Какие конфигурации 1С устарели и уже не обновляются: что делать бизнесу

Какие конфигурации 1С устарели и больше не обновляются, чем это опасно для бизнеса и как правильно спланировать переход на актуальную систему.

Какие конфигурации 1С устарели и уже не обновляются

Для бизнеса «устаревшая 1С» — это не просто программа с непривычным интерфейсом. Критичный момент наступает, когда используемая редакция перестает получать обновления от разработчика или получает их в ограниченном объеме. Тогда в программе могут отсутствовать актуальные формы отчетности, изменения в расчете налогов и зарплаты, новые форматы электронного обмена и необходимые механизмы интеграции.

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

Полностью снятые с поддержки редакции

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

Характерный пример — старые редакции массовых решений, которые разработчик заменил более современными ветками. К этой категории относятся, в частности, «1С:Бухгалтерия 7.7», «1С:Зарплата и Кадры 7.7», а также устаревшие редакции конфигураций на платформе 1С:Предприятие 8, для которых предусмотрен переход на актуальную редакцию или другое поддерживаемое решение. Продолжать эксплуатацию таких систем только потому, что «все пока проводится», рискованно.

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

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

Системы с ограниченной поддержкой и рисками для учета

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

В 2025 году особенно важно смотреть не только на название продукта, но и на конкретную редакцию. «Бухгалтерия предприятия», «Зарплата и управление персоналом», «Управление торговлей», «Комплексная автоматизация» и другие популярные решения существуют в разных поколениях. Фраза «у нас стоит 1С:Бухгалтерия» сама по себе ничего не говорит о состоянии поддержки — нужны номер редакции и релиз.

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

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

Какие ветки скоро перестанут обновляться

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

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

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

Чем опасна работа на устаревших конфигурациях 1С

Устаревшая конфигурация 1С может продолжать запускаться, проводить документы и формировать привычные отчеты. Поэтому у бизнеса возникает ощущение, что срочности нет: программа работает — значит, менять ничего не нужно. На практике проблема обнаруживается в тот момент, когда меняются требования законодательства, формат электронного документа, протокол обмена или правила работы внешнего сервиса. Если разработчик уже не поддерживает конфигурацию, необходимые изменения в нее просто не попадают.

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

Риски по отчетности, кассам, маркировке и ЭДО

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

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

Для компаний, работающих с маркируемыми товарами, последствия могут быть еще заметнее. В этом случае 1С участвует в цепочке приемки, продажи, возврата, перемещения и вывода кодов маркировки из оборота. Изменение требований к обмену с системой маркировки способно сделать отдельную операцию недоступной или привести к расхождению данных между фактическим движением товара и информационной системой.

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

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

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

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

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

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

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

Как старые версии влияют на обмены и интеграции

Современная 1С редко работает изолированно. Она получает заказы с сайта или маркетплейса, обменивается данными с CRM, передает платежные документы в банк, взаимодействует с кассами, сервисами доставки, ЭДО и государственными системами. Каждый такой обмен строится на определенных протоколах, форматах, API и механизмах авторизации, которые со временем меняются.

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

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

Поэтому оценивать устаревшую 1С стоит не по принципу «открывается база или нет», а по способности системы поддерживать текущие процессы компании. Если для отчетности, маркировки, ЭДО и обменов регулярно требуются ручные обходные решения, это уже не просто вопрос удобства. Это показатель накопленного технологического риска, который следует учитывать при выборе между дальнейшими доработками и переходом на поддерживаемую конфигурацию.

Чаще всего с чего на что переходят после устаревания системы

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

На практике направление перехода зависит не только от исходной конфигурации. Для торговой компании может быть достаточно современной «1С:Управление торговлей», а организации со сложным производством, бюджетированием и управленческим учетом потребуется «1С:ERP». Чем больше функциональных контуров затрагивает старая база, тем важнее до начала проекта сопоставить реальные бизнес-процессы с возможностями целевого решения.

Переход с УПП 1.3 на 1С:ERP

Для компаний, которые продолжают использовать «1С:Управление производственным предприятием 1.3», одним из основных вариантов развития становится «1С:ERP Управление предприятием». Такое направление особенно логично для производственных предприятий, где в одной системе связаны закупки, склад, производство, продажи, себестоимость, финансы и управленческий учет.

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

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

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

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

Переход с УТ 10.3 на современные редакции УТ, КА или ERP

Для пользователей «1С:Управление торговлей 10.3» выбор целевой системы шире. Если компания в основном занимается оптовой торговлей и ей нужны продажи, закупки, склад, ценообразование, CRM-функции и управление запасами, естественным вариантом становится актуальная редакция «1С:Управление торговлей». Однако выбирать решение только по принципу «УТ меняем на УТ» не обязательно.

«1С:Комплексная автоматизация» имеет смысл рассматривать, когда торговый контур нужно теснее объединить с регламентированным учетом, зарплатой, финансами и другими процессами предприятия. «1С:ERP» чаще выбирают компании с более сложным управленческим контуром, производством, развитым бюджетированием или потребностью централизовать процессы крупного предприятия.

Особое внимание при миграции с УТ 10.3 требуется интеграциям. За длительное время эксплуатации у компании могут появиться обмены с сайтом, маркетплейсами, кассовым оборудованием, бухгалтерской системой, складскими сервисами и собственными приложениями. Старый механизм обмена не всегда можно без изменений подключить к новой конфигурации, поэтому интеграционный контур необходимо обследовать отдельно.

Есть и организационный момент: сотрудники привыкли к определенной последовательности документов и расположению команд в УТ 10.3. В современной системе аналогичная операция может оформляться по-другому. Поэтому перед запуском полезнее обучать пользователей не расположению кнопок, а новому сценарию работы целиком — от заказа клиента до отгрузки и отражения оплаты.

Переход с 1С:Розница 2.3 на 1С:Розница 3.0

В рознице задача обычно выглядит компактнее, чем миграция крупной производственной системы, но цена ошибки здесь особенно заметна: кассы и магазины должны продолжать обслуживать покупателей. При переходе с «1С:Розница 2.3» на «1С:Розница 3.0» необходимо заранее проверить не только данные, но и весь рабочий контур торговой точки.

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

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

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

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

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

Аудит текущей конфигурации и зоны риска

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

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

• Данные: справочники, остатки, взаиморасчеты, документы и необходимая история операций.
• Доработки: изменения конфигурации, расширения, внешние отчеты, обработки и печатные формы.
• Интеграции: сайты, маркетплейсы, CRM, банки, ЭДО, телефония и оборудование.
• Бизнес-процессы: закупки, продажи, склад, производство, зарплата, бухгалтерский и управленческий учет.
• Техническая часть: объем базы, быстродействие, резервное копирование, серверная инфраструктура и права доступа.

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

Выбор целевой системы под задачи компании

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

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

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

Пошаговый план миграции, тестирования и запуска

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

1. Подготовить целевую базу. Настроить организации, учетную политику, роли пользователей, необходимые функциональные опции и интеграции.
2. Выполнить пробную миграцию. Перенести согласованный объем данных и зафиксировать время, необходимое для процедуры.
3. Провести сверку. Сопоставить остатки товаров, денежных средств, расчеты с контрагентами и другие контрольные показатели старой и новой систем.
4. Проверить рабочие сценарии. Пользователи должны провести реальные типовые операции: оформить продажу, поступление, платеж, отгрузку, закрытие периода и сформировать ключевые отчеты.
5. Выполнить финальный перенос. Выбрать период минимальной нагрузки, остановить ввод данных в старой системе, перенести актуальные изменения и снова проверить контрольные показатели.
6. Организовать период стабилизации. Быстро разбирать ошибки и вопросы пользователей, не отключая доступ к старой базе как к архивному источнику до завершения всех проверок.

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

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

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

Полезные сервисы и обновления

Мобильная автоматизация склада

Узнать больше

Маркировка «Честный ЗНАК»

Узнать больше

Розничная торговля и инвентаризация

Узнать больше

Вопросы и ответы

Как понять, что конфигурация 1С устарела?

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

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

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

Чем опасна работа на старой версии 1С?

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

На что обычно переходят с 1С:УПП 1.3?

Для производственных предприятий одним из основных вариантов является «1С:ERP Управление предприятием». Такой переход требует предварительного обследования, поскольку архитектура, справочники, документы и отдельные учетные процессы в УПП и ERP различаются.

На какую систему переходить с 1С:Управление торговлей 10.3?

Выбор зависит от процессов компании. Для продаж, закупок, склада и управления запасами обычно рассматривают современную редакцию «1С:Управление торговлей». Для более широкого комплекса учета может подойти «1С:Комплексная автоматизация», а при сложном производстве, бюджетировании и комплексном управлении ресурсами — «1С:ERP».

Что нужно проверить перед переходом с 1С:Розница 2.3 на 1С:Розница 3.0?

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

Нужно ли переносить в новую 1С всю историю документов?

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

Можно ли перенести все доработки из старой 1С в новую?

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

Как перейти на новую 1С без длительной остановки бизнеса?

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

Что входит в аудит 1С перед миграцией?

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