Міграція даних з legacy-систем на UBD — База знань

Міграція з legacy-системи — це не «перенесли таблиці і поїхали». Це проєкт, що триває 4-12 місяців, у якому 80% роботи — підготовка, і тільки 20% — власне перенесення. Помилка на старті призводить до тижнів простою або до втрати даних. Стаття описує 6-фазний підхід, перевірений на десятках проєктів.

Фаза 1. Інвентаризація

Тривалість: 2-6 тижнів.

Перш ніж переносити, треба знати, що переносимо. Завдання фази:

Каталог даних: усі таблиці, документи, журнали, файлові сховища legacy-системи.
Класифікація: які дані треба перенести, які архівувати, які можна видалити (не всі дані заслуговують міграції — старі тестові, давно неактуальні).
Обсяг: кількість записів у кожній таблиці, розмір файлових сховищ.
Якість даних: наскільки погані дані у legacy (відсутні значення, порушення цілісності, дублікати).
Залежності: які зовнішні системи звертаються до legacy і будуть зачеплені міграцією.

Результат: документ «Каталог даних і план міграції».

Фаза 2. Mapping

Тривалість: 3-8 тижнів.

Структура legacy і структура UBD ніколи не збігаються. Завдання — створити mapping: яке поле legacy відповідає якому полю UBD, як трансформувати значення.

Тип mapping	Складність	Приклад
1:1 (пряме копіювання)	Низька	employee.fio → user.full_name
1:N (одне поле legacy → кілька UBD)	Середня	address (рядок) → street + city + zip
N:1 (кілька legacy → одне UBD)	Середня	first_name + last_name → full_name
Трансформація значень	Висока	status_code (1,2,3) → status (active/pending/closed)
Збагачення з зовнішніх джерел	Висока	company_code → company_id (lookup в довіднику)
Денормалізація → нормалізація	Дуже висока	Один великий запис з повтореннями → кілька пов’язаних

Фаза 3. Валідація

Тривалість: 2-6 тижнів.

До початку міграції перевіряємо якість даних. Типові перевірки:

Заповненість обов’язкових полів: для скільки записів поле X порожнє?
Формат: e-mail відповідає стандарту, телефон — національному формату.
Унікальність: чи дублюються РНОКПП, e-mail?
Цілісність: чи всі foreign keys посилаються на існуючі записи?
Часова консистентність: чи всі created_at < updated_at?

Результат: звіт про якість з відсотками порушень. На основі звіту замовник вирішує: виправляти у legacy перед міграцією, виправляти у процесі міграції, ігнорувати, відкинути «погані» записи.

Фаза 4. Тестова міграція

Тривалість: 4-8 тижнів (кілька циклів).

На тестовому стенді виконується повна міграція з прод-копії даних. Завдання:

Перевірити, що ETL-скрипти спрацьовують без помилок.
Перевірити, що результуючі дані у UBD коректні.
Вимірювати час міграції — це визначить тривалість cutover у проді.
Знайти крайні випадки (дані, які mapping не передбачив).

Зазвичай — 2-4 повні цикли тестової міграції до приймальних випробувань.

Фаза 5. Продакшн-міграція (cutover)

Тривалість: від декількох годин до тижнів.

Дві стратегії:

Велика міграція (big bang)

Legacy зупиняється у визначений момент, виконується повна міграція, UBD стартує. Час даунтайму — від кількох годин до доби.

Переваги: чітка точка переключення, немає необхідності синхронізації legacy ↔ UBD.

Недоліки: ризик — якщо щось не спрацює у проді, відкат складний. Простой бізнесу.

Поступова міграція (parallel run)

Legacy і UBD працюють паралельно. Дані пишуться у обидві системи. Поступово функції переключаються з legacy на UBD. Після стабілізації legacy відключається.

Переваги: можна відкотити, нульовий простой.

Недоліки: складність синхронізації, ризик розбіжностей даних, вдвічі більше навантаження на адміністрування.

Фаза 6. Верифікація

Тривалість: 2-4 тижні після cutover.

Після міграції — перевірка цілісності:

Кількість записів: N у legacy = N у UBD (з урахуванням відкинутих).
Контрольні суми по полях: sum(salary) у legacy = sum(salary) у UBD.
Випадкова вибірка: 50-200 записів, ручна перевірка повної відповідності.
Журнали міграції: усі помилки, попередження проаналізовані.
Тестові кейси бізнес-процесів: ключові процеси (наприклад, створення документа, затвердження) виконуються кінцевими користувачами.

Інструменти

Інструмент	Коли використовувати
ETL-платформи (Talend, Pentaho, NiFi)	Складні mapping з трансформаціями, регулярні міграції
Прямі SQL-скрипти	Прості міграції, контрольоване середовище
API-bridges (custom-код)	Legacy зі своїм API, складна логіка
UBD ETL-модуль	Стандартні джерела (SharePoint, 1С, Bitrix24)

Особливі випадки

Тимчасові дані

У legacy зберігаються тимчасові кеші, сесії, чернетки. Не переносимо — створюються заново в UBD при роботі.

Працівники з посадами, що змінилися

Орієнтація на актуальний стан, але історія посад зберігається у окремій таблиці (часто це нова таблиця, якої не було у legacy).

Міграція файлових сховищ

Документи з версіонуванням: переносити всі версії чи тільки актуальну? Залежить від регуляторних вимог. Для електронного документообігу — всі версії з мета-даними і підписами.

План відкату

Перед cutover обов’язково готується план відкату:

Резервна копія legacy перед запуском.
Чітка точка прийняття рішення «йдемо далі» / «відкочуємось» (зазвичай через 24-72 години після cutover).
Процедура відкату задокументована, прорепетирована на тесті.
Відповідальні особи з повноваженнями приймати рішення про відкат.

[ ПРАКТИЧНА РЕАЛІЗАЦІЯ ]

Як UBD прискорює міграцію зі стандартних джерел

UBD має штатну ETL-логіку для імпорту з популярних в Україні джерел: Microsoft SharePoint, 1С (через ODBC або вивантаження), Bitrix24, Excel-файли з умовною структурою. Для цих джерел не потрібно писати ETL-скрипти з нуля — налаштовується mapping у графічному інтерфейсі, ETL запускається автоматично. Це скорочує фази 2-4 на 30-50%.

UnityBaseDefense — технічна довідка →