Функциячто работает сейчас
УПП → ERP · наследие · типовой механизм · решение
Что переносить
из УПП
в ERP — и что
не переносить
Не копируем старую конфигурацию в новую. Для каждой значимой функции отделяем бизнес‑обязанность от исторической реализации, проверяем типовой механизм ERP, данные и архитектурный разрыв — и только потом решаем, что сохранить, заменить, перепроектировать или исключить.
Сам факт существования доработки не является требованием к новой системе. Требованием становится только нужный результат процесса, который можно показать на конкретном сценарии.
Обязанностьзачем это бизнесу
ERPчто есть типового
Разрывчего не хватает
Решениесохранить / заменить типовым / перепроектировать / исключить
F-17Контроль доступности материалатиповой + настройкаT
F-28Специальный расчёт обещанной датыперепроектироватьR
F-41Историческая печатная формаархивироватьX
- 01Проверить обязанность
- 02Сверить типовой ERP
- 03Принять функцию на сценарии
4 решениядля каждой значимой функции1 процесскак граница первого разборатиповой ERPпроверяется до разработкиповторный сценарийкак приёмка результата
Короткий ответ
Переносить нужно не доработку. Переносить нужно обязанность бизнеса.
Старая функция получает право попасть в новую систему только после того, как команда может показать, какой результат процесса без неё теряется, чем этот результат закрывается в ERP и как проверить его после переключения.
01Обязанность02Стандарт03Разрыв04Решение05Приёмка
Перенос доработки — это сохранение необходимого бизнес‑результата в целевой архитектуре, а не механическое воспроизведение старого кода, структуры данных и интерфейса УПП. Если результат можно получить типовым механизмом ERP, старый код не является активом — он становится кандидатом на исключение.
Поэтому технический реестр сам по себе почти ничего не говорит об объёме миграции. Два объекта конфигурации могут выглядеть одинаково важными, но один ежедневно участвует в обещании клиенту, а второй остался после процесса, которого в компании уже нет. Начинать нужно с процесса и принятого результата, а не с количества изменений.
Ограниченное окно сопровождения УПП создаёт давление по срокам, но не меняет эту логику. Чем сильнее дедлайн, тем опаснее переносить всё подряд: лишний объём увеличивает миграцию, тестирование и параллельный период как раз тогда, когда время проекта наиболее ценно.
Пять проверок до переноса
Как доказать, что функция действительно нужна в целевой системе
Проверки идут от смысла к реализации. Если первый вопрос не закрыт, переходить к следующему рано.
- 01Обязанность
Сначала назвать бизнес‑результат, а не объект конфигурации
Для каждой значимой доработки фиксируем, какое обязательное действие, контроль или расчёт она обеспечивает сегодня. Если смысл нельзя сформулировать без названия модуля, граница ещё не определена.
- 02Использование
Проверить, что функция действительно участвует в рабочем сценарии
Отделяем используемое поведение от исторического наследия: кто запускает функцию, как часто, на каких данных и что происходит, если она недоступна.
- 03Стандарт
Сопоставить обязанность с типовым механизмом целевой системы
Сравниваем не названия объектов УПП и ERP, а требуемое поведение. Типовой механизм принимается только если закрывает нужную обязанность и проходит контрольный сценарий.
- 04Данные
Отделить перенос поведения от переноса всей исторической реализации
Определяем, какие данные нужны для непрерывности, что остаётся архивом, какие идентификаторы должны совпасть и кто владеет преобразованием между старой и новой моделью.
- 05Приёмка
Закончить решением и способом проверить его после переключения
У каждой функции должен быть критерий: сохранить смысл, заменить типовым, перепроектировать или исключить. После запуска результат повторно проверяется на том же бизнес‑сценарии.
Четыре решения
У старой функции нет варианта «перенести автоматически»
После пяти проверок функция должна получить одно явное решение. Это и есть управляемая граница наследия.
SСОХРАНИТЬ
Сохранить смысл
Функция нужна для результата процесса, но способ её реализации может измениться полностью.
TЗАМЕНИТЬ ТИПОВЫМ
Заменить типовым
Целевая система уже закрывает требуемое поведение. Доработка не переносится, а сценарий принимается на типовом механизме.
RПЕРЕПРОЕКТИРОВАТЬ
Перепроектировать
Обязанность остаётся, но старая реализация связана с архитектурой УПП и создаёт лишние зависимости в новой системе.
XИСКЛЮЧИТЬ
Исключить или архивировать
Функция больше не поддерживает обязательный результат, используется только для истории или дублирует другую рабочую систему.
Типовые ошибки
Где переход незаметно превращается в копирование старой системы
Четыре решения выглядят быстрыми на старте, но резко увеличивают стоимость второй половины проекта.
Переносить все доработки по списку объектов конфигурации
Технический перечень не показывает, какая функция реально нужна бизнесу и какая уже закрыта типовым механизмом ERP.
Тащить все данные только потому, что они когда‑то были введены
Исторические регистры, документы и служебные поля смешиваются с данными, необходимыми для непрерывности процесса и отчётности.
Считать одноимённую функцию ERP автоматической заменой доработки
Совпадение названия не гарантирует совпадения правил, ролей, данных и момента принятия решения в конкретном предприятии.
Оставлять старую и новую реализацию без срока отключения
Параллельный период полезен только как ограниченная проверка. Без владельца и даты завершения он превращается в постоянный второй источник истины.
01Критичный процесс
Первый проверяемый шаг
Карта наследия одного процесса за 10 рабочих дней
Берём один процесс, от которого зависит реальный результат бизнеса, и классифицируем только функции и данные, без которых его нельзя безопасно перевести в целевую систему.
Периметр1 процессФокусважные функцииНа выходе6 материалов
Решение после разборачто переносить / чем заменить / что перепроектировать / что исключить
Разобрать свой процесс Паспорт процесса
граница, владелец и принятый результат
Реестр функций
что реально участвует в сценарии
Сверка с ERP
типовой механизм и подтверждённый разрыв
Карта данных
операционные данные, история и архив
Матрица решений
сохранить / заменить типовым / перепроектировать / исключить
План первой волны
приёмка, параллельный период и возврат
Публичные основания
Что 1С подтверждает о поддержке УПП и переходе на ERP
Дата проверки: 7 августа 2026 года. Регламент поддержки и методические материалы проверяются заново перед проектным решением.
Граница заявления. Официальные материалы подтверждают срок и правила поддержки, рекомендации и доступные методики перехода. Они не определяют автоматически, какие именно доработки, данные и интеграции конкретного предприятия нужно переносить.
Короткие ответы
Что уточнить до реестра доработок и первой волны
Главные вопросы о сроке поддержки УПП, типовых механизмах ERP, истории, поэтапности и границе первого разбора.
Задать свой вопрос01Поддержка 1С:УПП уже закончилась?
Нет. Актуальные материалы 1С указывают поддержку УПП до конца 2026 года. В I квартале 2027 года планируются только обновления, необходимые для отчётности за 2026 год; с 1 апреля 2027 года консультации по УПП со стороны фирмы 1С не планируются. Перед проектным решением всё равно нужно проверить действующие ИТС/КП УПП и конкретную поставку.
02Нужно ли переносить все доработки УПП?
Нет. Переносить имеет смысл обязанность процесса, если она остаётся необходимой. Старая реализация может быть заменена типовым механизмом ERP, перепроектирована или исключена. Решение принимается по контрольному сценарию, а не по факту существования кода.
03Что делать с историческими данными?
Разделить данные для непрерывности работы, данные для обязательной отчётности и архив. Не весь исторический массив обязан жить в операционной базе новой системы. Для каждой группы нужны владелец, правило преобразования и способ сверки.
04Можно ли перейти частями?
Да, если первый этап даёт самостоятельный результат, имеет ясных владельцев данных и ограниченный параллельный период. Временные обмены и двойная работа должны иметь срок завершения и понятный способ возврата.
05С чего начать, если доработок сотни?
Не с полного технического реестра. Начните с одного важного процесса и функций, без которых он не даёт принятого результата. Это позволяет быстро выделить действительно ценное наследие и определить правило классификации для остального массива.
Материал проверенУПП → ERP · официальные материалы 1С · граница вывода
На дату проверки официальные материалы 1С описывают поддержку УПП до конца 2026 года, ограниченные обновления в I квартале 2027 года и прекращение консультаций с 1 апреля 2027 года. Решение о переносе конкретных доработок принимается отдельно — по бизнес‑обязанности, типовой возможности ERP и контрольному сценарию.
Актуализировано
Вопрос по вашему наследию
Есть список доработок УПП? Начните не со списка — начните с важного процесса.
Зафиксируем один процесс, его обязательный результат и функции, которые действительно поддерживают этот результат. После этого станет видно, что проверять в ERP и что не стоит переносить.
- Один важный процесс вместо всей конфигурации
- Типовой ERP проверяется до новой разработки
- Каждая функция получает явное решение