Перенос сайта на другой хостинг - типовая задача, которая в неопытных руках кладёт проект на сутки. У бизнеса за это время отваливается реклама, теряются заявки, портятся позиции в выдаче. В статье разберём, как переехать на новую площадку за 1 рабочий день без простоя для пользователей.
Материал собран на опыте Сайты2.рф. Студия из Кронштадта работает с 2008 года, сделала 550+ проектов, NPS 9,2, средний рост заявок ×2,4, CR 4,8%, 92% клиентов возвращаются за повторными работами. В стеке - 1С-Битрикс, WordPress, Laravel, ISPmanager, BitrixVM, cPanel, certbot, rsync, mysqldump.
Время чтения - 11 минут. Внутри 4 этапа подготовки, 9 шагов миграции, 7 ошибок, чек-лист на 15 пунктов и FAQ.
Когда пора менять хостинг
Решение о смене площадки никогда не бывает спонтанным. Обычно срабатывает один из четырёх триггеров.
Медленный TTFB. Время ответа сервера выше 800 мс на статике или 1,5 секунды на динамике. Сайт проседает в Core Web Vitals, Яндекс понижает в выдаче. Подробно про метрики - в гайде Core Web Vitals 2026.
Частые падения. Аптайм ниже 99,5% за месяц, ночные перезагрузки без предупреждения, утечки памяти у соседей по VDS. У интернет-магазина за час простоя в пиковый день уходит 80-200 тысяч рублей выручки.
Политика 152-ФЗ. Хостер не на территории РФ или не предоставляет письмо о расположении дата-центра. С 2022 года Роскомнадзор регулярно проверяет операторов ПДн. Проверки идут по чек-листу 152-ФЗ.
Истечение контракта. Закончился промо-период, тариф вырос в 2-3 раза. Технически всё устраивает, но платить переплату нет смысла.
Сюда же добавим масштаб: проекту тесно на shared-хостинге, нужен VDS или выделенный сервер. Это плановая миграция, к ней готовятся за 2-4 недели.
Что значит "без даунтайма"
Без даунтайма - значит, для конечного пользователя сайт не падает в момент переключения. Никаких "ведутся технические работы", никаких 502 от nginx, никаких потерянных корзин у покупателей.
Технически это достигается двумя условиями:
- Оба сервера (старый и новый) работают одновременно 24-72 часа после переноса.
- DNS-переключение настроено через низкий TTL, поэтому переход на новые IP занимает минуты, а не сутки.
Полный нулевой даунтайм возможен только при синхронной репликации БД и общем хранилище для пользовательских файлов. На малом и среднем бизнесе достаточно так называемого near-zero подхода: окно расхождения 1-3 минуты, за которое успевает закончиться текущая транзакция и начаться следующая.
Подготовка за 7 дней до миграции
Этап подготовки длиннее самого переноса. Сэкономите здесь - получите аварию на боевом сервере.
1. Выбор нового хостинга
Берёте площадку на 1-2 класса мощнее текущей. Проверяете локацию дата-центра (РФ для 152-ФЗ), наличие SSD/NVMe, бэкапов на стороне хостера, поддержки 24/7. Подробный разбор критериев - в статье Как выбрать хостинг для сайта.
Для 1С-Битрикс берут панель BitrixVM или ISPmanager 6 с шаблоном Bitrix. Для WordPress - cPanel или ISPmanager. Laravel-приложения проще разворачивать на чистом Ubuntu LTS с настроенным nginx, php-fpm, supervisor.
2. Заказ ресурсов с запасом 30%
Если на старом сервере CPU грузится на 40%, на новом закладывайте 55-60% от лимита. Запас нужен на сезонные всплески, обновления версий PHP, неожиданные крон-задачи.
3. Бэкап всего
Снимаете полную копию: код проекта, базу данных, файлы пользователей, cron-задачи, переменные окружения, SSL-сертификаты. Архив храните в двух местах - локально и в облаке. Без бэкапа миграцию не начинают.
4. Аудит старого сайта
Перед переносом избавляются от мусора: удаляют битые ссылки, неиспользуемые плагины, временные таблицы БД, древние ревизии записей. Чем чище проект, тем быстрее проходит синхронизация. Заодно проверяют сайт по чек-листу приёмки.
9 шагов переноса сайта на другой хостинг
Главный ключ статьи - перенос сайта на другой хостинг без даунтайма. Девять шагов ниже выстроены так, чтобы пользователь ничего не заметил.
Шаг 1. Развёртывание копии на новом хосте
На новом сервере поднимаете окружение, идентичное старому: версия PHP, расширения, лимиты, MySQL/MariaDB, Redis. Создаёте поддомен test.вашсайт.ру и привязываете его к новому IP через A-запись. Доступ к поддомену закрываете basic-auth, чтобы поисковики не индексировали копию.
Шаг 2. Перенос файлов через rsync
Команда rsync -avz --progress копирует код и пользовательские файлы по SSH с сохранением прав, дат и симлинков. Для проекта в 30-50 ГБ первая синхронизация занимает 2-6 часов. Повторные проходят за 10-20 минут - rsync переносит только изменённые файлы.
Если SSH между хостами недоступен, делают tar-архив, кладут на S3-совместимое хранилище, скачивают на новом сервере.
Шаг 3. Перенос базы данных через mysqldump
Снимаете дамп командой mysqldump --single-transaction --quick. Параметр single-transaction нужен для InnoDB, чтобы дамп был консистентным без блокировки таблиц. Дамп копируете на новый сервер, разворачиваете через mysql -u user -p база < dump.sql.
Для проектов с БД больше 5 ГБ применяют mydumper/myloader - они работают в несколько потоков и переносят данные в 4-7 раз быстрее.
Шаг 4. Настройка SSL
Если у проекта Let's Encrypt - на новом сервере запускают certbot для тех же доменов через DNS-validation. Обычный HTTP-validation на этом этапе не подойдёт - домен ещё указывает на старый IP. Подробно про SSL - в статье SSL-сертификат для сайта.
Если сертификат коммерческий - копируют файлы .crt и .key, подключают через nginx или Apache на новом сервере.
Шаг 5. Прогон функционального чек-листа
На test-поддомене проходят все ключевые сценарии: открытие главной, листинг каталога, карточка товара, корзина, чекаут, оплата, форма заявки, личный кабинет, поиск, фильтры. Запускают тестовый платёж в песочнице. Проверяют логи nginx и php-fpm на ошибки.
Параллельно гоняют PageSpeed Insights, сравнивают TTFB и LCP с боевым сервером. Если новый хост проигрывает в скорости, разбираются с настройками кеша и opcache до переключения.
Шаг 6. Снижение TTL DNS до 300 секунд
За 2 дня до миграции в панели регистратора уменьшают TTL у A-записи и записи www до 300 секунд (5 минут). Поэтому при переключении провайдеры обновят кеш за 5-15 минут, а не за сутки.
Если TTL стоял 86400 (24 часа), а вы поменяли его за час до миграции - не сработает. Старое значение уже разошлось по DNS-кешам.
Шаг 7. Финальная синхронизация
За 5 минут до переключения снимают свежий дамп БД, переносят на новый сервер, накатывают. Параллельно повторно гоняют rsync по файлам пользователей. На этом этапе на 1-3 минуты можно поставить сайт в read-only - корзины и заказы блокируются, просмотр контента остаётся.
Шаг 8. Переключение A-записи в DNS
В панели регистратора меняете IP-адрес в A-записях @ и www на новый. Сохраняете. С этого момента пользователи постепенно перетекают на новый сервер.
Старый сервер не выключайте - часть провайдеров будет ходить на него ещё 12-48 часов. Если на нём отдавать актуальный код и БД, никто ничего не заметит.
Шаг 9. Мониторинг 24-72 часа
Включаете внешний мониторинг через UptimeRobot, Pinger, Яндекс.Мониторинг. Следите за откликами обоих серверов, ошибками 5xx, логами php-fpm. Через 48-72 часа, когда весь трафик уходит на новый IP, старый сервер можно гасить.
Что часто ломается после переноса
Девять из десяти инцидентов после миграции - это не баги, а забытые мелочи. Перечень самых частых.
Cron-задачи. Записи в crontab не переносятся автоматически при rsync. Команда crontab -l на старом сервере, сохранить в файл, скопировать, crontab cronfile на новом.
Sendmail и SMTP. Письма из CMS перестают доходить. Причина - на новом IP не настроен SPF/DKIM, или sendmail не установлен. Решается за 30 минут: установка пакета, добавление TXT-записей в DNS.
Права доступа на файлы. rsync с флагом -a их сохраняет, но при ручном переносе через архив - часто слетают. CMS падает в 500-ю ошибку. Решение: chown -R пользователь:группа /var/www, chmod 755 на директории, 644 на файлы.
Кеш Битрикса. После переноса в /bitrix/cache/ остаются файлы со старыми путями. Сайт работает с глюками. Лечится через админку: Настройки → Производительность → Очистить весь кеш. Или вручную: rm -rf /bitrix/cache/*.
Переменные окружения. .env-файл проекта Laravel или WordPress часто исключают из git и забывают перенести. Сайт встречает белым экраном. Решение: руками копируют .env с боевого сервера до переключения.
Сравнение методов миграции
Под разный масштаб подходят разные подходы.
DNS-переключение. Самый простой метод. Подходит для лендингов, корпоративных сайтов, интернет-магазинов с трафиком до 5 000 визитов в сутки. Окно расхождения - 5-15 минут.
Split DNS / weighted DNS. Часть трафика идёт на старый IP, часть на новый. Удобно для A/B-тестирования нового сервера. Поддерживается у Яндекс.DNS, Cloudflare, AWS Route 53.
Reverse proxy. На новом сервере ставится nginx-proxy, который сначала проксирует на старый IP, потом постепенно переключается. Применяется для высоконагруженных проектов с активными сессиями.
Blue-green deployment. Параллельно работают две полные копии проекта. Переключение - сменой балансировщика. Подходит SaaS-сервисам и крупным e-commerce от 50 000 визитов в сутки.
Для 80% задач малого и среднего бизнеса работает первый вариант. Усложнения нужны там, где простой стоит сотен тысяч рублей в час.
Стоимость работ
Силами заказчика бесплатно по деньгам, но затратно по времени: 12-30 человеко-часов разработчика и сисадмина. Для проекта без боевой нагрузки этого хватает.
Силами студии стоимость зависит от сложности:
- Лендинг или сайт-визитка - 25 000-35 000 ₽.
- Корпоративный сайт на WordPress или Битрикс - 35 000-55 000 ₽.
- Интернет-магазин с интеграциями - 55 000-90 000 ₽.
В работу входит подготовка, перенос файлов и БД, настройка SSL, переключение DNS, мониторинг 72 часа, гарантийная неделя на доработки. Точную смету выдаём после аудита проекта. Рассчитать в калькуляторе или посмотреть прайс на услуги.
7 ошибок при переносе
Ошибка 1. Миграция без тестового прогона
Файлы и БД залили на новый сервер и сразу переключили DNS. На третий час обнаружили, что не работает оплата. Решение: обязательный test-поддомен и чек-лист сценариев до переключения.
Ошибка 2. Высокий TTL DNS
Перед переключением забыли снизить TTL до 300 секунд. Старое значение 86400 разошлось по всем кешам провайдеров. Часть трафика сутки ходит на старый сервер с устаревшей БД.
Ошибка 3. Выключение старого сервера сразу после переноса
Через час после переключения старый VDS погасили. Те, у кого DNS ещё не обновился, видят 503. Старый сервер держат минимум 48-72 часа.
Ошибка 4. Перенос без аудита
В дамп БД попадают 300 МБ временных таблиц и логов. Файловая помойка из кешей и старых ревизий копируется на новый сервер вместе с проектом. Решение - аудит и чистка за неделю до миграции.
Ошибка 5. Игнорирование cron и переменных окружения
Перенесли код и БД, забыли crontab и .env. Через час перестали уходить уведомления, через сутки не списались абонентки. Чек-лист спасает.
Ошибка 6. Бэкап только в одном месте
Архив лежит на старом сервере, который как раз и переносят. Если на этапе синхронизации диск посыпался - проект потерян. Минимум две копии в разных физических местах.
Ошибка 7. Перенос в пятницу вечером
К субботе всплывает баг, поддержка хостера работает в дежурном режиме, ваш разработчик в отпуске. Миграцию делают вторник-четверг утром, в окно с минимальной нагрузкой. Лучше всего - 03:00-06:00 МСК.
Чек-лист "перенос за 1 день"
- [ ] Выбран новый хостинг с запасом 30% по ресурсам
- [ ] Сделан бэкап кода, БД, файлов в двух местах
- [ ] Перенесены и сохранены cron-задачи
- [ ] Скопированы .env и переменные окружения
- [ ] Поднята тестовая копия на поддомене
- [ ] SSL настроен через DNS-validation Let's Encrypt
- [ ] Пройден функциональный чек-лист на test-копии
- [ ] Сравнены метрики скорости со старым сервером
- [ ] Снижен TTL DNS до 300 секунд за 2 дня
- [ ] Сделан финальный dump БД за 5 минут до переключения
- [ ] Переключена A-запись в DNS-панели
- [ ] Подключён внешний мониторинг доступности
- [ ] Проверены логи php-fpm и nginx на новом сервере
- [ ] Очищен кеш CMS (Битрикс, WordPress, Laravel)
- [ ] Старый сервер выключен через 72 часа после переноса
FAQ
Сколько занимает миграция сайта по времени
Подготовка - 5-7 дней (выбор хостинга, бэкапы, аудит). Активная фаза переноса - 1 рабочий день (4-8 часов). Мониторинг и доработки - 2-3 дня. Полный цикл - 10-14 дней.
Можно ли переехать без потери позиций в поиске
Да, если переезд проходит без даунтайма и без смены URL-структуры. SEO-позиции зависят от контента и ссылочного, а не от IP. Проседание возможно при долгом простое от 6 часов или при смене протокола (http на https) одновременно с миграцией.
Что делать, если новый хостинг оказался хуже старого
В течение 72 часов после переключения старый сервер остаётся боевым - возврат делают за 30 минут изменением A-записи обратно. Поэтому старый VDS не гасят сразу. После 72 часов возврат тоже возможен, но придётся синхронизировать БД и файлы заново.
Нужно ли менять что-то в коде сайта после переноса
Чаще нет. Иногда меняют пути в config-файлах (DOCUMENT_ROOT), параметры подключения к БД, ключи интеграций. Кардинальная переработка кода нужна только при смене панели управления или версии PHP.
Можно ли мигрировать самостоятельно без разработчика
На простом сайте-визитке - да, если есть базовые навыки работы с SSH, MySQL и DNS. На корпоративном сайте или магазине - рискованно: цена ошибки выше, чем стоимость работ студии. Заодно после миграции часто требуется поддержка сайта для стабилизации.
Можно ли совместить миграцию с редизайном
Можно, но это два проекта по сложности. Перенос делают на текущей версии сайта, редизайн запускают через 1-2 недели после стабилизации. Для одновременного запуска заказывают редизайн с миграцией в одном проекте у одного подрядчика.
Что в итоге
Перенос сайта на другой хостинг без даунтайма - это 4 этапа подготовки и 9 шагов миграции. При грамотной подготовке весь процесс укладывается в 1 рабочий день, без потери заявок и позиций. Главное - тестовая копия на поддомене, низкий TTL DNS, двойной мониторинг и старый сервер в горячем резерве 72 часа.
Если планируете переезд - в Сайты2.рф делаем миграцию под ключ с фиксацией сроков в договоре. Студия в Кронштадте, опыт с 2008 года, 550+ проектов, 92% клиентов возвращаются. Берём проекты на 1С-Битрикс, WordPress, Laravel, MODx. Аудит хостинга и план переноса - бесплатно за 24 часа.
Заказать поддержку и перенос сайта - Рассчитать стоимость - Написать в Telegram @t9424744 - Позвонить +7 (812) 942-47-44
