Доработанная 1С годами не обновлялась, а теперь надо: как обновиться и ничего не сломать

Павел СтупкоАрхитектор 1С, бизнес-аналитик

3 сентября 2026 · 9 минут

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

Почему доработанную базу боятся обновлять

Страх обоснованный, но неточный: ломается не «база», а конкретные вещи.

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

Изменённые формы и отчёты. Кнопки, дорисованные в типовой форме, после объединения уезжают или теряют обработчики. У переделанного отчёта слетают поля и настройки.

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

Есть и второй слой. Руководитель годами слышит «обновляться нельзя» и начинает считать это свойством системы. Хотя это решение одного программиста пять лет назад. «Нельзя» значит «страшно и долго тому, кто будет делать». А платит компания: каждое изменение закона — ручная доработка вместо готового релиза, маркировка и ЭТрН — через костыли.

Три состояния конфигурации, и что каждое значит для обновления

В конфигураторе состояние видно в разделе «Поддержка», от него зависит объём и способ обновления.

«Объекты поставщика» — ключ ко всему. Вместе с релизом 1С привозит конфигурацию поставщика, платформа хранит её в базе как эталон и при обновлении понимает: модуль отличается от поставки, потому что его правили вы, или потому что 1С сама его изменила. Правило поддержки задаётся для каждого объекта: девяносто процентов под замком, десять — «с сохранением поддержки», и конфликты только по этим десяти. «Снять с поддержки» всё — удобство программиста, за которое компания платит на каждом обновлении.

Сколько релизов пропущено — столько же рисков

У обновления с релиза трёхлетней давности четыре эффекта, которых при регулярных нет.

• Каскад. Релиз ставится не с любого предыдущего: у каждого есть список версий, с которых допустим переход. Пропустили тридцать — идёте через промежуточные, и на каждом шаге объединение повторяется.
• Структура данных. Между релизами меняются регистры и реквизиты, платформа перестраивает таблицы, на базе в сотни гигабайт это часы. Переход через редакцию, с УТ 11.4 на 11.5, — особенно.
• Обработчики обновления. При первом запуске код переносит данные в новые структуры. В типовых на БСП часть обработчиков отложенная и крутится в фоне иногда сутками. Если доработка положила в регистр данные, которых обработчик не ждёт, он падает на середине.
• Платформа. Каждый релиз конфигурации требует минимальную версию платформы: база на 8.3.1x, релиз просит 8.3.2x. Платформу обновляют отдельно: сервер, клиентские места, СУБД. Сдвигается и режим совместимости, а это меняет поведение кода.

Чем дольше не обновлялись, тем больше это проект, а не обновление.

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

• 1. Инвентаризация доработок. Сравниваем рабочую конфигурацию с конфигурацией поставщика (или с чистой поставкой того же релиза, если снята) и получаем реестр: что изменено, зачем, кто пользуется. Обычно треть доработок мёртвая.
• 2. Перенос в расширения, где возможно. Формы, отчёты, печатные формы переезжают хорошо, переписанное проведение — с осторожностью, изменения структуры данных — не все. Остальное — в конфигурации под правилом «с сохранением поддержки».
• 3. Тестовая копия. Полная копия боевой на том же релизе платформы, для большой базы — копия СУБД, а не выгрузка в .dt.
• 4. Обновление на копии с секундомером. Проходим каскад и записываем, сколько заняли реструктуризация и обработчики. Это реальный размер окна.
• 5. Прогон ключевых сценариев. 15–30 операций: заказ, отгрузка, оплата, закрытие месяца, обмены, отчётность и всё, что завязано на доработки. Прогоняют ключевые пользователи: программист проверит, что открывается, пользователь — что считается верно.
• 6. Сверка до и после. Остатки, оборотка, дебиторка на одну дату в старой базе и в обновлённой копии. Расхождение — обработчик или ошибка объединения.
• 7. Окно и откат. Резервная копия, запрет входа, платформа, конфигурация, обработчики, короткий прогон. Критерий отката оговорён заранее: не прошли сценарии к такому-то часу — восстанавливаем копию.

Что даёт AI при разборе доработок

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

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

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

Чего AI не делает: не объединяет конфигурации и не решает конфликты, это за человеком. А реестр читается руководителем без переводчика: видно, за что платите и от чего можно отказаться. Как мы это делаем — на странице AI Обновление 1С; если база уже фактически самописная — AI-поддержка самописной 1С.

Как это выглядит в программе

Три экрана из типовой УТ 11, которые стоит открыть до разговора с подрядчиком.

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

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

Фильтр по ошибкам за последние часы: упавшие обработчики, обмены, фоновые задания. Рядом — «Результаты обновления программы», где видно, какие отложенные обработчики ещё не завершились.

Когда обновляться уже не стоит, а стоит переходить

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

Редакция снята с поддержки или не развивается. УПП, УТ 10.3, Комплексная 1.1, Бухгалтерия 2.0: обновляться некуда.

Переписана большая часть типовых объектов. При трети изменённых объектов и больше проще собрать заново.

Обновление нужно ради одной функции. Ради ЭТрН или маркировки бывает дешевле решение рядом.

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

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

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

С чего начать

Не с покупки релиза. С реестра доработок и ответа на вопрос: обновляться или переходить. Это ровно то, что делает AI Диагностика 1С: собираем реестр, оцениваем путь по каскаду и пишем план с окном и критерием отката. С планом на руках вы говорите с любым подрядчиком на своих условиях.

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