Смена подрядчика по Битриксу: как передать сайт новой команде без потери данных, заявок и позиций в поиске

Смена подрядчика по сайту на Битриксе — стрессовая операция. Бизнес боится потерять заявки в момент перехода, обвалить позиции в поиске, остаться без доступов или получить «чёрный ящик», в котором новая команда будет месяцами разбираться за деньги клиента. Эти риски реальны, но при правильной подготовке переход проходит за 2–4 недели и без простоя. В статье — пошаговый план: что собрать у старого подрядчика, как передать код, базу и контент, как не потерять SEO-трафик и заявки, и какие юридические моменты закрыть до расставания.

Когда пора менять подрядчика

Сначала честно ответьте: проблема в команде или в задачах. Если подрядчик не закрывает задачи, на которые у него нет компетенций (например, вы выросли из продуктового магазина в маркетплейс), — возможно, нужен не новый исполнитель, а второй, более узкий. Но если вы видите системные проблемы, медлить не стоит.

• Сроки регулярно срываются в 2–3 раза, а оценки задач не сходятся с фактом.
• Подрядчик не отвечает на письма по 2–3 дня, эскалации не работают.
• Вы не понимаете, за что платите: счета без расшифровки часов и задач.
• Падает качество — после каждого релиза появляются новые баги, тесты не проводятся.
• Команда не делает бэкапы, не ведёт документацию, всё «в голове у одного разработчика».
• Подрядчик отказывается обновлять Битрикс, ссылаясь на «риски», и сайт уходит в архив с устаревшими модулями.
• Вы не можете получить исходники, доступы к репозиторию, сервер — всё «у них».

Если узнали 3–4 пункта из списка — переход обоснован. Если 1–2 — попробуйте сначала переговоры и письменное соглашение по SLA. Смена подрядчика всегда дороже, чем починка отношений.

Шаг 1. Аудит того, что у вас есть на руках

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

• Где физически расположен сайт: хостинг, VDS, выделенный сервер, облако (Selectel, Timeweb, Beget, AWS, Yandex Cloud).
• Кто владелец аккаунта хостинга и домена: ваша компания или подрядчик.
• Где находится репозиторий с кодом (GitLab, GitHub, Bitbucket) и кто его владелец.
• Редакция Битрикса, номер версии ядра и список установленных модулей Marketplace.
• Лицензия Битрикса: на чьё имя оформлена, когда продление, есть ли активная техподдержка от 1С-Битрикс.
• Интеграции: 1С, CRM (Битрикс24, amoCRM, RetailCRM), службы доставки, платёжные шлюзы, аналитика, рассылки.
• Доступы: админка сайта, FTP/SFTP, SSH, база данных, панель хостинга, DNS-провайдер, почта, кабинеты Яндекс.Метрики и Search Console.

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

Шаг 2. Юридическая чистота расставания

Прежде чем что-то передавать, проверьте договор со старым подрядчиком. Ищите конкретные пункты.

• Передача исключительных прав на разработанный код — должна быть явно прописана. Если этого нет, формально код принадлежит подрядчику.
• Обязательство передать исходники, документацию и доступы по требованию заказчика.
• Сроки уведомления о расторжении (обычно 30 дней).
• NDA — действует ли он после расторжения, на какой срок, что считается конфиденциальной информацией.
• Гарантийные обязательства на ранее сделанные работы — кто чинит баги, обнаруженные после расставания.

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

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

Шаг 3. Полные бэкапы — ваша главная страховка

До передачи доступов сделайте независимые резервные копии и сохраните их вне инфраструктуры подрядчика — например, на корпоративном Яндекс.Диске или S3-хранилище компании.

• Полный дамп базы данных в формате .sql или .sql.gz (через mysqldump или штатный бэкап Битрикса).
• Архив /bitrix, /local, /upload и пользовательских папок (/include, /about и т. п.).
• Файл .htaccess, конфиги Nginx/Apache, php.ini, my.cnf — настройки сервера.
• Cron-задания (crontab -l) — список запланированных задач, без них могут перестать выгружаться 1С, отправляться письма, чиститься кэш.
• SSL-сертификаты и ключи (если не Let's Encrypt).
• Экспорты из CRM, истории заявок, настройки платёжных шлюзов и доставки.

Бэкапы делайте минимум в двух экземплярах: один — рабочий, второй — «холодный» (offline-копия). Проверьте, что архив открывается и дамп БД восстанавливается на тестовом сервере. Бэкап, который вы не разворачивали, — это ещё не бэкап.

Шаг 4. Передача доступов: что и в каком порядке

Не отдавайте новой команде «всё и сразу» от старой. Сначала переоформите ключевые активы на компанию, потом выдавайте новые доступы.

• Домен — переносите в аккаунт регистратора, оформленный на юрлицо. У многих регистраторов это делается через push.
• Хостинг/VDS — либо переоформите аккаунт на компанию, либо мигрируйте сайт на новую инфраструктуру (часто это делает новый подрядчик).
• Репозиторий — создайте корпоративный аккаунт в GitLab/GitHub, перенесите туда код, отзовите доступы у внешних пользователей.
• Лицензия Битрикса — привяжите к корпоративному e-mail, смените пароль личного кабинета 1С-Битрикс.
• DNS — управление зоной должно быть у вас, а не у подрядчика.
• Метрика и Search Console — добавьте корпоративных пользователей с правом администратора, удалите старых.
• Платёжные шлюзы и онлайн-кассы — у них юридический владелец вы, но технические доступы могли быть у подрядчика; смените пароли и API-ключи.

Правило 24 часов: после расставания все пароли, API-ключи и токены, к которым имел доступ старый подрядчик, должны быть сменены в течение суток. Это не про недоверие — это базовая ИБ-гигиена.

Шаг 5. Передача кода и документации

Идеальный вариант — у старого подрядчика есть Git-репозиторий с историей коммитов и README. Реальный вариант — код лежит на проде, изменения вносились через FTP, истории нет. От этого зависит сложность приёмки.

• Запросите архив всего рабочего кода + дамп БД на актуальную дату.
• Получите список кастомных модулей в /local/modules и /bitrix/modules — особенно собственных разработок подрядчика.
• Выясните, какие компоненты переопределены в /local/templates и /local/components.
• Соберите документацию: схема архитектуры, описание интеграций, форматы обмена с 1С, структура нестандартных таблиц БД.
• Список технических аккаунтов: SMTP для писем, токены API служб доставки, ключи Яндекс.Карт и т. п.
• Перечень регулярных задач: что делает cron, что — агенты Битрикса, какие есть ручные процедуры (например, ежемесячная выгрузка отчёта).

Если документации нет — это нормально для Битрикс-проектов. Заложите 1–2 недели в работу нового подрядчика на «обратный инжиниринг»: изучение кода, описание интеграций, составление актуальной схемы.

Шаг 6. Технический аудит силами новой команды

Не передавайте проект «вслепую». Хороший новый подрядчик первой работой делает приёмочный аудит — за фиксированную небольшую стоимость или даже бесплатно (если впереди контракт).

• Состояние ядра Битрикса и модулей: какие версии, что устарело, что в Marketplace заброшено.
• Качество кода: кастомизации в /bitrix/ (это плохо), хардкод, отсутствие миграций, дубли компонентов.
• Состояние базы: размер, индексы, фрагментация, мусорные таблицы от удалённых модулей.
• Безопасность: открытые .git/, доступные дампы, SQL-инъекции, устаревший PHP, слабые пароли.
• Производительность: время ответа, размер кэша, проблемные SQL-запросы, Core Web Vitals.
• SEO-состояние: индексация, robots.txt, sitemap, микроразметка, дубли страниц, 404-ошибки.
• Интеграции: работают ли обмены с 1С без ошибок, не копятся ли неотправленные заказы в CRM.

Результат аудита — отчёт с описанием проблем, оценкой рисков и планом стабилизации на первые 1–2 месяца. Это документ, по которому вы поймёте, что приняли, и сможете спланировать бюджет.

Шаг 7. Как не потерять SEO-позиции при переходе

Сама по себе смена подрядчика SEO не ломает — ломают изменения, которые новая команда вносит «по дороге». Чтобы трафик не просел, зафиксируйте текущее состояние и не трогайте критичные SEO-факторы первые 1–2 месяца.

• Сделайте полный краулинг сайта (Screaming Frog, Netpeak Spider) — получите снимок URL, заголовков, метатегов, кодов ответа.
• Сохраните текущий robots.txt, sitemap.xml, файл .htaccess с редиректами.
• Выгрузите топ-100 поисковых запросов и страниц-доноров трафика из Метрики и Search Console.
• Зафиксируйте позиции по семантическому ядру в трекере (Topvisor, SERanking) до начала работ.
• Запретите новой команде менять URL-структуру, чистить старые страницы и менять title/H1 без согласования с SEO-специалистом.
• Если сайт мигрирует на новый сервер — настройте такие же редиректы, сохраните URL вплоть до слешей и регистра, не меняйте кодировку.

Самый болезненный сценарий: новая команда «причесала» URL и убрала «лишние» параметры. Через 2 недели трафик упал на 40%, и его собирают обратно полгода. Любые изменения URL — только с 301-редиректами и согласованием.

Шаг 8. Непрерывность заявок и заказов

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

• Перед миграцией дублируйте получателей всех уведомлений (заказы, заявки с форм) на корпоративный e-mail клиента.
• Проверьте, что коды счётчиков аналитики и пикселей рекламных кабинетов сохранены.
• Проведите смоук-тест: оформите тестовый заказ, отправьте заявку с каждой формы, проверьте отправку SMS и e-mail.
• Если меняется сервер — переключайте DNS в часы минимальной нагрузки и держите оба сервера активными 48–72 часа (TTL DNS).
• Настройте мониторинг доступности (UptimeRobot, Яндекс.Метрика, собственные алерты) — чтобы первыми узнавать о падениях, а не от клиентов.
• На время перехода держите «горячую линию» — выделенный канал связи с обоими подрядчиками, где можно быстро эскалировать инцидент.

Шаг 9. Первые 30/60/90 дней с новой командой

Чтобы переход прошёл управляемо, разбейте его на этапы с понятными результатами.

• Дни 1–7: приёмка доступов, бэкапы, технический аудит, фиксация SEO-снимка.
• Дни 8–30: стабилизация — закрытие критичных уязвимостей, обновление PHP до поддерживаемой версии, настройка резервного копирования и мониторинга.
• Дни 31–60: устранение технического долга по приоритетам аудита, налаживание регулярных релизов, написание недостающей документации.
• Дни 61–90: первые продуктовые задачи — то, ради чего меняли подрядчика. К этому моменту проект должен быть прозрачным и предсказуемым.

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

Признаки, что новый подрядчик подходит

• Сразу спрашивает про бэкапы, доступы, документацию — а не про «как делать».
• Предлагает приёмочный аудит как первый шаг, а не сразу ныряет в задачи.
• Готов работать с вашим существующим кодом, а не уговаривает «всё переписать с нуля».
• Использует Git, ведёт задачи в трекере, делает регулярные релизы и фиксирует изменения.
• Объясняет риски и сроки на понятном языке, без «магии Битрикса».
• Подписывает NDA и договор с явной передачей прав на код.

Чек-лист передачи сайта на Битриксе

• Подписано соглашение о расторжении с старым подрядчиком, передаче прав на код и срок последней поддержки.
• Сделаны и проверены 2 независимых бэкапа (код + БД + конфиги).
• Домен, хостинг, лицензия Битрикса и репозиторий переоформлены на компанию.
• Все пароли, API-ключи и токены сменены в течение 24 часов после расставания.
• Получен полный архив кода, дамп БД, список модулей и интеграций, документация (что есть).
• Новая команда провела технический аудит и согласовала план стабилизации.
• Зафиксирован SEO-снимок: краулинг, позиции, robots.txt, sitemap, редиректы.
• Дублируются уведомления о заявках и заказах на корпоративный e-mail.
• Настроен мониторинг доступности и алерты.
• Проведены смоук-тесты ключевых сценариев: заказ, заявка, оплата, обмен с 1С.

Итог

Смена подрядчика по Битриксу — это не катастрофа, а управляемый проект на 4–8 недель. Главное: расставаться по-человечески, забирать доступы и код заранее, не давать новой команде сразу всё ломать «по-своему» и фиксировать SEO-состояние до начала работ. Тогда вы получите команду, с которой можно расти, а не проблемный проект, который полгода будут чинить за ваш счёт.

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