Передача сайта новой команде поддержки — это не пересылка логина от административной панели. Нужно передать контроль над доменом, хостингом, кодом, базой данных, интеграциями, аналитикой и резервными копиями, а затем проверить, что новые специалисты действительно могут обслуживать проект.
Плохая передача проявляется не сразу. Сайт может работать ещё несколько месяцев, пока не понадобится продлить домен, восстановить копию, изменить интеграцию или найти исходники. Чтобы смена подрядчика не привела к потере данных и зависимости от бывшего исполнителя, процесс лучше провести по чек-листу.
Содержание:
Главный принцип: владельцем должна оставаться компания
Домены, хостинг, лицензии, рекламные кабинеты и репозитории следует регистрировать на компанию или её уполномоченного сотрудника. Подрядчику выдаётся необходимый уровень доступа, но он не должен оставаться единственным владельцем критичной учётной записи.
Если домен оформлен на бывшего разработчика, а код хранится только в его личном аккаунте, технически сайт не находится под полным контролем бизнеса. Исправлять такую ситуацию лучше до конфликта или аварии.
Что нужно передать
| Объект | Что проверить | Кто должен владеть |
|---|---|---|
| Домен | Регистратор, контакт, срок продления, DNS | Компания-заказчик |
| Хостинг или сервер | Панель, SSH/SFTP, база, резервные копии | Компания или согласованный корпоративный аккаунт |
| CMS | Администраторские учётные записи и роли | Компания |
| Код | Актуальный репозиторий, ветки и история | Организация или корпоративный аккаунт |
| Интеграции | API-ключи, вебхуки, контакты второй стороны | Компания |
| Аналитика | Метрика, Analytics, Tag Manager, цели | Компания |
| Лицензии | CMS, плагины, модули и сроки | Компания либо прозрачно описанный партнёрский договор |
| Документация | Архитектура, инструкции, история решений | Общее корпоративное хранилище |
Шаг 1. Проведите инвентаризацию
До отключения старой команды составьте карту всех систем. Источник информации — договоры, счета, письма, DNS-записи, код сайта, административная панель и браузерные запросы. Важно найти не только очевидные сервисы, но и фоновые интеграции.
- регистратор домена и DNS-провайдер;
- хостинг, облако, CDN и почтовый сервис;
- CMS, административные панели и база данных;
- Git-репозиторий и процесс размещения изменений;
- 1С, CRM, платёжные системы, доставки и телефония;
- Яндекс Метрика, Google Analytics, Tag Manager и рекламные пиксели;
- сервисы рассылок, чатов, карт, отзывов и CAPTCHA;
- лицензии модулей, плагинов, шрифтов и изображений;
- тестовый сайт и промежуточные окружения.
Результатом должна стать таблица: сервис, адрес входа, владелец, ответственный, назначение, срок оплаты и уровень критичности. Пароли в обычной таблице хранить не следует — для них используется менеджер паролей.
Шаг 2. Создайте полную резервную копию
Перед любыми изменениями доступов создаётся независимая копия файлов и базы данных. Если сайт принимает заказы или заявки, нужно определить момент фиксации данных, чтобы во время передачи ничего не потерялось.
- архив актуальных файлов сайта;
- экспорт базы данных;
- копия пользовательских загрузок и документов;
- конфигурация сервера и расписание фоновых заданий;
- DNS-записи и почтовые настройки;
- экспорт настроек аналитики, если это возможно;
- проверка, что копия открывается и может быть восстановлена.
Бэкап желательно хранить не только на том же сервере. Если проблема затронет аккаунт хостинга, копия внутри него может стать недоступной вместе с сайтом.
Шаг 3. Передайте код и историю изменений
Архив текущей версии полезен, но он не заменяет Git-репозиторий. История коммитов показывает, зачем вносились изменения, какие файлы связаны и как разворачивался проект. Новая команда должна получить актуальную версию, соответствующую рабочему сайту.
Нужно проверить основную ветку, незавершённые изменения, инструкции по сборке, переменные окружения, зависимости и процесс выпуска. Секреты не хранятся в репозитории открытым текстом — они передаются через защищённый канал и затем заменяются.
Шаг 4. Соберите техническую документацию
Идеальная документация бывает редко. Для начала достаточно описать архитектуру, ключевые интеграции, процедуру развёртывания и критичные сценарии. Полезнее актуальные десять страниц, чем старое техническое задание на сотни страниц, которое не соответствует текущему сайту.
- структура проекта и используемые технологии;
- назначение нестандартных модулей и плагинов;
- схема обмена с 1С, CRM и внешними API;
- процесс размещения изменений;
- процедура резервного копирования и восстановления;
- расписание cron, агентов и очередей;
- описание ролей пользователей;
- известные ошибки, технический долг и временные решения;
- контакты провайдеров и ответственных специалистов.
Шаг 5. Передавайте доступы безопасно
Не стоит отправлять все пароли одним письмом или в общем чате. Используйте корпоративный менеджер паролей, временные ссылки либо защищённый канал. Где возможно, создавайте отдельные учётные записи вместо передачи одного общего администратора.
Для каждого участника выдаётся минимально необходимый уровень прав. Действия администраторов желательно журналировать, а критичные аккаунты защищать двухфакторной аутентификацией.
Шаг 6. Проведите встречу по передаче знаний
Документы не отвечают на все вопросы. Старая команда должна показать архитектуру, процесс релиза, нестандартные места и типовые аварии. Встречу полезно записать и дополнить итоговым протоколом.
- как локально или на тестовом сервере запустить проект;
- как размещаются изменения на продакшене;
- какие функции нельзя менять без расширенного тестирования;
- где находятся логи и мониторинг;
- как диагностировать основные интеграции;
- какие задачи не завершены;
- какие риски известны старой команде.
Если бывший подрядчик недоступен, новая команда восстанавливает эту информацию через аудит. Это занимает время, поэтому передачу лучше начинать до завершения старого договора.
Шаг 7. Проверьте критичные сценарии
После получения доступов новая команда должна не просто войти в панели, а выполнить контрольные действия. Для магазина это создание заказа, применение скидки, переход к оплате и передача в учётную систему. Для корпоративного сайта — отправка всех типов форм и появление лида в CRM.
| Что проверить | Пример результата |
|---|---|
| Сайт и административная панель | Открываются без ошибок, права соответствуют ролям |
| Формы и уведомления | Заявка приходит ответственному и фиксируется в CRM |
| Заказ и оплата | Корректно рассчитываются сумма и статус |
| Интеграции | Данные уходят и возвращаются без ошибок |
| Резервная копия | Создаётся и может быть восстановлена |
| Развёртывание | Тестовое изменение проходит согласованный путь |
| Аналитика | Основные события и конверсии продолжают поступать |
Шаг 8. Измените доступы после приёмки
Сначала новая команда подтверждает, что всё необходимое получено и работает. После этого отзываются учётные записи бывших сотрудников и подрядчиков, меняются общие пароли, API-ключи и при необходимости SSH-ключи. Резкая смена доступов до проверки может заблокировать получение недостающих данных.
Особенно внимательно нужно обращаться с платёжными системами, почтой, DNS и интеграциями. Замена ключа без обновления на сайте приведёт к остановке функции.
Как не потерять SEO и аналитику
- не менять URL, DNS и структуру сайта без отдельной необходимости;
- сохранить доступы к Яндекс Вебмастеру, Search Console и аналитике;
- зафиксировать действующие редиректы, robots.txt и sitemap.xml;
- проверить цели, электронную коммерцию и рекламные события;
- сохранить историю мониторинга позиций и отчётов;
- проверить работу счётчиков после любых технических изменений.
Сама смена команды не требует миграции сайта или переделки структуры. Чем меньше технических изменений совмещено с передачей, тем проще определить причину возможного сбоя.
Что делать, если подрядчик не отдаёт доступы
Сначала нужно определить юридического владельца домена, хостинга и лицензий, изучить договор и собрать подтверждения оплаты. Часто доступ можно восстановить через корпоративную почту или службу поддержки провайдера. Если аккаунт оформлен на третье лицо, вопрос может потребовать юридического урегулирования.
Параллельно следует сохранить всё, к чему компания ещё имеет доступ: файлы, базу, контент, аналитические данные и документацию. Не нужно пытаться ломать чужие аккаунты или обходить ограничения — восстановление проводится через официальные процедуры.
Приёмочный чек-лист
- компания контролирует домен и DNS;
- получен доступ к хостингу, серверу и базе;
- создана и проверена независимая резервная копия;
- репозиторий актуален и принадлежит корпоративному аккаунту;
- переданы лицензии и интеграции;
- описан процесс размещения изменений;
- проверены формы, заказы, оплата и обмены;
- аналитика продолжает получать данные;
- составлен список известных проблем и ближайших задач;
- старые доступы отозваны после завершения приёмки.
Как German Web принимает сайт на поддержку
Сначала мы запрашиваем ссылку, список задач и доступные сведения о технологиях. Затем проверяем доступы, код, резервирование, интеграции и критичные сценарии. Если проект небольшой и понятный, можно перейти к первой задаче. Для сложной системы или плохого чужого кода может потребоваться отдельный платный аудит.
После знакомства выбирается разовый или абонентский формат, согласуются приоритеты и SLA. Состав работ описан в статье о технической поддержке, а условия — на странице поддержки и развития сайтов.
Частые вопросы
Нужно ли отключать старую команду сразу?
Нет. Сначала новая команда должна получить и проверить доступы, код, копии и документацию. Старые учётные записи отзываются после приёмки, если нет угрозы безопасности.
Достаточно ли архива файлов сайта?
Нет. Нужны база данных, пользовательские загрузки, конфигурация, репозиторий, доступы к инфраструктуре и сведения об интеграциях.
Кто должен владеть доменом и хостингом?
Лучше, чтобы владельцем была компания-заказчик или её корпоративный аккаунт. Подрядчику выдаются необходимые права без передачи полного контроля над активом.
Можно ли принять сайт без исходного технического задания?
Да. Новая команда может изучить рабочую систему и восстановить документацию. Для сложного проекта это обычно отдельный этап аудита.
Когда менять пароли и API-ключи?
После проверки передачи, но без неоправданной задержки. Сначала нужно убедиться, что известны все места использования ключей, иначе связанная функция может остановиться.
Нужно ли переносить сайт на другой хостинг при смене команды?
Не обязательно. Если текущая инфраструктура подходит и компания её контролирует, смена подрядчика может пройти без миграции и дополнительных рисков.
