Как сменить подрядчика по сайту и не потерять доступы, данные и рекламу

Безопасная смена подрядчика начинается с инвентаризации: какие системы поддерживают сайт, кто управляет их аккаунтами и что нужно для восстановления. Передача архива и пароля от CMS не завершает процесс. Новая команда должна проверить доступы, работоспособность проекта и связанные каналы заявок до отзыва прежних полномочий.

Не совмещайте передачу с необязательным редизайном, переездом и заменой рекламных кабинетов. Чем больше одновременных изменений, тем сложнее найти причину сбоя. Сначала примите существующий проект в проверяемом состоянии, затем согласуйте отдельную очередь развития. При аварии действия определяют по её масштабу, а не по этому обычному плану.

Назначьте владельца передачи со стороны компании

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

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

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

Составьте реестр систем и полномочий

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

В статье Олега Родина о смене подрядчика подчёркивается независимое управление ключевыми ресурсами и наличие копий. Для приёмки полезно проверить не обещание «всё ваше», а конкретное действие: может ли уполномоченный сотрудник восстановить вход без личного телефона бывшего исполнителя.

Проверьте резервную копию восстановлением

Уточните состав копии: файлы, база, пользовательские загрузки и необходимые параметры окружения. Архив кода без актуальных данных не является полной копией работающего магазина. Секретные настройки храните защищённо и отдельно от общедоступной документации. Не публикуйте их в репозитории ради удобства передачи.

Разверните проект в изолированной среде по согласованной инструкции. Заблокируйте отправку реальных писем, клиентских уведомлений и платёжных действий из тестовой копии. Проверьте, что она не запускает штатные фоновые задачи на реальных данных и не становится публичным дублем сайта в поиске.

Сравните восстановленную версию с согласованным состоянием рабочего проекта: страницы, медиафайлы, формы, роли и нужные интеграционные настройки. Отдельно зафиксируйте дату данных. Копия недельной давности может запускаться без ошибок, но не содержать последние заказы и изменения каталога.

Передайте код вместе со способом выпуска изменений

Новой команде нужны актуальный репозиторий, зависимости, порядок настройки окружения и инструкция выпуска. Сверьте, нет ли исправлений только на рабочем сервере, отсутствующих в истории кода. Такие различия нужно описать и согласованно сохранить, а не стирать первым обновлением из репозитория.

В руководстве UP по передаче сайта в реестр включены сборка, интеграции и фоновые задания. Для вашего проекта составьте собственную карту зависимостей. Особое внимание уделите тому, что не видно на странице: плановому импорту, отправке почты, сертификатам, платёжным обработчикам и автоматическому продлению сервисов.

Попросите описание нестандартных доработок и ограничений обновления. Не требуйте идеальной документации всего проекта перед любым действием, но выделите критичные участки. Для каждого полезны назначение, расположение, зависимые сервисы и контрольный сценарий. Это ускорит первый безопасный выпуск новой команды.

Сохраните рекламу и историю измерений

Проверьте роли в рекламных кабинетах, аналитике, системах коллтрекинга и CRM. Передача управления не обязательно требует создания новых аккаунтов. Если перенос действительно нужен, отдельно согласуйте сохранение истории, идентификаторов, оплат и непрерывности измерения, учитывая правила конкретного сервиса.

Сверьте активные объявления, посадочные, фиды и цели. После смены доступов проведите помеченную тестовую заявку с известным источником. Она должна дойти до получателя, появиться в учёте и не потерять доступные метки. Для проверки используйте цепочку от визита до CRM.

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

Разведите консультационную передачу и изменение сайта

Старая и новая команды могут одновременно обсуждать устройство проекта, но выпуск изменений должен иметь одного согласованного координатора. Запишите, кто имеет право менять рабочий сайт в переходный период и как согласуется исключение. Иначе два независимых исправления способны перезаписать друг друга.

Условный пример: старая команда завершает настройку обмена, а новая меняет шаблон заказа. До выпуска нужно понять, пересекаются ли обработчики и как проверить итог. Само присутствие двух подрядчиков не является ошибкой; опасно отсутствие единого порядка изменений и известной рабочей версии.

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

Завершите передачу контрольным протоколом

Проверьте сайт как посетитель, отправьте тестовую форму, проверьте доставку письма и появление записи в CRM. Для магазина добавьте каталог, корзину и согласованный тест оплаты. Убедитесь, что резервное копирование и мониторинг продолжают работать, а не просто были настроены когда-то прежней командой.

В итоговом документе оставьте переданные объекты, результаты проверок, нерешённые вопросы и ответственных. Отдельно перечислите отозванные доступы и оставленные временно с датой пересмотра. Это полезнее фразы «сайт передан полностью», которая не показывает состояние отдельных зависимостей.

Если одновременно требуется перенос платформы, используйте отдельный план переезда с контролем SEO. Для обычной эксплуатации закрепите план обслуживания сайта: кто принимает задачи, проверяет выпуск и отвечает на сбой.

Вопросы о смене подрядчика

Достаточно доступа администратора CMS?

Нет. Он не заменяет управление доменом, сервером, копиями, рекламой и внешними сервисами. Составьте реестр зависимостей и проверьте каждую отдельно, включая возможность восстановления корпоративного доступа.

Нужно сразу менять все пароли?

Сначала определите связанные сервисы и план передачи. По завершении приёмки отзовите ненужные полномочия и согласованно замените секреты. При подтверждённом компрометировании действует отдельный план реагирования, где приоритетом становится ограничение угрозы.

Когда передачу можно считать завершённой?

Когда компания управляет ключевыми аккаунтами, новая команда проверила восстановление и выпуск, критичные сценарии работают, а оставшиеся вопросы зафиксированы с ответственными. Один полученный архив или устное подтверждение этого не доказывают.

Источники и дополнительные материалы

• Олег Родин: как сменить подрядчика по сайту
• UP: передача сайта другому разработчику