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

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

Почему смена разработчика кажется рискованной

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

На практике нормальная передача проекта — это не «начать заново», а последовательно собрать доступы, зафиксировать текущее состояние и дать новой команде время разобраться в критичных участках.

Что нужно получить до расставания с предыдущим подрядчиком

• Доступ к административной части 1С-Битрикс.

• Доступ к серверу или хостингу, SSH/SFTP, панели управления.

• Доступ к базе данных и актуальной резервной копии.

• Контроль над доменом и DNS.

• Доступ к репозиторию, если используется Git.

• Список внешних интеграций: 1С, CRM, платёжные системы, доставки, API.

• Доступы к связанным сервисам: почта, аналитика, CDN, SMS, телефония и т. п.

• Информацию о регулярных заданиях, cron, агентах и нестандартных сервисах.

• Документацию и описание нестандартных доработок, если они есть.

Что я бы проверил до начала новых доработок

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

• Есть ли рабочая резервная копия и можно ли из неё восстановиться.

• Как устроено серверное окружение и соответствует ли оно проекту.

• Насколько сильно изменялось ядро или стандартные компоненты.

• Где находится кастомный код и как он связан с остальной системой.

• Какие интеграции критичны для бизнеса.

• Есть ли явные ошибки, нестабильные процессы и проблемы производительности.

• Можно ли безопасно сделать тестовую копию.

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

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 13806 тендеров
проведено за восемь лет работы нашего сайта.

Нужно ли переписывать сайт с нуля

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

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

Если этого нет, разумнее сохранить рабочие части и развивать проект постепенно.

Как должна выглядеть нормальная передача

1. Получить доступы и резервные копии.

2. Развернуть тестовую копию.

3. Проверить ключевые интеграции и критичные процессы.

4. Зафиксировать основные риски.

5. Выбрать первую понятную задачу.

6. Выполнить её и только после этого наращивать объём работы.

Я считаю, что первая конкретная задача — лучший способ проверить новую команду. Клиент видит, как разработчик разбирается в проекте, соблюдает сроки, задаёт вопросы и сдаёт результат.

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

Частые вопросы

Нужно ли предупреждать старого подрядчика заранее?

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

Может ли новая команда работать параллельно со старой?

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

Нужно ли сразу передавать весь сайт новой компании?

Нет. Можно начать с одной задачи или ограниченного участка проекта.

Что зафиксировать в плане перехода

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

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

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

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

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

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

Что важно запомнить

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

Александр Мельников, технический директор и тимлид интернет-агентства «Пегас». 20 лет опыта в веб-разработке и проектах на 1С-Битрикс.