ISPmanager 6 — альтернатива cPanel зі схожим функціоналом, але гнучкішою ліцензійною політикою і нативною підтримкою Nginx. Перенесення сайтів з cPanel не потребує складних інструментів — усе робиться через стандартні бекапи та імпорт, але порядок кроків важливий: пропущений етап пошти чи прав доступу дає робочий сайт з непрацюючою відправкою листів.

Порівняння cPanel і ISPmanager 6

Розгорнуте порівняння можливостей — у статті ISPmanager 6 vs cPanel; якщо потрібне перенесення між двома серверами вже на ISPmanager, дивіться статтю перенесення сайту між серверами в ISPmanager 6.

Функція	cPanel	ISPmanager 6
Керування сайтами	Так	Так
MySQL/MariaDB	phpMyAdmin	Вбудований інструмент
Пошта	Так (Roundcube)	Так (Roundcube)
SSL (Let's Encrypt)	Так	Так
Nginx + PHP-FPM	Ні (лише Apache)	Так, нативно
Docker/контейнери	Ні	Базова підтримка
Ціна/місяць (1 сервер)	$25+	€15–30

Крок 1: експорт з cPanel

# Через cPanel -- Backup Wizard -- Full Account Backup
# Завантажити .tar.gz архів акаунта

# Або через CLI на сервері з cPanel
/usr/local/cpanel/scripts/pkgacct USERNAME /home/backup/

Крок 2: створення користувача в ISPmanager

# В ISPmanager: Користувачі -- Створити
# Або через CLI ISPmanager
/usr/local/mgr5/sbin/mgrctl -m ispmgr user.edit name=myuser passwd=StrongPass123 email=user@example.com package=default

Крок 3: перенесення файлів сайту

# Завантажити бекап на новий сервер
scp backup-cpanel.tar.gz root@new-server:/tmp/

# Розпакувати і скопіювати файли
cd /tmp && tar -xzf backup-cpanel.tar.gz
rsync -av /tmp/homedir/public_html/ /var/www/www-root/data/www/example.com/

# Встановити права
chown -R www-data:www-data /var/www/www-root/data/www/example.com/

Розбір типових помилок при перенесенні

500 Internal Server Error одразу після копіювання файлів — найчастіше річ у правах: скопійовані файли зберігають власника cPanel-акаунта, а PHP-FPM в ISPmanager працює від іншого користувача.
SQLSTATE[HY000] [1045] Access denied for user у конфігу сайту після імпорту БД — користувач MySQL з cPanel не переніс разом з дампом, його потрібно створити заново в ISPmanager з тим самим ім'ям і новим паролем.
Листи йдуть, але не приходять отримувачам — на новому сервері не налаштовано записи SPF/DKIM або зберігся старий MX, що вказує на сервер cPanel; перевіряйте DNS окремо від факту успішної відправки.
PHP Fatal error: require(): Failed opening required — в архіві cPanel відносні шляхи прописані інакше, ніж очікує структура каталогів ISPmanager (/var/www/www-root/data/www/ замість public_html).

Крок 4: відновлення баз даних MySQL

# Знайти дампи БД у бекапі cPanel
ls /tmp/mysql/
# backup-db1.sql.gz, backup-db2.sql.gz ...

# Створити БД в ISPmanager (через вебінтерфейс або CLI)
# Імпортувати
zcat /tmp/mysql/db1.sql.gz | mysql -u root -p db1_new

Крок 5: перенесення поштових скриньок

# Витягти пошту з бекапу cPanel
ls /tmp/mail/example.com/
# user1/ user2/ ...

# Скопіювати Maildir на ISPmanager
rsync -av /tmp/mail/example.com/ /var/vmail/example.com/

# В ISPmanager створити скриньки з тими самими іменами і паролями
# (паролі доведеться скинути -- cPanel зберігає лише хеші)

Паролі поштових скриньок: зберегти паролі під час міграції пошти не можна — вони зберігаються у вигляді хешів, несумісних між панелями. Розішліть користувачам листи з інструкцією щодо встановлення нового пароля заздалегідь, до перемикання MX-запису.

Налаштування SSL в ISPmanager

# ISPmanager автоматично випускає Let's Encrypt SSL
# Сайти -- вибрати домен -- SSL -- Let's Encrypt -- Увімкнути
# Або через CLI
/usr/local/mgr5/sbin/mgrctl -m ispmgr ssl.edit elname=example.com letsencrypt=on

Порівняння способів перенесення пошти і файлів

Дані	Спосіб перенесення	Ризик втрати
Файли сайту	tar.gz + rsync	Низький
Бази даних	mysqldump / вбудований бекап	Низький за перевірки дампу
Поштові скриньки	rsync Maildir	Середній (паролі губляться)
Cron-завдання	Ручне перенесення з crontab -l	Високий (часто забувають)

Права на файли: ISPmanager використовує схему прав, відмінну від cPanel. Після перенесення перевірте, що PHP-скрипти можуть читати і писати потрібні директорії (/var/www/www-root/data/www/), інакше сайт відкриється, а завантаження файлів чи кеш перестануть працювати.

Коли таке перенесення не підходить

Потрібне перенесення без даунтайму — метод через повний бекап передбачає паузу між експортом і перемиканням DNS; для нульового простою потрібна окрема схема з паралельною роботою двох серверів і фінальною синхронізацією.
На старому сервері використовуються специфічні модулі Apache (mod_security-правила, кастомні .htaccess під конкретну версію Apache) — ISPmanager працює з Nginx, і такі правила доведеться переписувати під інший вебсервер, а не просто скопіювати.
Акаунтів десятки і більше — ручне перенесення за кроками вище не масштабується; для масової міграції потрібен скрипт, що автоматизує експорт і створення користувачів через CLI ISPmanager.

Як перевірити, що перенесення завершено успішно

# Сайт відкривається напряму за IP нового сервера (до перемикання DNS)
curl -H "Host: example.com" http://NEW_SERVER_IP/ -I

# База даних на місці і таблиці читаються
mysql -u root -p -e "USE db1_new; SHOW TABLES;"

# Поштова скринька приймає листи локально
echo "test" | mail -s "test" user1@example.com

# Після перемикання DNS -- MX справді веде на новий сервер
dig MX example.com +short

Якщо сайт відповідає за прямим IP, таблиці бази видно і вони не порожні, тестовий лист доставляється в Maildir, а MX після перемикання вказує на новий сервер — міграцію завершено без втрат.