Практические советы от BTLab по миграции СЭД с западных систем

• ПетрАрбузов
• 6 декабря 2023
• Статьи

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

Процесс миграции с зарубежной платформы на российскую можно разбить на 2 блока:

1. Миграция функциональности.
2. Миграция данных.

Миграция функциональности

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

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

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

Миграция данных

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

Определение пула мигрируемых данных

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

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

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

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

Совет! Часто заказчикам оптимально сформировать отчёт или печатную форму всех заданий по документу – тогда вместо всех заданий мы переносим отчёт (печатную форму всех заданий по документу), если не требуется собирать статистику по старым объектам, если в организации есть система, которая отвечает за хранение всех подобных данных.

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

Формирование плана миграции

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

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

Скачать буклет бесплатно

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

Когда мы определили приоритеты миграции, мы можем составить чёткий план. Например, будем ли мы сначала мигрировать НСИ, чтобы минимизировать число запросов, и вся нормативно справочная информация к моменту создания документов в новой системе у нас уже была внутри. Потом мы будем мигрировать активные оперативные документы за текущий год. Затем приступаем к миграции архива – сначала входящие, потом исходящие, а затем ОРД и т.д. В каждой организации подобная последовательность будет своя, исходя из приоритетов.

Анализ возможных вариантов выгрузки из старой системы

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

1. Может ли компания сама выгрузить данные из системы?
2. Есть ли возможность расширить API старой системы? Бывают ситуации, когда API старой системы невозможно доработать, описание БД – нет, описание API отсутствует. Тогда приходится разбираться на уровне СУБД (структуры базы), как эти данные хранятся, как разработать механизмы по выгрузке.
3. Есть ли открытое API, не требующее установки доп. компонент для миграции данных.
4. Требуется разрабатывать промежуточные утилиты, которые будут работать на выгрузку данных из старой системы и на загрузку в новую, если нет API. 

На основании всей этой информации можно приступить к принятию решению по использованию 1 из 4 вариантов миграции:

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

Сравним все варианты.

Файловая система

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

Плюсы:

• Возможность миграции без организации доступа между источником и приёмником.
• Снижение стоимости миграции в случае выгрузки данных Заказчиком. Можно комбинировать команду, в результате сроки можно снизить.

Минусы:

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

Передача напрямую из источника

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

Плюсы:

• Снижение стоимости миграции в случае самостоятельной реализации заказчиком. Если есть какие-то механизмы в старой системе, то их можно переиспользовать, с помощью API Docsvision передать данные в новую систему. На стороне источника делается доработка для обеспечения возможности миграции.
• Возможность повторно использовать механизм в случае миграции данных в другие системы (например, из Lotus Notes одна база ложится в Docsvision, вторая на корп. портал в 1С Битрикс).

Минусы:

• Создание наработок для потенциально «мёртвой» системы.
• Активное участие специалистов Заказчика или высокая цена в случае привлечения подрядчика.

Получение данных на уровне приёмника

На стороне приёмника делается доработка для обеспечения получения данных из источника.

Плюсы:

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

Минусы:

• Высокая стоимость
• Отсутствие возможности повторно использовать механизмы в случае необходимости частичной миграции данных в другие системы (например, из Lotus Notes одна база ложится в ДВ, вторая на корп. портал в 1С Битрикс).

Через промежуточные утилиты

Создаётся утилита, которая отвечает за получение и передачу данных.

Плюсы:

• Минимальная нагрузка на специалистов заказчика.
• Отсутствие привязки к стеку системы приёмника при реализации получения данных (1 разработчик может писать на java механизм получения данных из Lotus, второй – сервисы создания объектов в ДВ на .Net).

Минусы:

• Высокая стоимость.
• Возможность повторно использовать механизмы в случае необходимости частичной миграции данных в другие системы (например, из Lotus Notes одна база ложится в ДВ, вторая на корп. портал в 1С Битрикс).

Определение архитектуры реализации миграции

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

Лучшие практики

1. Мигрировать только то, что действительно нужно. Это позволит снизить стоимость и время.
2. Выполнить хотя бы минимальную выверку данных перед миграцией для исключения дублей. Это касается данных документов, НЦИ.
3. Сделать копию старой системы, если есть такая возможность.
4. Копию развернуть «в той же стойке», что и новая система, чтобы минимизировать время на передачу данных. На больших объёмах очень сильно расширяются сроки.
5. Мигрируемая система должна быть на быстрых дисках по операциям чтения – это также помогает снизить сроки.
6. Многопоточная миграция для сокращения сроков миграции, если мы видим огромный пул документов, то прорабатываем каждый аспект, где можно сократить объёмы.
7. Анализ загрузки ресурсов во время миграции. Если из-за нехватки ресурсов происходит ошибка out of memory, приложение падает, то всё время простоев приводит к увеличению сроков. Минимально необходимо мониторить CPU, RAM, Диск, Сеть – смотреть, где и что можно увеличить при необходимости.
8. После реализации механизмов миграции выполнить замеры времени, актуализировать план миграции на базе актуальных данных.
9. Подготовить инструкции по миграции данных, в том числе описание архитектуры обязательно.
10. В реализации учесть возможность обновления мигрированного документа.
11. В реализации учесть возможность выборки мигрируемых документов и режима (только создание/создание и обновление).
12. Обучить миграции заказчика, не замыкать все процессы на себе.
13. Реализовать логирование в табличном виде, чтобы быстро анализировать ошибки.
14. Все возможные проблемы, которые заранее видим, кодируем: например, 01 – документ мигрирован успешно, 02 – документ не создан, не найден контрагент. При таком подходе анализ лога миграции будет занимать минимум времени.

Выводы

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