Переход с cPanel на Enhance: что изменится для вас

cPanel был стандартной панелью управления хостингом на протяжении двадцати лет, поэтому большинство людей, переходящих с него, на самом деле не сравнивают функции — их больше беспокоит, что произойдёт на следующий день после переезда. Вот что действительно меняется.

Меняется сама модель — и в этом весь смысл

cPanel предоставляет вам одну учётную запись, внутри которой находится всё: файлы, базы данных, почта, cron — и всё это использует общие лимиты аккаунта. Enhance предоставляет отдельный контейнер для каждого сайта. Пять ваших сайтов — это пять изолированных окружений со своими лимитами CPU, RAM и I/O.

Первое практическое отличие заметно сразу: если какой-то плагин начинает бесконтрольно потреблять CPU, он выводит из строя только один сайт, а не все сразу.

Второе преимущество становится заметно примерно через неделю: отдельные лимиты для каждого сайта означают и отдельную статистику. Если что-то начинает работать медленно, вы сразу можете увидеть, какой именно сайт создаёт нагрузку.

Куда переместились привычные функции

Те же задачи, просто находятся в других местах. Ничего из этого списка в Enhance не исчезло — оно просто переместилось.

Но две вещи действительно отличаются.

На уровне аккаунта больше нет общего public_html — у каждого сайта собственный web root. Также нет директории .cpanel с конфигурацией всего аккаунта: этим состоянием управляет сама панель. Именно поэтому перенос сайта между серверами выполняется средствами панели, а не простым переносом tar-архива.

Две привычки, от которых придётся отказаться

Перестаньте мыслить «аккаунтами» и начните мыслить «сайтами». В cPanel добавление второго проекта обычно означало создание addon-домена внутри того же аккаунта с общей версией PHP и общими лимитами. В Enhance вы добавляете отдельный сайт, который получает собственную версию PHP, собственные лимиты и собственные резервные копии.

При миграции пользователи иногда пытаются воссоздать старую структуру — один сайт с пятью дополнительными доменами — а потом удивляются, куда исчезла изоляция.

Перестаньте устанавливать отдельные плагины безопасности на каждый сайт. WAF, сканирование вредоносного ПО и защита от brute-force работают ниже уровня сайта — непосредственно на сервере. WordPress-плагин безопасности поверх этого в основном лишь расходует CPU, повторно сканируя уже проверенные файлы, а его функция блокировки попыток входа начинает дублировать серверную защиту.

Как на самом деле происходит переезд

Грамотная миграция — это не tar-архив и надежда на лучшее. Вот порядок действий, позволяющий избежать простоя:

1. Копировать, а не переносить. Сайты создаются заново на новой платформе, пока старые продолжают обслуживать посетителей. На этом этапе DNS вообще не меняется.
2. Проверить каждый сайт через временный URL. Enhance предоставляет каждому сайту временное имя хоста. Проверьте оформление заказа, контактную форму, авторизацию и другие важные функции. Именно этот этап часто пропускают, а потом обнаруживают, что платёжный шлюз был привязан к IP старого сервера.
3. Уменьшить TTL DNS. Установите его на 300 секунд примерно за сутки до переключения. Тогда в случае необходимости откат займёт минуты, а не часы.
4. Синхронизировать последние изменения. Перенесите изменения базы данных и файлов, появившиеся за время тестирования нового сервера.
5. Переключить DNS. В течение часа наблюдайте за обоими серверами. Старый сервер лучше отключать через неделю, а не в тот же вечер.

Пять шагов, позволяющих выполнить миграцию без простоя. DNS не меняется вплоть до пятого шага.

# до переключения: сколько времени займёт откат?
dig +short example.com A
dig example.com A | awk '/^example/ {print "TTL", $2}'

# после переключения: действительно ли сайт уже работает на новом хостинге?
curl -sI https://example.com | grep -iE 'server|x-litespeed'

Что действительно может сломаться

• Жёстко прописанные пути. Всё, что ссылается на /home/olduser/public_html — например, WP_CONTENT_DIR в WordPress, include в старом PHP-приложении или команда cron, — необходимо изменить под новый путь.
• Списки разрешённых IP-адресов. Платёжные шлюзы, почтовые реле и сторонние API могут быть привязаны к IP старого сервера. Найдите и проверьте такие настройки до миграции — это одна из самых распространённых причин проблем после переключения.
• Почта. Перенос почты — отдельная задача, не связанная напрямую с переносом сайтов. Если MX-записи домена указывают на другой почтовый сервис, оставьте их без изменений и сначала перенесите сайты.
• Очень старые версии PHP. Код, которому требуется PHP 5.6, не будет работать на современной платформе. Это уже не миграция, а необходимость доработки или переписывания кода — и лучше узнать об этом до начала переезда.

В inSave миграцией занимаются инженеры, которые обслуживают саму платформу, а не автоматический скрипт: мы копируем сайты, предоставляем вам временные URL для проверки, и только после подтверждения каждого сайта переключается DNS.

Миграция бесплатна на всех тарифах, включая реселлерские, где может потребоваться перенести десятки клиентских аккаунтов.

Коротко

Вы теряете одну учётную запись, внутри которой находится всё, но получаете отдельный контейнер для каждого сайта — со своими лимитами, резервными копиями и версией PHP.

Миграция безопасна, когда выполняется по принципу «скопировать → проверить → переключить», и становится рискованной, когда старую систему отключают сразу в момент переезда.

Большинство проблем при миграции связано не с самой панелью. Обычно виноват жёстко прописанный путь или список разрешённых IP-адресов, о котором никто заранее не вспомнил.