Смена подрядчика по сайту почти всегда происходит в панике: старый разработчик пропал, поднял цену вдвое или просто перестал отвечать в мессенджере, а сайт тем временем продолжает принимать заказы. За последние годы я минимум раз пятнадцать заходил в чужие проекты именно в этой роли - либо принимал сайт от предыдущего исполнителя, либо, наоборот, передавал клиента дальше. Ниже - реальный порядок действий, а не теория.
Аудит перед сменой подрядчика: что смотреть в первую очередь
Прежде чем писать прежнему исполнителю «давайте расставаться», соберите полную картину проекта. Мне нужно на старте увидеть три вещи: хостинг и его тарифный план, CMS с версией ядра и списком плагинов, и список внешних интеграций - эквайринг, доставка, CRM, рассылки.
На практике интеграций обычно больше, чем клиент помнит. Стандартный набор для интернет-магазина на WooCommerce - это эквайринг через Т‑Банк, служба доставки СДЭК с расчётом стоимости в корзине, плюс вебхуки в CRM. Если хотя бы один модуль настроен захардкоженными ключами без документации, при переезде на новый сервер он просто перестанет работать, и вы узнаете об этом от клиентов, а не от разработчика.
Попросите старого подрядчика прислать техническое описание архитектуры - даже в виде текстового файла на пол-страницы. Если такого документа никогда не было, это тревожный звонок: скорее всего, часть логики держится в голове одного человека, и без него разбираться в проекте будет заметно дольше.
Какие доступы собрать у прежнего исполнителя
Список минимум состоит из следующего:
- Панель хостинга или облачного провайдера (root или админ-доступ, не гостевой)
- Административная панель CMS - с ролью администратора, а не редактора
- Домен и DNS-зона - либо доступ к регистратору, либо к DNS-провайдеру, если записи вынесены отдельно
- FTP/SFTP или SSH к серверу
- Учётки в личных кабинетах эквайринга, СДЭК, email-рассылок, аналитики
- Репозиторий с кодом, если проект кастомный, а не собран в конструкторе
- Ключи API для сторонних сервисов и вебхуков
Доступы нужно не просто получить, а сразу проверить рабочим входом при подрядчике на связи - часто пароли присылают устаревшие или от давно отключённой двухфакторной аутентификации. Отдельно смените все пароли и API-ключи сразу после передачи: даже добросовестный исполнитель мог случайно оставить копию доступов в переписке или в файле на своём компьютере.
Если сайт собран на Tilda, доступы устроены проще - там нет хостинга и сервера в привычном виде, но важно получить права совладельца проекта в личном кабинете Tilda, а не приглашение с ролью редактора. Отдельно проверьте кастомные скрипты, вставленные через блок T123 или в настройках проекта: часто там живёт интеграция с CRM или счётчики аналитики, которые перестанут работать при неаккуратном переносе.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Бэкапы: как не потерять базу данных и медиафайлы
Перед любыми действиями с сайтом делайте полный бэкап - базы данных, файлов темы, загруженных медиа и, отдельно, всех переменных окружения с ключами интеграций. На WordPress это обычно два архива: дамп MySQL и zip с папкой wp-content. На кастомных проектах на Laravel или Node.js добавляется файл .env - без него после переноса перестанут работать почтовые рассылки, эквайринг и любые внешние API.
Бэкап нужно не просто скачать, а проверить восстановлением на тестовом окружении. Я сталкивался с ситуацией, когда клиент три месяца получал от старого подрядчика архивы весом 40 мегабайт вместо ожидаемых нескольких гигабайт - экспорт базы обрывался по таймауту, а никто это не проверял, потому что архив просто клали в облако по расписанию.
Если база большая (интернет-магазин с историей заказов за несколько лет), экспорт через административную панель CMS может не осилить объём. Тогда делают дамп напрямую через mysqldump по SSH или через панель управления базой данных на хостинге. Для регулярных автоматических бэкапов на будущее удобно поднять отдельный скрипт с ротацией копий и выгрузкой в отдельное хранилище - в библиотеке готовых скриптов есть шаблоны именно под такую задачу, их проще адаптировать, чем писать с нуля.
Миграция сайта без даунтайма: DNS, TTL и staging-копия
Остановка сайта на несколько часов ради переезда - это не техническая необходимость, а следствие плохого планирования. Схема, которая у меня стабильно работает:
- За сутки-двое до переезда снижаю TTL на A‑записи домена до 300 секунд (пять минут) - это даёт быстрое переключение вместо стандартных 24-48 часов на распространение изменений DNS
- Разворачиваю копию сайта на новом хостинге по отдельному техническому адресу или через правку локального файла hosts - так можно протестировать всё до переключения реального трафика
- Синхронизирую базу данных непосредственно перед переключением - если это интернет-магазин, важно поймать момент с минимальным числом активных заказов, обычно это ночь или раннее утро
- Меняю A‑запись на новый сервер и слежу за логами обоих серверов несколько часов - часть трафика ещё идёт на старый IP из-за закешированных DNS у части пользователей
- Через сутки возвращаю TTL к обычному значению и отключаю старый хостинг, но не раньше
При такой схеме реальный простой укладывается в считаные минуты - время на переключение записи и перезапуск веб-сервера, а не часы недоступности сайта. Отдельно проверяю SSL-сертификат на новом сервере до переключения DNS: если сертификат не готов заранее, посетители при переходе увидят предупреждение браузера о небезопасном соединении, и это гораздо заметнее, чем короткая пауза в доступности.
Особенности передачи по разным платформам
Порядок действий отличается в зависимости от того, на чём собран сайт. Свёл основные различия в таблицу.
| Платформа | Что критично при передаче | Типичный риск |
|---|---|---|
| Tilda | Права совладельца проекта, экспорт кастомных скриптов из блоков T123 | Скрипт интеграции с CRM живёт только в настройках проекта и нигде не задокументирован |
| WordPress / WooCommerce | Дамп базы, wp-content, файл с ключами эквайринга и СДЭК | Плагины с истёкшей лицензией перестают получать обновления безопасности после переезда |
| Кастомный сервис (Laravel, Vue, Next.js) | Репозиторий с историей коммитов, .env, доступ к CI/CD | Часть переменных окружения хранится только в памяти прежнего разработчика |
| Telegram-бот на aiogram | Токен бота, доступ к серверу с ботом, база подписчиков | Смена токена без предупреждения обрывает вебхук, бот перестаёт отвечать |
| Автоматизация в n8n | Экспорт workflow, доступы ко всем подключённым сервисам | Учётные данные хранятся в самом n8n и не экспортируются вместе со сценарием |
Отдельно про ботов и автоматизации: если у вас Telegram-бот на обработке заявок, смена токена «на всякий случай» ломает вебхук мгновенно, а клиенты об этом узнают раньше вас - просто бот перестаёт отвечать. Токен меняют только тогда, когда есть основания подозревать его утечку, и делают это synchronно с обновлением вебхука на новом сервере.
Частые ошибки при смене подрядчика по сайту
За годы работы с чужими проектами вижу одни и те же грабли:
- Передача без тестового периода. Новый исполнитель разворачивает копию сайта и сразу переключает домен, не прогнав хотя бы базовые сценарии - оформление заказа, отправку формы, работу интеграций.
- Забытые cron-задачи. На старом сервере работал скрипт, который раз в сутки синхронизировал остатки товаров с 1С или обновлял курс валют - после переезда про него просто забывают, и через неделю каталог начинает расходиться с реальными остатками.
- Смена SMTP без проверки. Почтовые уведомления о заказах перестают приходить, потому что на новом сервере не настроена отправка почты или не прописаны SPF/DKIM записи - письма улетают в спам или не отправляются вовсе.
- Один комплект доступов на всех. Старый администратор входит по тому же паролю, что и все остальные, и никто не меняет учётки после расставания с подрядчиком.
- Отсутствие технического задания на передачу. Без письменного акта приёма-передачи со списком доступов и работающих модулей потом сложно доказать, что именно и в каком состоянии было получено.
Если своими силами провести аудит и миграцию сложно - по объёму работы это обычно ближе к полноценному техническому проекту, чем к разовой консультации. Разработка сайта на WordPress с нуля у меня стоит от 60 000 ₽, а разовый аудит и приёмка проекта от прежнего подрядчика можно заказать отдельно как консультацию от 3 000 ₽ - часто этого достаточно, чтобы понять реальное состояние кода и доступов до подписания акта.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Сколько по времени занимает смена подрядчика по сайту?
Аудит и сбор доступов обычно укладываются в 2-3 дня при условии, что прежний исполнитель на связи. Сама миграция на новый хостинг с проверкой всех интеграций занимает от одного до пяти рабочих дней в зависимости от сложности проекта - простой сайт-визитка на Tilda переезжает за пару часов, интернет-магазин с эквайрингом и складской интеграцией требует полноценного тестового прогона перед переключением.
Можно ли сменить подрядчика, если сайт делали без документации?
Можно, но это увеличивает время аудита минимум вдвое - новому исполнителю приходится восстанавливать логику работы по коду, а не по описанию. В таких случаях я сначала делаю технический аудит с описанием архитектуры и только после этого берусь за доработки, иначе есть риск сломать интеграцию, о существовании которой никто не предупредил.
Что делать, если старый подрядчик не отдаёт доступы?
Если сайт и домен официально принадлежат вам (а не оформлены на аккаунт разработчика), теоретически можно восстановить доступ через регистратора домена и хостинг-провайдера по документам о владении. На практике проще сразу прописывать в договоре с любым подрядчиком пункт о передаче полного комплекта доступов по завершении работ - это снимает большинство конфликтов при расставании.
Нужно ли предупреждать пользователей о миграции сайта?
При грамотной схеме с понижением TTL и staging-копией простой обычно не превышает нескольких минут, и отдельное предупреждение не требуется. Исключение - интернет-магазины с активными заказами: миграцию стоит планировать на период минимальной нагрузки и заранее сообщить постоянным клиентам о возможных технических работах, если ожидается пауза в приёме оплат дольше 15-20 минут.