Перенос документов между системами электронного документооборота: как не потерять архив и юридическую значимость

Как безопасно перенести документы при смене СЭД и не превратить архив в набор файлов без прав, подписей и истории согласований

В чём проблема и кому полезна статья

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

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

Отдельно стоит сразу развести два похожих, но разных сценария. Первый — миграция данных при смене внутренней СЭД (тема этой статьи): организация отказывается от одной системы делопроизводства в пользу другой и переносит архив. Второй — роуминг между операторами ЭДО: обмен юридически значимыми документами с контрагентами, которые подключены к другому оператору (например, «Контур.Диадок» и СБИС) [7][8]. Это разные задачи с разными техническими решениями, и путать их не стоит — если ваш вопрос именно про обмен с контрагентами, а не про переезд архива, роуминг обычно решается настройкой на стороне операторов ЭДО без переноса данных вообще [9].

Что переносится при миграции СЭД: простое объяснение

Документ в СЭД — это не файл. Это карточка с набором атрибутов (номер, дата, автор, статус, гриф, срок хранения), к которой прикреплены один или несколько файлов, ссылки на записи справочников (контрагенты, подразделения, номенклатура дел), история движения по маршруту согласования и электронные подписи, которыми документ подписан на каждом этапе [2][10].

Поэтому при переносе между системами нужно синхронно перенести несколько связанных слоёв:

• Файлы вложений — сами документы во всех форматах, в которых они хранились, включая версии.
• Карточки и атрибуты — метаданные, по которым документы находят, фильтруют и к которым привязаны сроки хранения.
• Справочники — контрагенты, сотрудники, подразделения, номенклатура дел, виды документов, на которые ссылаются поля карточек [2].
• Историю бизнес-процессов — листы согласования, кто и когда согласовал или отклонил документ [10].
• Электронные подписи — сами подписи и информация, необходимая для их последующей проверки.
• Права доступа — кто может видеть и редактировать документ в новой системе.

Разработчики специализированных утилит-мигрантов отдельно подчёркивают: миграция подразумевает не разовое копирование, а определённую последовательность действий и перенос целого ряда связанных объектов, а не только самих документов [1][2]. Пропуск любого из этих слоёв — типичная причина, по которой перенесённый архив формально «работает», но фактически бесполезен: документы есть, а найти их по нужным атрибутам, проверить, кто и когда их согласовал, или подтвердить подпись — уже нельзя.

Как устроен процесс переноса

Кто выполняет перенос: три подхода

Готовая утилита-мигратор. Для самых распространённых пар «старая СЭД → новая СЭД» вендоры и интеграторы готовят специализированные инструменты. Например, для перехода с «Е1 Евфрат» на DIRECTUM или Docsvision такие решения уже существуют и построены на опыте множества похожих проектов: они переносят карточку документа с атрибутами, приложенные файлы, связанные справочники и историю бизнес-процессов, а работают по принципу регулярно запускаемого агента, который находит изменённые с момента последнего запуска документы и переносит их в целевую систему [10]. Это самый предсказуемый вариант, но он существует не для всех пар систем.

Выгрузка — преобразование — загрузка (ETL). Если готового мигратора нет, данные выгружают из старой системы (через её API, экспорт в файлы или прямой доступ к БД), приводят к формату, который понимает новая система, очищают от дублей и загружают через API целевой СЭД [11][12]. Такой подход требует больше разработки, но подходит для любой пары систем и даёт полный контроль над логикой сопоставления полей.

Ручной перенос. Для небольших архивов или отдельных категорий документов (например, только активные договоры, а не весь исторический архив) иногда достаточно ручного экспорта и повторной загрузки с контролем оператора. Это не масштабируется на большие объёмы, но может быть оправдано для узкой задачи.

Единого формата миграции для любой пары СЭД нет. Спецификация OASIS CMIS описывает универсальный интерфейс к контентным хранилищам, но применить её можно только при документированной поддержке на обеих сторонах. В остальных проектах используют API, штатный экспорт или согласованный файловый пакет и отдельно проверяют, какие метаданные и доказательства подписи доступны в выбранном интерфейсе.

Из чего состоит проект миграции

1. Аудит исходной системы. Изучают структуру данных, объём архива, состав карточек и справочников, качество данных — дубли, неполные записи, нарушенную ссылочную целостность [12]. Отдельно фиксируют, какие документы физически хранятся не в СЭД, а на файловых шарах или в почте — их тоже придётся включить в периметр переноса или сознательно исключить.
2. Изучение целевой платформы. Архитектурные ограничения, поддерживаемые типы данных, лицензионная модель, API и его лимиты [12].
3. Маппинг данных. Сопоставление полей карточек и справочников старой и новой системы. Это обычно самая трудоёмкая часть проекта — не потому что сложна технически, а потому что требует содержательных решений: как классификация документов в старой системе ляжет на номенклатуру дел в новой, что делать с полями, которых в целевой системе нет.
4. Резервное копирование исходных данных перед началом любых работ — чтобы иметь возможность вернуться к исходному состоянию, если перенос пойдёт не по плану [11][15].
5. Пилотный перенос на репрезентативном подмножестве данных. Прогон миграции на ограниченном наборе документов, чтобы проверить логику до того, как она применяется ко всему архиву [16].
6. Полный перенос. Крупные объёмы обычно переносят поэтапно, с проверкой результатов на каждом шаге, а не одним массивом [11].
7. Сверка. Сопоставление количества документов, контрольных сумм по ключевым полям и результатов выборочных проверок между старой и новой системой — перенос считается завершённым, если расхождений нет [17].
8. Тестирование доступности и работоспособности документов в новой системе конечными пользователями, включая проверку электронных подписей.

Российская специфика

Импортозамещение и сроки

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

Для проверки, входит ли конкретный продукт в реестр отечественного софта и есть ли у него сертифицированные аналоги, используется единый реестр российского ПО Минцифры, где можно подобрать замену конкретному иностранному решению [19]. Среди СЭД/ECM-платформ, включённых в реестр, — Directum, Docsvision, «1С:Документооборот», ELMA365, СЭД «Дело», СЭД ТЕЗИС, Tessa и ряд других [20][21].

Юридическая значимость документов после переноса

Юридическая сила электронного документа не является свойством СЭД — она обеспечивается электронной подписью и соблюдением требований к форме, полномочиям подписанта и процедуре обмена, а не самим фактом хранения файла в конкретной системе [3][4]. Регулируют это прежде всего два закона: 63-ФЗ «Об электронной подписи» и 402-ФЗ «О бухгалтерском учёте» [22].

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

Требования к архивному хранению

Требования к рабочему коммерческому архиву и к документам, которые передаются на государственное или муниципальное архивное хранение, различаются. Правила Росархива, состав пакета и формат PDF/A применяют, когда это следует из статуса организации, вида документа и сценария передачи. Для внутренней миграции состав архива определяют по срокам хранения, нормативным обязанностям и возможности доказать происхождение файла, подписи и метаданных [23][24][25].

Отличие от роуминга операторов ЭДО

Если задача — не перенос внутреннего архива, а обмен документами с контрагентами, которые работают в другом сервисе ЭДО (например, компания использует «Контур.Диадок», а её поставщик — СБИС), это решается не миграцией данных, а роумингом: технологией обмена юридически значимыми документами между разными операторами ЭДО, при которой процессы и требования регулирует отраслевая ассоциация разработчиков и операторов систем электронных услуг [7][8][9]. В большинстве случаев для этого достаточно отправить контрагенту приглашение через свой сервис ЭДО — данные при этом не переносятся между системами, а документы каждый раз доставляются адресату через связку операторов [26][27].

Варианты реализации: что выбрать

Готовый мигратор от вендора или интегратора — самый быстрый и предсказуемый путь, если он существует для конкретной пары систем. Такие инструменты разрабатываются на основе опыта уже реализованных проектов перехода и минимизируют риск потери связанных данных [1][10].

ETL-разработка под конкретный проект — вариант для пар систем, для которых готового решения нет, либо когда стандартный мигратор не покрывает всю нужную функциональность (например, специфичные доработки старой СЭД, нетиповые справочники, кастомные маршруты согласования). Такой подход даёт полный контроль над логикой сопоставления, но требует больше времени на разработку, тестирование и последующую поддержку.

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

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

Практические этапы проекта

1. Определить периметр переноса: какие документы, за какой период, из каких хранилищ (СЭД, файловые шары, почта) подлежат миграции, а что можно оставить в режиме архива только для чтения или не переносить вовсе.
2. Провести аудит исходных данных и качества (дубли, неполные карточки, нарушенные связи) [12].
3. Изучить API и ограничения целевой системы, включая лимиты на количество запросов и объём единовременной загрузки.
4. Составить маппинг полей карточек, справочников и типов документов между системами.
5. Сделать резервную копию исходной системы [11][15].
6. Разработать или настроить инструмент переноса и прогнать его на пилотном наборе данных [16].
7. Провести полный перенос поэтапно с контролем на каждом шаге [11].
8. Сверить количество документов, контрольные суммы и выборочные записи между системами [17].
9. Проверить работоспособность электронных подписей и доступность документов для конечных пользователей в новой системе.
10. Определить дальнейшую судьбу старой системы: держать как архив только для чтения на переходный период или полностью вывести из эксплуатации.

Ограничения, ошибки и риски

Перенос только файлов без метаданных и связей. Если переносятся только вложения без карточек, справочников и истории согласования, в новой системе оказывается набор файлов без возможности их искать, фильтровать по атрибутам или подтверждать историю движения документа [2][10].

Потеря данных для проверки электронной подписи. Визуальный штамп подписи в PDF — не то же самое, что данные, необходимые для криптографической проверки. Если при миграции переносится только «картинка» подписи, а не полный набор данных для её верификации, доказать подлинность документа впоследствии может быть сложно [3][22].

Недооценка «теневого» архива. Часть документов компании обычно существует вне основной СЭД — на общих сетевых папках, в личных почтовых ящиках, в разрозненных Excel-реестрах. Если не включить инвентаризацию таких источников в проект, при расчёте бюджета и сроков миграции легко упустить работы, о существовании которых команда узнаёт уже после старта проекта [28].

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

Некорректный или неполный маппинг справочников. Если контрагенты, подразделения или номенклатура дел не сопоставлены аккуратно, в новой системе появляются дубли записей или документы, привязанные не к тем объектам [2].

Отсутствие плана отката. Без резервной копии исходных данных и чёткого критерия «миграция прошла успешно» сложно принять обоснованное решение — продолжать использовать новую систему или вернуться к старой при обнаружении расхождений [11][15].

Игнорирование сроков нормативных требований. Для организаций, подпадающих под КИИ, промедление с переходом на отечественное ПО после наступления регуляторных сроков создаёт не только технический, но и комплаенс-риск [5][6].

Рекомендации по выбору решения

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

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

Как может помочь «Пятый фактор»

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

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

Вывод

Перенос документов между СЭД — это проект по миграции связанных данных, а не копированию файлов, и относиться к нему стоит соответственно: с аудитом исходной системы, маппингом полей, резервным копированием, пилотным прогоном и обязательной сверкой результатов. Российская специфика добавляет к этому дополнительный слой требований — от сроков перехода на отечественное ПО для субъектов КИИ до требований Росархива к формату архивного хранения. А юридическая значимость документов после переноса зависит не от того, в какой системе они лежат, а от того, сохранены ли данные, необходимые для проверки электронной подписи, которой они были подписаны изначально. Если у вас есть похожая задача — начните с честного аудита того, что и где сейчас хранится, прежде чем выбирать конкретный инструмент миграции.

Источники

[1] docsvision.com — Утилита для миграции в Docsvision 5 — https://docsvision.com/info-centr/news/utilita_migrazii_v_docsvision.html

[2] tanais.ru — Миграция данных — компания TANAiS — https://www.tanais.ru/services/integratsiya-informatsionnykh-sistem/data_migration/

[3] comindware.ru — Юридически значимый ЭДО: подпись, обмен и хранение — https://www.comindware.ru/blog/yuridicheski-znachimyy-edo/

[4] delo-press.ru — Юридическая сила документа, электронная подпись и СЭД — https://delo-press.ru/journals/documents/informatsionnye-tekhnologii/62943-zavisimost-yuridicheskoy-sily-dokumenta-ot-elektronnoy-podpisi-i-sed/

[5] base.garant.ru — Указ Президента РФ от 30.03.2022 № 166 — https://base.garant.ru/403784114/

[6] navigator.axoft.ru — Указ Президента Российской Федерации от 30 марта 2022 года № 166 — https://navigator.axoft.ru/all-items/tproduct/667629304-328570524551-ukaz-prezidenta-rossiiskoi-federatsii-ot

[7] diadoc.ru — Роуминг в ЭДО между разными операторами: как обмениваться документами — https://www.diadoc.ru/articles/22150-rouming_s_diadokom

[8] kontur.ru — Роуминг ЭДО — Контур.Диадок — https://kontur.ru/diadoc/roaming

[9] taxcom.ru — Роуминг между операторами ЭДО — обмен документов между системами — https://taxcom.ru/dokumentooborot/rouming/

[10] tanais.ru — Мигратор данных — компания TANAIS Москва — https://www.tanais.ru/solutions/migrator/

[11] practicum.yandex.ru — Миграция базы данных: как сделать, примеры, инструменты — https://practicum.yandex.ru/blog/migraciya-baz-dannyh/

[12] mkskom.ru — Миграция данных: что такое миграция базы данных и зачем это нужно — https://mkskom.ru/blog/migraciya-dannyh

[13] tadviser.ru — CMIS - Content Management Interoperability Services — https://www.tadviser.ru/index.php/Статья:CMIS_-_Content_Management_Interoperability_Services_-_Службы_взаимодействия_при_управлении_контентом

[14] osp.ru — CMIS: управление контентом как сервис — https://www.osp.ru/os/2008/09/5716877

[15] dis-group.ru — Миграция данных — что это и как сделать правильно? — https://dis-group.ru/blogs/migracziya-dannyh-chto-eto-i-kak-sdelat-pravilno/

[16] decosystems.ru — Базы данных: схема и процесс миграции — https://www.decosystems.ru/migratsii-baz-dannyh/

[17] vc.ru — Изучаем миграцию базы данных: цели, примеры и пошаговая инструкция — https://vc.ru/dev/3001766-migratsiya-bazy-dannykh-tseli-primery-i-poshagovaya-instruktsiya

[18] passwork.ru — Импортозамещение ИБ-решений (СЗИ): переход на российское ПО — https://passwork.ru/blog/importozamieshchieniie-ib-rieshienii/

[19] lpmotor.ru — Импортозамещение в IT-сфере России: полный обзор — https://lpmotor.ru/articles/importozameshchenie-it-rossiya-2026-2601

[20] elma365.com — Системы и программы электронного документооборота: обзор СЭД — https://elma365.com/ru/articles/obzor-i-sravnenie-sistem-elektronnogo-dokumentooborota/

[21] tadviser.ru — СЭД (отраслевой обзор) — https://www.tadviser.ru/index.php/СЭД

[22] ca.kontur.ru — Юридическая сила электронного документа — https://ca.kontur.ru/articles/yuridicheskaya-sila-elektronnogo-dokumenta

[23] slsoft.ru — Электронный архив: как обеспечить долговременное хранение юридически значимых документов — https://slsoft.ru/news/elektronnyy-arkhiv-kak-obespechit-dolgovremennoe-khranenie-yuridicheski-znachimykh-dokumentov/

[24] archiv.ru — Сроки хранения документов в организации — https://www.archiv.ru/useful/sroki-khraneniya-otdelnykh-vidov-dokumentov/

[25] archiv.ru — Хранение электронных документов: сроки, способы, организация архива — https://www.archiv.ru/useful/hranenie-elektronnyh-dokumentov-v-organizacii-sroki-sistema-trebovaniya/

[26] tochka.com — Роуминг ЭДО между операторами: что это, как работает — https://tochka.com/knowledge/edo/rouming-edo-chto-eto-i-kak-ego-nastroit-s-drugimi-operatorami/

[27] diadoc.com — Диадок Роуминг — обмен с другими операторами ЭДО — https://diadoc.com/roaming

[28] eodoc.ru — Миграция СЭД на российское ПО в 2026 году: как рассчитать затраты и избежать скрытых расходов — https://eodoc.ru/migraciya-na-rossiyskoe-po-raschet-zatrat/