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