Сайт "держит" один подрядчик: админка, root и лицензия Битрикс - у него. Уведомили об уходе - и страх остаться без входа, без отката и с молчащими формами. Как сменить подрядчика по поддержке сайта без простоя: за день пройдёте чек-лист передачи на 1С-Битрикс - доступы на себя, лицензия, staging и бэкап, акт, затем онбординг новой команды 1-2 недели.
Смена подрядчика по поддержке сайта на 1С-Битрикс - управляемая передача живого CMS-проекта: изъятие и переоформление доступов и лицензии на заказчика, проверка бэкапа и staging, акт передачи с прекращением доступа старой команды и онбординг нового подрядчика без простоя критичных сценариев вроде форм и обмена с 1С. Сегодня соберите таблицу доступов и сверьте владельца ключа. Не расторгайте договор, пока ownership не у вас.
Речь только про CMS "1С-Битрикс: Управление сайтом" на вашем хостинге. Это не облачная CRM Bitrix24. Соседние темы не дублируем: поддержка и SLA - после смены; состав пакета ТП - у нового подрядчика; приёмка до акта на сдаче - другой этап. Здесь - уход от действующей поддержки живого сайта.
Типичная боль и частая проблема: домен на карте менеджера студии, лицензия на ИП подрядчика, root знает один разработчик, который уже уволился. На практике, например, новый подрядчик две недели не может сделать бэкап, заявки с формы молчат. Типичная ошибка - расторгнуть договор до ownership. Результат чек-листа - контроль у вас до расторжения, а не после "пересылки логинов".
Соберите чек-лист доступов до уведомления об уходе
Смена поддержки - не "переслать пароли в чат", а короткий проект передачи контроля. Пока доступы "в голове" у старой команды, после уведомления об уходе рычаг исчезает. Делайте инвентаризацию до расторжения.
| Контур | Что изъять / переоформить | Готово, если |
|---|---|---|
| Домен и DNS | Регистратор, NS, A/MX | Логин и оплата на заказчике |
| Хостинг / VPS | Панель, root/SSH, биллинг | Владелец - вы; пароли сменены |
| Админка CMS | Пользователи bitrix/admin/ | Ваш админ есть; лишние удалены после акта |
| БД и файлы | MySQL, SFTP, путь /local/ | Доступ у вас, не "только у них" |
| Git и деплой | Репозиторий, CI, ключи | Репо на вашем org |
| Аналитика и API | Метрика, SMTP, платежи/CRM | Кабинеты на заказчике |
- Выпишите контуры из таблицы в свой файл (не в чат подрядчика).
- Запросите письмом: хостинг, домен, SSH, БД, админка, Git, SSL, почта, Метрика, платежи; отдельно - cron/агенты и ключи API.
- Войдите сами и смените пароль там, где логин уже ваш.
- Где логина нет - потребуйте переоформление аккаунта на заказчика.
Если сайт на VPS или shared-хостинге, биллинг и панель должны быть вашими. Для Битрикс часто берут хостинг Beget - но смена подрядчика не равна смене хостера: сначала ownership, миграция - только если нужна.
Делайте: полный список до уведомления. Не делайте: ждать "передадим после акта" - после акта мотивация падает.
Переоформите лицензию 1С-Битрикс на заказчика
Из практики: часто ломается сценарий SiteUpdate, если забыли ключ продукта. Если лицензия оформлена на студию, обновления и Marketplace формально не ваши. Вендор допускает однократную уступку прав - через sales@1c-bitrix.ru и бланк с данными нового владельца (FAQ по передаче лицензии).
- Сверьте владельца ключа и "главного пользователя" в кабинете лицензии.
- Если владелец - подрядчик, инициируйте уступку на заказчика до расторжения.
- Сохраните LICENSE_KEY и доступы к обновлениям у себя.
- Проверьте Marketplace updates под вашей учёткой в админке.
- Убедитесь, что SiteUpdate открывается без чужой учётки студии.
- Бета-обновления - только на копии для разработки, не на бою.
Делайте: сверку ключа рядом с доменом. Не делайте: расторгать договор, пока ключ не на вас.
Проверьте staging, бэкап и пробный restore
Staging - тестовая копия сайта, где новая команда смотрит код и обновления без правок на бою. Без неё "войти в проект" часто значит править прод. Документация Битрикс: кастом в /local/, правки - после теста на dev-копии.
- Сделайте свежий бэкап: Настройки → Инструменты → Резервное копирование (dump.php / CBackup) и скопируйте архив offsite к себе.
- Прогоните пробный restore.php на отдельном стенде.
- Разверните или потребуйте staging; вход новой команды сначала туда.
- Зафиксируйте дату бэкапа и факт restore в акте передачи.
Workflow: свежий дамп → offsite у вас → пробный restore → smoke-тест staging → смена паролей на бою. Регулярные копии - в гайде по бэкапу; обновления ядра - в статье про обновление.
Делайте: restore "на словах" не считается. Не делайте: верить "бэкап делает хостинг", если ни разу не поднимали сайт из копии.
Подпишите акт передачи и смените все пароли
Акт передачи сайта и доступов фиксирует: что передано и что доступ старой команды прекращён. Без списка и смены паролей бывший исполнитель (или его уволенный сотрудник) заходит месяцами спустя.
- В акте перечислите: домен, хостинг, админка, БД, Git, лицензия, бэкап, staging, API, Метрика/почта; добавьте фразу о прекращении доступа старого подрядчика с даты.
- После подписи смените все пароли: хостинг, SSH, БД, админка, Git, DNS, SMTP, API.
- Удалите учётки старой команды в bitrix/admin/ и на сервере.
- Проверьте свой админ и возможность restore.php на случай блокировки.
Делайте: акт со списком + смена паролей в один день. Не делайте: общих админов "на всякий случай" - это vendor lock.
Запустите онбординг нового подрядчика на 1-2 недели
Пароли ≠ знание. Интеграции, агенты, кастом в /local/, обмен с 1С нужно прожить вместе. Ориентир: параллель 1-2 недели при Git и собранных доступах; дольше - если репозитория нет.
Схема без простоя:
Ownership у заказчика → акт и смена паролей → карта интеграций → новая команда на staging → параллель 1-2 нед → smoke-тест форм/заказов/обмена → старый подрядчик выходит
- Составьте карту: формы, оплата, CRM API, обмен 1С, почта; зафиксируйте, кто чинит P1 на этой неделе.
- Дайте новому доступ к staging; бой - по согласованному окну.
- Каждый день параллели - smoke-тест критичных сценариев.
- После стабильной недели закройте доступ старой команде полностью.
Если нового ещё нет - как выбрать подрядчика на сайт. Пакет у нового сверьте по чек-листу техподдержки, договор - по организации поддержки.
Если доступы размазаны и нужен независимый вход в чужой проект на 1С-Битрикс - обсудите онбординг поддержки: аудит ownership, staging и карта интеграций.
Делайте: параллель со smoke-тестами. Не делайте: "рубильник" в пятницу без карты интеграций.
Закрепите ownership в договоре, чтобы не повторить зависимость
Смена бесполезна, если через год снова: домен у менеджера, Git только у студии, staging нет. В новом договоре: домен/хостинг/лицензия на заказчике; репозиторий у вас; staging обязателен; при расторжении - регламент передачи и акта.
Красные флаги: FTP-only без Git, нет staging, лицензия не на вас, root у одного человека, отказ отдать бэкап. Два и больше - запускайте чек-лист, не ждите кризиса.
Нужен спокойный вход в уже работающий Битрикс-проект - через форму контактов. Примеры - в портфолио.
Делайте: ownership и регламент передачи в договоре. Не делайте: поддержку на личных аккаунтах студии.
Автор: Максим Мольков, разработчик 1С-Битрикс.
Источники: FAQ 1С-Битрикс по передаче лицензии; learning restore.php; user_help dump.php; docs по /local/; license_update / SiteUpdate; практика передачи CMS на сопровождение.
Частые вопросы
Можно ли сменить подрядчика, если старый не отвечает?
Да. Начните с того, что уже под контролем: хостинг, домен, биллинг, бэкапы у хостера. Восстанавливайте по частям: панель → БД → админка → Git. Если админка потеряна - restore.php и свежий дамп. Фиксируйте переписку для юристов.
Нужен ли акт передачи сайта?
Да. В акте - список переданного (доступы, лицензия, бэкап, репозиторий) и формулировка о прекращении доступа старой команды. Без акта и смены паролей передача остаётся на словах.
Что делать с лицензией Битрикс при смене поддержки?
Сверьте владельца ключа. Если лицензия на подрядчике - однократная уступка через sales@1c-bitrix.ru на заказчика до расторжения. Иначе SiteUpdate/Marketplace остаются рычагом старой студии.
Сколько длится передача поддержки?
Ориентир: 1-2 недели параллели при Git и собранных доступах; до 3-4 недель без репозитория. День акта - один рабочий день чек-листа, онбординг - отдельно.
Нужно ли менять все пароли после передачи?
Да: хостинг, SSH, MySQL, bitrix/admin/, Git, DNS, SMTP, API. Иначе бывший исполнитель заходит позже. Удалите старые учётки и проверьте вход своим админом.
Чем смена поддержки отличается от приёмки нового сайта?
Приёмка нового сайта - проверка до акта на сдаче, пока есть рычаг оплаты. Смена поддержки - передача живого сайта: ownership, staging/бэкап, акт прекращения доступа и онбординг без простоя заявок.
Где в Битрикс смотреть бэкап и восстановление (dump.php, restore.php, CBackup)?
Дамп: Настройки → Инструменты → Резервное копирование (dump.php / CBackup). Пробное восстановление - restore.php на отдельном стенде. Архив держите offsite у заказчика, не только на диске хостинга.
