Миграция сайта или веб‑сервиса на новый хостинг — одно из тех дел, где подготовка решает всё. Для малого и среднего бизнеса простои означают потерю клиентов и денег, поэтому важна прозрачная чек‑линия: тестирование, аккуратная работа с DNS и несколько готовых сценариев отката. Ниже — практический план, применимый к сайтам на CMS, простым веб‑приложениям и интернет‑магазинам.
Перед миграцией: сбор данных и подготовка окружения
Начните с аудита: какие компоненты зависят от текущего хостинга — база данных, cron‑задачи, почта, внешние интеграции (платёжные шлюзы, API), SSL‑сертификаты, файлы пользователей. Зафиксируйте версии PHP, базы, расширений, конфигурации веб‑сервера и ограничения (память, execution_time).
Параллельно разверните тестовую копию на новом хостинге. Если сомневаетесь в ресурсах — полезно перечитать рекомендации по выбору между виртуальным хостингом, VPS и выделенным сервером: как выбрать тип хостинга.
Снизьте TTL записей DNS заранее — за 48–72 часа до миграции установите меньший TTL (например, 300–600 секунд). Это уменьшит время переключения, если вы используете изменения DNS для финального шага.
Пошаговая миграция: от клона до «живого» сайта
- Клонирование и синхронизация данных. Сделайте полную копию файлов и дамп базы. Для динамических данных (заказы, регистрации) настройте репликацию или периодические синхронизации: rsync для файлов и бинарную репликацию/горячие бэкапы для БД.
- Тестирование на новом хостинге. Используйте временный домен или правку hosts на локальных машинах, чтобы проверить работу сайта через новый сервер без переключения публичного DNS. Проверьте формы, загрузки файлов, отправку почты (через тестовую почтовую подсистему) и работу сторонних интеграций.
- SSL и доменные имена. Выпустите сертификат (Let’s Encrypt или платный) на новом хосте. Если сертификат зависит от проверки по HTTP, делайте это на временном домене или после краткого переключения DNS с низким TTL.
- Финальная синхронизация. За 10–30 минут до запланированного переключения сделайте инкрементальную синхронизацию: свежие файлы и дамп изменений в базе. Для минимизации потерь переводите систему в режим обслуживания (maintenance), если это допустимо.
- Переключение DNS или балансировщика. Если вы используете прямой DNS: смените A/CNAME записи и ожидайте обновления — с заранее пониженным TTL это займёт минуты, а не часы. При использовании балансировщика или CDN — переключите origin/endpoint внутри панели управления. Планируйте переключение в окно низкой нагрузки; при учёте сезонности выбирайте момент согласно аналитике (см. рекомендации по пикам спроса и сезонности): учитывать пики спроса и сезонность.
- Проверка работоспособности и мониторинг. После переключения быстро проверьте ключевые сценарии: главная страница, покупка, вход, админка. Настройте простые HTTP‑чекеры и метрики (время ответа, код 200, ошибки 5xx). Подключите логирование ошибок и просматривайте логи первые 2–4 часа особенно внимательно.
Нюансы для интернет‑магазинов и баз с активными транзакциями
Если у вас есть заказы/платежи в реальном времени, рассмотрите blue‑green deployment или использование прокси/балансировщика, который направляет трафик на новый бэкенд по флагу. Можно временно блокировать новые заказы на старом хосте, сделать финальную синхронизацию и затем открыть приём на новом. Обязательно согласуйте с платёжными провайдерами возможные IP‑изменения.
Откат при ошибках: подготовьте план заранее
Откат должен быть простым и проверенным. Опишите три уровня отката:
- Мягкий откат — исправление конфигурации на новом сервере (например, поправить путь к файлам, права, переменные окружения).
- Переключение назад по DNS — меняем записи на прежние значения. Это работает быстро при низком TTL, но может потребовать до нескольких минут для некоторых клиентов.
- Полный откат — перевод всего трафика обратно на старый хост, восстановление базы из бэкапа, откат к предыдущей версии кода.
Перед миграцией сохраните контрольный дамп БД и архив файлов с отметкой времени. Прогоните сценарий отката на тестовом окружении, чтобы не сталкиваться с неожиданными шагами в критический момент.
Чек‑лист после успешной миграции
Через 24–72 часа проведите полный аудит — проверьте логи ошибок, метрики производительности, индексацию поисковиками, доставляемость почты и работу интеграций. Обновите внутреннюю документацию: куда заходить по SSH, где бэкапы, как восстанавливать сертификат. Если появятся проблемы с доставкой уведомлений или авторизацией — проверьте брандмауэр, обратные DNS и SPF/DKIM записи.
Миграция без простоя — это комбинация грамотной подготовки, тестирования и готовых сценариев отката. Планируйте работу на «тихое» время, снизьте TTL заранее и держите под рукой контакты техподдержки старого и нового хостера. Такой подход минимизирует риски и позволит перевести сайт на хостинг в Беларуси с минимальным влиянием на бизнес.