- Инвентаризация кодовой базы. Сканируется директория проекта на предмет общего объёма файлов, выявляются скрытые медиа-архивы и временные кеши, которые не требуется переносить. Для крупного интернет-магазина типичный объём — 8–25 ГБ, и от него зависит выбор метода передачи: rsync, tar+scp или snapshot диска.
- Снимок базы данных. Делается дамп всех схем с фиксацией кодировки (utf8mb4_unicode_ci), движков таблиц и хранимых процедур. Если база крупнее 4 ГБ, дамп разбивается по таблицам с параллельной заливкой через mysqldump --single-transaction для консистентности данных.
- Карта зависимостей. Перечисляются все внешние сервисы — платёжные шлюзы, службы доставки, маркетплейсы, рекламные пиксели, веб-аналитика. Для каждой связи фиксируется список IP, которые потребуется добавить в whitelist у партнёров после смены площадки.
- Аудит DNS-записей. Снимаются текущие A, AAAA, MX, TXT, SPF, DKIM, DMARC, CAA. Для каждой записи определяется TTL — за 48 часов до миграции он снижается до 300 секунд, чтобы обновление прошло максимально быстро.
- Проверка лицензий. Премиум-плагины, шаблоны и SaaS-сервисы часто привязаны к домену или IP. Составляется реестр лицензий с инструкцией по переактивации после переключения. Иначе после миграции часть функционала откажет — от форм обратной связи до модулей расчёта доставки.
- Профиль нагрузки. Снимаются графики посещаемости за последние 90 суток, чтобы выбрать окно с минимальным трафиком — обычно ночь со вторника на среду или воскресенье 03:00–07:00 по МСК.
- Тестовая копия. На целевом сервере поднимается staging-окружение с тем же стеком, на нём прогоняются все критичные сценарии: оформление заказа, оплата, регистрация, личный кабинет. До прохождения staging боевая миграция не запускается.
Результатом аудита становится миграционная карта на 15–30 страниц с чек-листами, ответственными и временными слотами. Этот документ передаётся всей команде — администратору, разработчикам, контент-менеджеру и тестировщику. Для проектов уровня создания интернет-магазина карта дополнительно включает протокол выверки остатков и заказов, чтобы переезд не нарушил учёт. Параллельно согласуется план коммуникации с пользователями: за 72 часа отправляется письмо, на сайте размещается баннер о технических работах, в социальных сетях публикуется анонс окна простоя.
Технология переноса файлов, базы данных и почтовых сервисов
Сам процесс миграции делится на три параллельных потока — статика, динамическое содержимое и почта. Каждый поток имеет собственные риски и инструменты, и игнорирование любого из них приводит к ситуации, когда «сайт работает, а письма не доходят» или наоборот. Грамотная организация позволяет уложиться в 4–8 часов даже для проектов объёмом 50 ГБ и базой в 20 миллионов записей.
- Передача исходных файлов. Используется rsync через SSH с параметрами -avz --partial --progress, что обеспечивает докачку при разрыве и сжатие на лету. Для гигантских репозиториев применяется LVM-snapshot и побайтовая передача через dd, чтобы исключить рассинхронизацию во время копирования.
- Перенос базы. Дамп заливается на целевую СУБД с проверкой целостности через CHECKSUM TABLE. Для движков InnoDB включается режим foreign_key_checks=0 на время заливки, после чего проверяется ссылочная целостность. Финальная сверка количества строк по каждой таблице исключает потери при передаче.
- Синхронизация дельты. Между первым копированием и финальным переключением проходит несколько часов, за которые на старом сервере появляются новые заявки и заказы. Перед DNS-переключением выполняется повторный rsync только изменённых файлов и инкрементальный дамп таблиц с флагом updated_at > {timestamp первого дампа}.
- Миграция почты. Если на старом провайдере работали почтовые ящики @домен, их содержимое переносится через imapsync с сохранением структуры папок, флагов прочтения и меток. Объём почтовых архивов компании уровня среднего бизнеса достигает 80–200 ГБ, и эту операцию запускают за сутки до основного окна.
- Перенастройка SPF/DKIM. Старые DKIM-ключи отзываются, новые генерируются на принимающем сервере и публикуются в DNS заранее. SPF-запись расширяется так, чтобы временно включать оба сервера — это даёт окно в 48 часов, когда письма уходят корректно при любом из активных MX.
- Сертификаты TLS. Let's Encrypt-сертификат выпускается через DNS-01 challenge до переключения трафика, что позволяет ему быть готовым к моменту изменения A-записей. Для EV-сертификатов с привязкой к юридическому лицу клиента согласуется передача приватного ключа по защищённому каналу.
- Кеш и CDN. После переключения принудительно очищаются кеши на уровне приложения, OPcache, Redis, а также покупные CDN-сервисы. Без сброса кеша часть посетителей в течение суток будет видеть старые версии страниц с прежнего IP.
Финальным шагом становится изменение A-записей DNS с переводом TTL обратно на стандартные 3600 секунд. В этот момент на обоих серверах должно быть включено логирование, чтобы убедиться: трафик постепенно перетекает на новую площадку и через 4–6 часов на старом IP остаётся менее 5% запросов. Для проектов с активным B2B-сегментом параллельно ведётся работа по доработке функционала сайта — в новое окружение сразу же выкатываются изменения, которые накопились за период подготовки и не были опубликованы на старой площадке во избежание двойного переноса.
Проверка работоспособности и контроль рисков после миграции
Переключение DNS — не финиш, а только начало этапа стабилизации. В ближайшие 24–72 часа проект находится под усиленным наблюдением: фиксируются метрики производительности, контролируется доставляемость писем, проверяется работа всех внешних интеграций. На этом отрезке выявляется 90% оставшихся проблем — от забытых cron-задач до несовместимости версий библиотек. Регламент проверки структурирован и не оставляет места случайностям.
- Функциональное тестирование. Прогоняется чек-лист из 50–120 сценариев: регистрация, авторизация, восстановление пароля, оформление заказа, оплата, возврат, личный кабинет, корзина, фильтры каталога, поиск. Каждый сценарий проходится как минимум в двух браузерах и на двух типах устройств.
- Контроль производительности. Снимаются метрики Core Web Vitals — LCP, INP, CLS — и сравниваются с показателями до миграции. Целевой LCP не выше 2.5 секунд, INP — не выше 200 мс. Если показатели хуже, выявляется причина: размеры изображений, отсутствие HTTP/2, неправильная настройка кеширования.
- Логи ошибок. В реальном времени отслеживаются error.log nginx, php-fpm и приложения. Любая 5xx-ошибка в первый час разбирается немедленно — обычно это либо отсутствующие расширения PHP, либо неверные права на директории upload/cache.
- Доставляемость писем. Через mail-tester.com и аналогичные сервисы проверяется итоговый рейтинг отправителя — целевая планка 9.5/10 и выше. Письма отправляются на тестовые ящики gmail, mail, yandex с проверкой попадания во «Входящие», а не в «Спам».
- Поисковая видимость. В Search Console и Яндекс.Вебмастере регистрируется новый адрес сервера, отправляется на переиндексацию sitemap.xml, контролируется отсутствие резких просадок по трафику и позициям. В первую неделю допустимы колебания ±15%, после чего показатели стабилизируются.
- Бэкапы. На новой площадке настраивается автоматическое создание бэкапов: ежедневный инкрементальный + еженедельный полный, с хранением 30 дней. Бэкапы выгружаются в отдельное S3-совместимое хранилище за пределами площадки исполнителя.
- Откат-план. Старый сервер сохраняется в режиме read-only ещё минимум 14 суток. Если в течение этого срока выявится критическая проблема, переключение DNS назад занимает не более 5 минут.
Особое внимание уделяется работе с пользовательскими сессиями. Если на старой площадке использовалось хранение сессий в файлах, а на новой — в Redis, без миграции хранилища все активные пользователи будут разлогинены одновременно, что для B2B-портала с тысячами активных клиентов означает шквал обращений в поддержку. Этот момент проектируется заранее, и сессии либо переносятся, либо переключение делается в окно минимальной активности. На этой же стадии формируется отчёт для заказчика: какие регламенты поддержки сайта подключаются на новой площадке, как организовано круглосуточное дежурство и какие SLA по времени реакции зафиксированы в договоре.
Состав работ, сроки и итоговая стоимость переезда под ключ
Услуга миграции оформляется по принципу фиксированного бюджета с прозрачной декомпозицией работ. Заказчик понимает, что входит в перенос, какие задачи относятся к опциональным и сколько времени займёт каждый блок. Подход исключает ситуации, когда после оплаты выясняется, что почта или SSL переносятся «отдельно за доплату». Все позиции оговариваются в коммерческом предложении до старта.
- Стандартный пакет. Включает аудит, копирование файлов и базы, перенос почты до 10 ящиков, выпуск SSL, настройку DNS, базовую проверку и 14-дневное наблюдение. Срок — 5–10 рабочих дней. Подходит для корпоративных сайтов и небольших каталогов до 5 ГБ.
- Расширенный пакет. Дополнительно покрывает оптимизацию конфигурации nginx и php-fpm, настройку Redis-кеширования, миграцию более 50 почтовых ящиков, перенастройку cron-задач и интеграций с CRM. Срок — 10–20 рабочих дней. Закрывает потребности интернет-магазинов с оборотом до 50 миллионов рублей в год.
- Корпоративная миграция. Подразумевает работу с кластерной архитектурой, балансировщиками, отдельной БД-нодой, синхронизацией геораспределённых реплик. Включает разработку плана отказоустойчивости, проведение учений по аварийному восстановлению и обучение внутренней команды клиента. Срок — 4–8 недель.
- Сопровождение после переезда. На 30, 60 и 90 сутки проводится контрольный аудит производительности, безопасности и резервного копирования. По результатам формируется отчёт с рекомендациями по дальнейшим улучшениям инфраструктуры.
- Гарантия. В течение 90 дней с момента финального переключения исправление любых проблем, связанных с миграцией, выполняется бесплатно. Если критический сбой произошёл по вине исполнителя, штраф фиксируется в договоре.
- Документация. Заказчик получает пакет файлов с описанием новой инфраструктуры: схема сети, доступы (передаются через защищённый менеджер паролей), инструкция по восстановлению из бэкапа, контактные обращения дежурной смены 24/7.
Цены формируются от объёма ресурса и сложности стека. Базовый перенос корпоративного сайта на WordPress или Битрикс начинается от 35 000 рублей. Миграция среднего интернет-магазина с интеграциями обходится в 80 000–180 000 рублей. Корпоративные проекты с кластером и геораспределёнными узлами оцениваются индивидуально — обычно от 350 000 рублей. Чтобы заказать услугу или узнать подробнее о включённых работах, достаточно оставить заявку на сайте или воспользоваться формой связи в разделе контакты. Менеджер свяжется в течение двух часов в рабочее время, согласует время первичного аудита и подготовит индивидуальное коммерческое предложение с учётом особенностей вашего проекта. Получить ориентировочную смету можно уже после первой технической встречи продолжительностью 30–45 минут, на которой проговариваются ожидания клиентов и критерии успеха.
Доменное имя, панель управления и поддержка после переезда
Отдельный блок переезда — корректная работа с доменным именем и панелью управления нового хостинга. Важно вовремя переключить делегирование домена, проверить DNS-записи и убедиться, что доступы к управлению сайтом и почтой переданы владельцу. Мы помогаем сделать это без простоя и берём на себя сопровождение в первые дни после миграции.
- перенос или перепривязка доменного имени и SSL-сертификата;
- настройка панели управления хостингом и прав доступа;
- помощь и техническая поддержка, пока сайт полностью не стабилизируется на новом сервере.
