Как передать сайт на 1С-Битрикс новому подрядчику без потери заявок

01

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

Когда меняют подрядчика по поддержке 1С-Битрикс, часто ограничиваются учётной записью администратора. Это создаёт иллюзию передачи, но не передаёт управление системой. Сайт зависит от домена и DNS, хостинга, базы данных, лицензии, репозитория, почтовых ящиков, API-ключей, CRM, счётчиков и рекламных кабинетов. Потеря одного звена проявляется не сразу: страница открывается, но формы не создают лиды, UTM исчезают, а резервная копия оказывается непригодной для восстановления.

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

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

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

03

Что должен показать технический аудит до переключения поддержки

Экспресс-аудит нужен не для поиска виноватого, а для оценки риска. Новый подрядчик проверяет версию ядра и PHP, редакцию и срок лицензии, состав модулей, кастомные компоненты в /local/ и /bitrix/, очереди агентов и cron. Важно отделить штатные возможности платформы от доработок: обновление ядра может затронуть именно нестандартный код.

Отдельно проверяют инфраструктуру: доступ к панели хостинга, параметры PHP, место на диске, версию СУБД, SSL-сертификаты, правила редиректов и почтовую отправку. В журнале событий и логах веб-сервера ищут повторяющиеся ошибки. Если есть staging, нужно подтвердить, что он разворачивается из актуальной копии и не отправляет реальные письма или заказы.

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

04

Реестр доступов: что собрать у прежнего подрядчика

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

Критичный риск — домен, зарегистрированный на прежнего исполнителя. Формально он может управлять DNS, продлением и почтой. До технической передачи проверьте регистратора, контактный email, юридического владельца и возможность смены NS-записей. Аналогично проверьте лицензию 1С-Битрикс: ключ и кабинет должны быть доступны компании.

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

05

Проверьте путь заявки от формы до CRM

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

В карточке лида или сделки должны сохраниться имя, телефон, email, страница отправки, дата и источник. Если CRM принимает UTM-метки, зафиксируйте соответствие: utm_source, utm_medium, utm_campaign, utm_content, utm_term. Нельзя принимать передачу по скриншоту формы: откройте созданную сущность в CRM и проверьте фактические поля, ответственного, стадию и уведомление.

Тестируйте как минимум три варианта: прямой заход, визит с UTM и отправку с мобильного устройства. Дополнительно проверьте защиту от спама, согласие на обработку персональных данных и письма менеджеру. Если на сайте используется Битрикс24, права на вебхуки и настройки CRM можно сверять с официальным справочником Битрикс24.

06

Безопасный сценарий смены подрядчика за пять этапов

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

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

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

1. 1

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

2. 2

   Зафиксируйте исходное состояние. Сохраните список форм, заявок, ошибок, версий и действующих интеграций.

3. 3

   Соберите независимые доступы. Переведите домен, хостинг и ключевые кабинеты на корпоративные контакты.

4. 4

   Восстановите копию на staging. Проверьте файлы, базу, агенты и отсутствие отправки реальных писем.

5. 5

   Пройдите контрольный маршрут. Отправьте тестовые формы, проверьте CRM, UTM, уведомления и фиксацию цели.

07

Документация, которая делает поддержку предсказуемой

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

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

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

08

Какие ошибки чаще всего срывают передачу

Первая ошибка — отключить прежнего подрядчика до получения полной копии и расшифровки интеграций. Вторая — считать, что администратор в 1С-Битрикс равен владельцу всех сервисов. Он не даёт доступ к DNS, панели сервера, рекламным кабинетам и CRM. Третья — сменить пароли без учёта сервисных подключений: обмен с CRM, SMTP или платёжным шлюзом может использовать старые данные.

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

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

09

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

Сайт на 1С-Битрикс передан не в момент выдачи доступа, а после управляемой проверки. У компании есть контроль над доменом, хостингом, лицензией и ключевыми аккаунтами. У нового подрядчика — персональные права, рабочая копия на тестовом окружении, описание интеграций и понятный канал для задач. У маркетинга — подтверждение, что формы, UTM, цели и CRM продолжают работать.

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

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