Как сменить подрядчика по поддержке Битрикс?

  • Автор: Иван Рябов
  • Опубликовано: 17.08.2026
  • Обновлено: 04.09.2026
  • Время чтения: 15 минут
Смена подрядчика по поддержке 1С-Битрикс пройдет без остановки сайта, если передача организована до крупных изменений и у заказчика есть доступ к ключевым системам. Сначала нужно зафиксировать состояние проекта, собрать управляемые доступы, проверить лицензию и исходный код, затем провести первичное обследование и передать новой команде ответственность за дальнейшие изменения. Не стоит поручать двум подрядчикам одновременно менять один код и рабочий сайт
Вернуться к списку

Что нужно проверить перед передачей сайта новой команде:

  • Сначала нужно сохранить контроль над доменом, сервером, сайтом, лицензией и репозиторием

  • Новая команда должна изучить проект до первой доработки

  • Критичные сценарии — заказ, оплата, авторизация, заявка и обмен данными — нужно зафиксировать отдельно

  • Доступ к административной части сайта не заменяет доступ к коду, инфраструктуре и резервным копиям

  • Лицензию 1С-Битрикс необходимо зарегистрировать на компанию-заказчика

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

В Ameton рекомендуем начинать передачу не с новой задачи, а с восстановления карты проекта: где находится код, кто управляет инфраструктурой, какие доработки нестандартны и что нельзя нарушить при первом изменении

Сначала зафиксируйте состояние сайта и контроль над системами

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

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

  • домену и корпоративной почте, с которой он связан

  • хостингу и серверному окружению

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

  • репозиторию актуального исходного кода

  • резервным копиям сайта и базы данных

  • лицензии 1С-Битрикс, установленным модулям и сервисам

  • системам оплаты, доставки, учёта, CRM и другим подключённым сервисам

  • тестовой среде, если она используется для выпуска изменений

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

Что новая команда должна проверить при входе в проект на 1С-Битрикс

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

Что проверяет новая команда

Почему это важно

Какой риск снижает

Редакция и состояние лицензии

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

Проблемы с продлением и обновлением

Исходный код и репозиторий

Позволяют понять, какая версия сайта является актуальной

Случайная перезапись рабочих доработок

Индивидуальные компоненты и модули

Показывают нестандартную логику проекта

Поломки после обновления платформы

Задания обмена и обработки данных

Влияют на каталог, заказы, статусы и уведомления

Неполные данные, дубли и задержки

Интеграции

Определяют, что сайт получает и куда передаёт данные

Некорректные цены, остатки или заказы

Критичные сценарии

Задают обязательный набор проверок после изменений

Ошибки, которые обнаруживаются уже клиентами


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

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

Что должна сделать новая команда при приёме сайта на поддержку

Новая команда должна принимать сайт через первичное обследование, а не через обещание быстро закрыть первую заявку. Для 1С-Битрикс особенно важно восстановить контекст индивидуальных доработок и связанных сервисов до выпуска изменений

Процесс передачи обычно состоит из пяти шагов:

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

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

  3. Зафиксировать критичные сценарии: заявка, заказ, оплата, авторизация, личный кабинет и обмен данными

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

  5. Сформировать отдельные очереди критичных, плановых и профилактических задач

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

Подробнее о необходимых материалах можно прочитать в статье Как передать сайт новой команде на поддержку

Что должно входить в поддержку после передачи

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

Направление

Что делает команда

Какой риск снижает

Стабильность

Диагностирует ошибки и проверяет ключевые сценарии

Простои, потерю заявок и заказов

Обновления

Проверяет совместимость ядра, модулей и индивидуальных доработок

Поломки после обновления

Резервные копии

Контролирует создание, хранение и восстановление

Потерю данных и длительный откат

Безопасность

Управляет доступами, анализирует права и важные настройки

Несанкционированный доступ и ошибки управления учётными записями

Интеграции

Проверяет результат обмена товарами, ценами, остатками и заказами

Дубли, неполные данные и неверные статусы

Развитие

Оценивает доработки с учётом архитектуры проекта

Накопление случайных и конфликтующих изменений


Если после обновления сайт открывается, это не доказывает, что работа завершена. Для интернет-магазина нужно проверить заказ и оплату, для B2B-портала — права пользователей и документы, для корпоративного сайта — отправку заявок и обработку обращений

Можно ли вести сайт двумя подрядчиками одновременно

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

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

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

Что делать, если старый подрядчик не передаёт доступы

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

Последовательность действий:

  • подтвердить регистрацию домена и права компании на него

  • восстановить доступ к корпоративной почте

  • обратиться к хостинг-провайдеру от лица компании-заказчика

  • определить, где хранится актуальный код и кто управляет репозиторием

  • восстановить доступ к учётным записям платёжных, логистических и других сервисов

  • проверить регистрацию лицензии 1С-Битрикс

  • отозвать неактуальные учётные записи и создать новые персональные доступы

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

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

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

Критерий

Хороший вариант

Рискованный вариант

Вход в проект

Команда изучает доступы, код, обновления, задания обмена и критичные сценарии

Просит только пароль от административной части

Оценка задач

Уточняет цель, границы и влияние на связанные функции

Называет решение без вопросов

Обновления

Проверяет изменения до публикации и повторно проходит важные сценарии

Устанавливает обновления сразу на рабочем сайте

Интеграции

Проверяет результат передачи данных

Ограничивается фактом соединения систем

Отчётность

Фиксирует выполненные работы, риски и следующие шаги

Присылает только общий счёт

Передача знаний

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

Хранит контекст в личной переписке специалистов


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

От чего зависит стоимость поддержки Битрикс-сайта

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

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

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

Какой формат поддержки выбрать после смены подрядчика

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

Тип проекта

Подходящий формат поддержки

Почему

Небольшой корпоративный сайт

Периодическое обслуживание и разовые доработки

Обычно достаточно контролировать формы, доступы и обновления по графику

Интернет-магазин

Регулярная поддержка

Заказы, оплаты, каталог и обмен данными требуют постоянного контроля

B2B-портал

Регулярная поддержка и развитие

Роли, документы, персональные условия и интеграции создают много зависимостей

Лендинг или промо-сайт

Плановые проверки и точечные работы

Сайт часто проще, если не участвует в критичных процессах

Проект без документации

Первичный аудит с последующим выбором формата

Сначала нужно восстановить устройство сайта и оценить риски


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

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

Ameton может начать работу с первичного обследования: проверить архитектуру, интеграции, доступы, резервные копии и критичные сценарии сайта. По итогам компания получает реестр рисков и рекомендуемый формат дальнейшей поддержки. Подробнее – в статье Зачем нужен аудит сайта на 1С-Битрикс перед стартом поддержки?


Ответы на частые вопросы

Обсудим проект?

Оставьте свои контакты или напишите нам в Телеграм или на почту. Наш менеджер свяжется с вами и подробно проконсультирует.