Главная › Блог › Как передать сайт другой студии без потери контроля: чек-лист

Как передать сайт другой студии без потери контроля: чек-лист

4 августа 2026 · 16 мин чтения

Передача сайта другой студии — это управляемая смена ответственности, а не пересылка архива и пароля от административной панели.

В согласованный момент одна команда должна прекратить изменять production, новая — получить проверяемый контроль над нужными системами, а клиент — сохранить владение доменом, данными, кодом, инфраструктурой и каналами восстановления.

Без процедуры обычно возникают две опасные зоны:

старая студия уверена, что уже ни за что не отвечает;
новая студия ещё не может безопасно восстановить сайт, изменить DNS или разобраться в алерте.

Хорошая передача закрывает этот промежуток документом, контрольными проверками и точным временем смены ответственности.

Коротко

Безопасный offboarding состоит из десяти этапов:

письменно определить состав передачи и момент смены ответственности;
сверить все активы, контуры, зависимости и владельцев;
подготовить актуальные копии кода, данных и документации;
передать owner-права и создать индивидуальные аккаунты новой команды;
провести совместную техническую сессию;
проверить сайт, критические пути, алерты и восстановление;
зафиксировать открытые риски, инциденты и временные меры;
получить подтверждение приёма конкретных объектов;
отозвать доступы старой студии и ротировать общие секреты;
сохранить доказательства передачи и закрыть платные ресурсы по согласованию.

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

Что именно передаётся

У сайта нет одной кнопки «передать всё». Даже небольшой проект может включать:

домен и аккаунт регистратора;
DNS;
корпоративную почту владельца;
CDN/WAF;
хостинг или облако;
виртуальные машины и контейнеры;
панель управления;
CMS;
базу данных;
пользовательские загрузки;
репозитории;
CI/CD;
package registry и образы;
cron и очереди;
резервные копии;
SSL-сертификаты;
1С и обмен;
CRM и формы;
платёжные и почтовые сервисы;
аналитику, рекламные кабинеты и теги;
мониторинг;
статус-страницу;
Helpdesk и историю инцидентов;
лицензии и подписки;
инструкции, исключения и принятые риски.

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

Четыре стороны передачи

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

Роль	Ответственность
Клиент-владелец	Подтверждает владение, границы, уполномоченных лиц и итоговый приём
Передающая студия	Готовит фактическое состояние, материалы, доступы и открытые риски
Принимающая студия	Проверяет полученное и сообщает о пробелах до точки передачи
Координатор	Ведёт реестр объектов, решения, сроки и итоговый протокол

Координатором может быть аккаунт-менеджер клиента или одной из студий. Важно, чтобы у него было право собирать подтверждения, но он не должен единолично объявлять технический объект принятым без проверки специалиста.

Дополнительно могут потребоваться:

владелец домена;
системный администратор;
специалист по 1С;
бухгалтерия по лицензиям;
security-контакт;
юрист для договорных формулировок;
поставщик хостинга или облака.

Сначала зафиксируйте точку смены ответственности

Фраза «передадим сайт до пятницы» создаёт неопределённость.

Запишите:

дату и время в одном часовом поясе;
какие объекты переходят в этот момент;
что остаётся у прежней команды временно;
кто принимает P1 до и после точки;
кто одобряет экстренное изменение;
действует ли окно совместного наблюдения;
какой канал используется при сбое;
что произойдёт, если критический объект не проверен;
кто может перенести точку передачи.

Пример:

Точка передачи production: 20 августа 2026 года, 12:00 МСК.

До 12:00 передающая студия остаётся первичным исполнителем по P1.
С 12:00 первичную реакцию выполняет принимающая студия.
Передающая команда доступна для консультации до 27 августа в рабочие часы,
но не меняет production без запроса и письменного подтверждения координатора.

Если к 18 августа не подтверждены owner-доступ к DNS и восстановление бэкапа,
координатор отдельно решает, переносить ли точку передачи.

Это операционный пример, а не готовая юридическая формулировка. Договорные последствия и ответственность проверяются сторонами отдельно.

Статусы объектов передачи

Для каждого элемента используйте одинаковые статусы:

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

«Ссылка отправлена» — не синоним «доступ проверен».

План передачи по времени

За 10–15 рабочих дней

назначить координатора;
согласовать состав и формат;
создать реестр объектов;
зафиксировать точку смены ответственности;
определить окно заморозки опасных изменений;
начать поиск неизвестных владельцев;
проверить возможность экспорта и передачи лицензий;
определить безопасный канал секретов;
согласовать участие внешних поставщиков.

За 5 рабочих дней

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

За 1–2 рабочих дня

остановить необязательные изменения;
проверить owner-права клиента;
подтвердить каналы P1;
выполнить контрольный релиз или безопасную проверку deploy, если входит в план;
протестировать алерт и его получение;
подготовить финальный снимок состояния;
отметить блокеры.

В точке передачи

зафиксировать время;
подтвердить состояние production;
передать первичную роль по инцидентам;
убедиться, что новая команда видит мониторинг и Helpdesk;
записать незакрытые пункты;
запретить несогласованные изменения старой командой.

После передачи

отозвать права старой студии;
завершить сессии и токены;
ротировать общие секреты;
перепроверить monitoring и каналы;
снять ненужные платные ресурсы;
завершить удаление или возврат данных по принятой процедуре;
провести контроль через 1–7 дней;
закрыть реестр только после доказательств.

Готовый реестр передачи

Скопируйте таблицу в Markdown, Helpdesk или рабочую базу.

| ID | Объект | Текущий владелец | Новый владелец | Способ передачи | Проверка | Статус | Риск/комментарий | Подтвердил | Дата |
|---|---|---|---|---|---|---|---|---|---|
| TR-001 | Домен example.ru | Клиент | Клиент | Делегированная роль новой студии | Вход, просмотр срока, тест без изменения | | | | |
| TR-002 | DNS-зона | Передающая студия | Клиент | Экспорт + новая роль | Сверка записей и контроль разрешения | | | | |
| TR-003 | Репозиторий | Передающая студия | Клиент/новая студия | Transfer/mirror | Clone, branches, tags, CI refs | | | | |
| TR-004 | Production | Клиент | Клиент | Индивидуальные аккаунты | Вход и разрешённая диагностика | | | | |
| TR-005 | Бэкап | Хостинг | Клиент | Доступ к хранилищу | Тестовое восстановление | | | | |
| TR-006 | Pingvera | Передающая студия | Клиент/новая студия | Новая роль или воссоздание профиля | Тестовый алерт | | | | |

Добавьте фильтры по критичности, владельцу и блокирующему статусу.

Полный Markdown-шаблон акта технической передачи

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

---
project_id: "WEB-0000"
project_name: ""
production_url: ""
handover_at: "YYYY-MM-DD HH:MM TZ"
coordinator: ""
outgoing_team: ""
incoming_team: ""
document_status: "draft"
---

# Протокол технической передачи проекта [название]

## 1. Стороны и роли

- Владелец со стороны клиента:
- Передающая команда:
- Принимающая команда:
- Координатор:
- Технические подтверждающие лица:
- Канал P1 во время перехода:

## 2. Граница и момент ответственности

- Точка передачи:
- До точки передачи отвечает:
- После точки передачи отвечает:
- Период консультаций:
- Запрещённые изменения:
- Условия переноса:

## 3. Состав передачи

| Объект | Владелец | Передано | Проверено | Результат | Открытый риск |
|---|---|:---:|:---:|---|---|
| Домен и регистратор | | | | | |
| DNS | | | | | |
| Хостинг/облако | | | | | |
| Код и репозитории | | | | | |
| CI/CD | | | | | |
| CMS | | | | | |
| База и файлы | | | | | |
| Бэкапы | | | | | |
| Интеграции | | | | | |
| Мониторинг | | | | | |
| Документация | | | | | |

## 4. Контрольные проверки

| Проверка | Ожидаемый результат | Фактический результат | Время | Проверил |
|---|---|---|---|---|
| Production открывается | | | | |
| Критический путь 1 | | | | |
| Форма/заказ | | | | |
| Фоновая задача | | | | |
| Алерт доставлен | | | | |
| Бэкап доступен | | | | |
| Restore test | | | | |

## 5. Открытые задачи и риски

| ID | Описание | Влияние | Временная мера | Владелец | Срок |
|---|---|---|---|---|---|
| | | | | | |

## 6. Доступы

> Значения секретов в документ не включаются.

| Система | Новый владелец | Роль принимающей команды | MFA | Vault ref | Старый доступ отозван | Проверил |
|---|---|---|:---:|---|:---:|---|
| | | | | | | |

## 7. Данные и материалы

- Что передано:
- Формат:
- Контрольная сумма/версия при необходимости:
- Где хранится:
- Кто получил:
- Что остаётся у передающей стороны:
- Срок и способ удаления/возврата:

## 8. Итог

- Принято:
- Принято с рисками:
- Не принято:
- Следующая контрольная дата:
- Подтверждение клиента:
- Подтверждение передающей команды:
- Подтверждение принимающей команды:

Передача домена и DNS

Это самый чувствительный участок. Ошибка может сделать недоступными сайт и почту или передать контроль третьей стороне.

Проверьте:

на кого зарегистрирован домен;
актуальны ли контактные данные;
кто оплачивает продление;
где находится recovery-почта;
включена ли MFA;
поддерживает ли регистратор роли;
есть ли блокировка переноса;
какие DNS-серверы авторитетны;
сохранён ли экспорт зоны;
есть ли DNSSEC и кто владеет ключевыми операциями;
какие записи связаны с почтой, проверками и внешними сервисами;
кто может выполнить экстренный откат.

Предпочтительно оставить owner-аккаунт у клиента и выдать новой студии делегированную роль. Если платформа не поддерживает роли, зафиксируйте временный риск и безопасную процедуру общей учётной записи.

Не меняйте владельца, DNS-провайдера и записи одновременно без необходимости. Разделяйте операции и подтверждайте каждую.

Передача кода и репозиториев

Архив текущей версии сайта недостаточен. Новой команде могут понадобиться:

полный Git-репозиторий;
ветки и теги;
история релизов;
submodule и внешние зависимости;
package registry;
инструкции сборки;
конфигурация CI/CD без раскрытия ненужных секретов;
правила веток и review;
список deploy-ключей;
информация о лицензиях;
соответствие commit и production;
незавершённые миграции;
известные расхождения между кодом и сервером.

Контрольная проверка:

новая команда клонирует репозиторий;
разворачивает локальный или тестовый контур;
выполняет сборку;
проверяет миграции;
сопоставляет версию с production;
делает безопасный тестовый deploy или dry run по согласованному сценарию.

Секреты из CI/CD не копируются в код. Создаются новые значения или безопасно передаются отдельным процессом.

Передача инфраструктуры

Зафиксируйте:

аккаунт и организацию облака;
проекты, подписки и плательщика;
регионы;
серверы, сети, firewall и балансировщики;
базы и хранилища;
DNS и сертификаты;
cron, очереди и worker;
логи и сроки хранения;
резервные копии;
инфраструктуру как код;
ручные изменения;
квоты, лимиты и будущие списания;
контакты поддержки провайдера.

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

Передача базы и пользовательских данных

До экспорта определите:

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

Не передавайте production-дамп ссылкой без контроля доступа. Не загружайте реальные персональные данные в тестовый контур без отдельного основания и защиты.

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

Передача бэкапов и восстановления

Передайте не только архив, но и доказательство процесса:

что входит в копию;
расписание;
место хранения;
срок хранения;
владелец ключа шифрования;
фактический доступ;
RPO/RTO;
последняя успешная копия;
последняя проверка восстановления;
совместимые версии среды;
пошаговый runbook;
известные исключения.

Лучшее подтверждение — тестовое восстановление в изолированной среде, выполненное принимающей командой или совместно.

Передача интеграций

Для каждой интеграции запишите:

владельца аккаунта;
направление данных;
endpoints;
сервисный аккаунт;
scopes;
срок токена;
IP или сетевые ограничения;
подпись webhook;
тестовый сценарий;
алерт;
процедуру ротации;
что произойдёт при отказе.

Особое внимание:

1С;
CRM;
платежи;
доставка;
SMTP и корпоративная почта;
антиспам и CAPTCHA;
аналитика;
внешняя авторизация;
callback и webhook.

Не просите новую команду проверять платёж реальной банковской картой без согласованного безопасного сценария.

Передача мониторинга и инцидентной истории

Новая студия должна знать:

какие функции наблюдаются;
какие пороги и подтверждения используются;
какие исключения приняты;
кто получает P1;
какие плановые окна действуют;
какие проблемы повторялись;
какие действия из postmortem не закрыты;
где находятся клиентские отчёты;
как проверить резервный канал.

Проведите тестовое событие и попросите нового дежурного:

получить уведомление;
открыть карточку проекта;
определить критичность;
подтвердить приём;
найти первый безопасный шаг;
назвать канал клиента.

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

Доступы: выдача, проверка, отзыв

Используйте матрицу безопасных доступов.

Правильная последовательность:

клиент подтверждает владельца;
новой команде создаются индивидуальные роли;
доступ проверяется;
сервисные аккаунты переводятся на нового владельца;
общие секреты ротируются;
доступ старой команды отзывается;
активные сессии завершаются;
токены, SSH-ключи и recovery проверяются отдельно;
факт отзыва подтверждается из системы;
матрица обновляется.

Не удаляйте старую команду до проверки аварийного доступа новой, если это создаёт риск полной потери управления. Но и не оставляйте бесконечный «временный» доступ после завершения консультационного окна.

Что передать о текущем состоянии

Снимок состояния на момент передачи включает:

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

Не называйте неизвестное исправным. Формулировка «не проверено» честнее и полезнее зелёной ячейки без доказательства.

Контрольная техническая сессия

План на 90 минут:

Время	Этап	Результат
0–10 мин	Границы и владельцы	Все понимают точку передачи
10–25 мин	Архитектура и зависимости	Новая команда видит критический контур
25–45 мин	Доступы	Выполнены безопасные входы
45–60 мин	Релиз и восстановление	Найдены инструкции и ограничения
60–75 мин	Мониторинг и инциденты	Проверены сигналы и эскалация
75–85 мин	Риски	Назначены владельцы пробелов
85–90 мин	Итог	Зафиксированы решения и следующий контроль

Не тратьте встречу на чтение документов вслух. Материалы передаются заранее, а сессия проверяет действие и неизвестное.

Критерии готовности

Передача может считаться технически завершённой, когда:

[ ] владелец каждого критического объекта установлен;
[ ] новая команда имеет проверенные индивидуальные роли;
[ ] клиент контролирует owner/recovery критических систем;
[ ] код клонируется и собирается;
[ ] production соответствует известной версии или расхождение записано;
[ ] критические пути проверены;
[ ] бэкап доступен и процедура восстановления понятна;
[ ] мониторинг и резервный канал работают;
[ ] открытые риски имеют владельцев;
[ ] ответственность передана в согласованное время;
[ ] права старой команды отозваны;
[ ] общие секреты ротированы по оценке риска;
[ ] временные копии и данные обработаны по процедуре;
[ ] итоговый протокол подтверждён.

Незакрытый некритичный пункт может быть принят как риск. Неизвестный владелец DNS или отсутствие контроля над owner-аккаунтом — обычно блокер, а не косметический комментарий.

Частые ошибки

Передают только ZIP и дамп

Без истории, сборки, инфраструктуры, интеграций и владельцев это аварийная копия, а не проект.

Секреты отправляют одним письмом

Письмо копируется, пересылается и остаётся в архивах. Используйте защищённое хранилище и индивидуальные роли.

Сразу удаляют старую команду

Новая ещё не проверила recovery. Сначала контролируемая выдача и проверка, затем отзыв по точке передачи.

Старую команду не удаляют никогда

«На всякий случай» превращается в постоянный неучтённый доступ. Ограничьте консультационное окно и завершите offboarding.

Скрывают технический долг

Новая команда обнаруживает его при первом P1, а клиент получает спор вместо реакции. Риски нужно назвать заранее.

Не передают мониторинг

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

Не учитывают лицензии и оплату

После передачи прекращается CDN, хостинг или модуль. Укажите плательщика, срок и владельца продления.

Нет точного времени ответственности

Первый инцидент превращается в спор двух студий. Зафиксируйте часовой пояс, primary и резерв.

Как помогает Pingvera

Pingvera может дать фактический слой для передачи:

список наблюдаемых сайтов и функций;
состояние критических проверок в момент перехода;
историю доступности и событий;
данные по SSL, домену, формам и внутренним сигналам;
клиентские отчёты;
проверку нового маршрута уведомлений;
контроль после смены DNS, хостинга или ответственной команды.

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

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

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

Часто задаваемые вопросы

Обязана ли старая студия передать весь исходный код?

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

Можно ли передавать пароли через Telegram?

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

Кто должен владеть доменом после передачи?

Обычно owner остаётся у клиента, а новой студии выдаётся делегированная роль. Фактическое владение проверяется у регистратора и в договорных документах.

Нужен ли период параллельной поддержки?

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

Когда отзывать доступ старой студии?

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

Что делать, если часть документации отсутствует?

Зафиксировать отсутствие как риск, определить минимально необходимое восстановление знания и назначить владельца. Нельзя молча отметить объект принятым.

Нужно ли передавать историю всех алертов?

Передайте объём, необходимый для понимания повторяющихся проблем, обязательств и текущего риска. Формат, срок и допустимость передачи данных согласуются отдельно.

Кто подписывает технический протокол?

Люди, уполномоченные сторонами подтвердить конкретные факты и приём. Если протокол становится юридически значимым актом, порядок устанавливается договором и проверяется специалистами.

Главное

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

Рабочая формула:

инвентаризация → безопасная выдача → проверка → точка ответственности → отзыв → контроль

Она защищает обе студии и, главное, не оставляет бизнес клиента между двумя зонами ответственности.

Источники и дополнительное чтение

Следующий материал курса: «Мониторинг как код для веб-студии: когда он нужен и как внедрить без массовых ошибок».

Узнавайте о проблеме раньше клиента

Pingvera следит за сайтами клиентов «снаружи и изнутри» — доступность из регионов, формы, оплата, домен, SSL, сервер — и предупреждает в Telegram, email и Max раньше, чем напишет клиент.

Попробовать Pingvera бесплатно

← Все статьи · Политика конфиденциальности · pingvera.ru · Telegram-канал