Миграция legacy-системы на проекте — не «переписать монолит», а управляемый переход с сохранением бизнес-ценности. Системному аналитику нужна согласованная картина AS-IS / TO-BE: границы систем, данные, интеграции, сценарии, NFR, риски простоя и критерии приёмки по волнам. Этот разбор показывает, как шаблоны артефактов из раздела 10.01 и зафиксированные решения по волнам складываются в одну трассируемую цепочку — от discovery до decommission.

1. Суть темы

Миграция legacy-системы (legacy system migration) — управляемый переход от устаревшей ИС (технологии, архитектура, модель данных, процессы) к целевому состоянию с сохранением или улучшением бизнес-ценности. Модернизация (modernization) часто идёт вместе с миграцией: меняется не только место размещения, но и архитектура, API, доменная декомпозиция.

Роль системного аналитика в таком кейсе — обеспечить трассируемую связку между бизнес-capability, требованиями, контрактами интеграций, данными и приёмкой. Финальные решения по инфраструктуре и целевому стеку принимают архитектор и DevOps; аналитик фиксирует, что должно работать в период coexistence, кто master по данным, как сверяются контуры и когда миграция считается завершённой.

Типовой вопрос, который закрывает разбор кейса: «Какие артефакты и решения нужны на каждой фазе, чтобы команды не расходились в трактовке AS-IS и не потеряли данные на cutover?» Ответ — не один документ, а набор связанных спецификаций с явными delta между «как сейчас» и «как будет» и зафиксированными assumptions по source of truth (SoT).

flowchart LR
    subgraph asis [AS-IS]
        L[Legacy монолит]
        I1[Point-to-point интеграции]
    end
    subgraph transition [Переход]
        G[API Gateway / Facade]
        S[Strangler-сервисы]
        DW[Dual write / sync]
    end
    subgraph tobe [TO-BE]
        N[Целевые микросервисы]
        E[Event bus]
    end
    L --> G
    G --> S
    S --> N
    I1 --> G
    L --> DW
    S --> DW
    N --> E

2. Ключевые понятия

В кейсе OrderHub опираемся на три опоры: Strangler Fig — поэтапная замена через фасад; 6 R — решение по каждому модулю и интеграции (Retain / Strangler / Retire); SoT по агрегату — master не «по заказу целиком», а по header/lines, статусу, остатку отдельно на каждой волне. Теория паттернов и стратегий — 03.06.01 Архитектурные паттерны распределённых систем; рамка 6 R — в материалах AWS и Microsoft из раздела «Источники».

Parity / accepted delta: функциональный паритет или явно задокументированные отличия между legacy и новым контуром; без второго UAT ловит «ложные баги» async-сценариев.

3. Как применяется в работе аналитика

Ниже — сквозной разбор типового кейса. Контекст вымышленный, но структура артефактов и решений по волнам повторяема на реальных проектах. Фокус — не каталог полей шаблонов, а логика принятия решений аналитиком на каждой фазе.

Карта фаз → решения SA → артефакты 10.01 (якорь для §3):

Фаза§Ключевые решения SAАртефакты 10.01
Discovery3.2SoT по агрегатам, пороги reconciliation, риски × волна10.01.14 Шаблон глоссария и словаря данных, Vision/scope
AS-IS / стратегия3.36 R × 14 интеграций, Context AS-IS + delta TO-BE03.01.02 Моделирование контекста системы (Context Diagram), 10.01.13 Шаблон архитектурного решения (ADR)
Детализация3.4Delta AS-IS→TO-BE, parity vs accepted delta, контрактыUS/UC, REST/SOAP, Producer/Consumer, BPMN, БД, NFR, роли
Cutover3.5Gate W0–W4, W0→W1 contract delta, V&V, runbook10.01.15 Шаблон матрицы трассировки, 10.01.10 Шаблон описания Airflow-триггеров и автоматических процессов
Decommission3.6Closure интеграций по волнам, Retire create pathContext TO-BE, ADR Retire

3.1. Контекст кейса

Бизнес: розничная сеть, ~400 магазинов. Legacy: монолит «OrderHub» (Java EE, Oracle) — приём заказов, резервирование остатков, статусы доставки, интеграция с WMS и платёжным шлюзом. Драйверы: рост онлайн-заказов, требования PCI-DSS, невозможность масштабировать пиковую нагрузку «Чёрной пятницы», уход ключевых разработчиков.

Ограничения проекта:

  • Нельзя останавливать приём заказов дольше 2 часов в ночное окно;
  • История заказов за 7 лет — для audit и споров с клиентами;
  • Параллельно идёт замена IdM — ролевая модель должна пережить переход; cutover OrderHub не раньше W1, пока IAM не выдаёт токены с маппингом legacy-ролей;
  • Freeze на новый функционал в legacy на 6 месяцев, кроме regulatory hotfix через 02.05.02 Управление изменениями (Change Control Board).

Цель SA: согласованный backlog миграции, контракты между контурами, критерии приёмки по волнам, runbook cutover. Критерии успеха в цифрах — по 02.01.02 Цели, KPI и критерии успеха (SMART, GQM).

Риски discovery (формат «риск × волна × триггер пересмотра assumptions»):

РискВолнаТриггер пересмотра
Implicit rules в legacy-кодеW0> 0,1% shadow-расхождений две недели подряд
Неполный mapping 23 legacy-статусовW1–W2Batch-статусы без UI обнаружены после go W1
PCI scope расширен новым контуромW1–W4Любой новый компонент в cardholder data flow
IdM не готов к dual-tokenW1Negative test ролей fail или freeze ролей нарушен

Формат управления — 08.05 Управление рисками на этапе анализа.

3.2. Фаза 1. Discovery и assessment

Задачи аналитика:

Выходные артефакты:

АртефактСодержание
Capability map«Приём заказа», «Резервирование», «Смена статуса», «Возврат», «Отчётность для финансов», «Admin UI»
Матрица 6 ROrder intake → Strangler + Rebuild; Reporting → Retain 12 мес.; Admin UI → Replatform (W4)
Backlog миграцииПриоритизированные волны с зависимостями — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кano), 02.05.01 Управление зависимостями между требованиями
Vision / scope (фрагмент)Границы первых трёх волн, out-of-scope — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)
10.01.14 Шаблон глоссария и словаря данныхOrder, Reservation, Shipment — с legacy-кодами статусов

Вопросы на стейкхолдер-сессии (зафиксируйте ответы в assumptions; фасилитация — 09.02 Проведение эффективных встреч и воркшопов; стейкхолдеры — 02.01.03 Анализ заинтересованных сторон (Stakeholder Map)):

  • Что является source of truth по заказу, статусам и остаткам в период coexistence?
  • Какие сценарии нельзя упростить (compliance, отчётность)?
  • Допустимы ли временные ручные операции и на сколько месяцев?
  • Критерии успеха в цифрах: % сверки остатков, SLA на создание заказа, допустимый % расхождений при reconciliation.

Зафиксированные ответы для OrderHub (W1–W2):

СущностьMaster в coexistenceDual write / readЭталон reconciliation
Заказ (header, lines) после createorder-serviceDual write в legacy для отчётовorder-service.orders vs legacy mirror
Статус заказа после createLegacy OrderHubEvent OrderCreated → legacy listenerLegacy status log до W2
Физический остатокWMSorder-service хранит reservation_refNightly DAG OrderHub/WMS vs WMS
Idempotency createorder-service (Idempotency-Key)Legacy numeric ID в external_idDuplicate detection по key + external_id

Порог расхождений: ≤ 0,01% строк сверки остатков; ≤ 0,1% полей в shadow W0 — иначе волна не продвигается.

3.3. Фаза 2. AS-IS, карта интеграций и выбор стратегии

Context AS-IS и delta TO-BE: 03.01.02 Моделирование контекста системы (Context Diagram) — OrderHub в центре, 14 внешних систем; delta W1: Gateway + order-service как новый контейнер, legacy остаёт master статусов. Контейнерный вид — 06.03.05 C4-модель (Gateway, order-service, OrderHub, WMS, Payment).

AS-IS (фрагмент):

  • Монолит OrderHub, 14 point-to-point интеграций — см. 03.05.01 Виды интеграции (точка-точка, ESB, API-led);
  • Статусы заказа — 23 значения в legacy, часть — исторические и не используется в UI;
  • Резервирование остатков — синхронный вызов внутри транзакции создания заказа.

Карта интеграций × 6 R × волна (закрывает scope; «пропавшие» контуры — осознанный Retain/Strangler позже):

№ИнтеграцияПротокол6 RВолнаРешение аналитика
1WMSSOAPStrangler + ACLW0–W2Adapter в первой волне; ACL маппинг статусов — 03.06.02 Основы Domain-Driven Design
2Payment GatewayRESTRetain → StranglerW1 Retain; W4 StranglerДо W4 авторизация через legacy; PCI boundary зафиксировать в ADR assumptions — 08.06 Юридические и регуляторные требования РФ (PCI-DSS)
3ERP (финансы)SFTP batchRetainW1–W3Файлы из legacy-отчётов; ERP не трогаем до Retire reporting
4CRM (клиент)RESTRetainW1–W2Read-only lookup из legacy
5SMS-шлюзRESTRetainW1–W2Триггер из legacy listener
6EmailSMTPRetainW1–W2Как SMS
7LoyaltySOAPRetainW2–W4Некритично для intake
8Anti-fraudRESTRetainW1–W3Синхронный вызов из legacy path
9BI / DWHJDBC batchRetainW1–W3Kafka OrderCreated параллельно с W1
10Tax serviceRESTRetainW1–W2Расчёт в legacy до W3
11Courier APIRESTRetainW2–W4После миграции статусов
12Store POS syncMQRetainW1–W3Остатки магазинов — вне scope intake
13Archive / legal holdSFTPRetainW3Bulk history + legal hold 7 лет
14Admin LDAPLDAPReplatformW4Связано с IdM; см. ниже

Критичные use case (оформляются по 10.01.02 Шаблон Use Case или 10.01.01 Шаблон User Story):

  1. Создание заказа с резервированием остатков;
  2. Отмена заказа с освобождением резерва;
  3. Сверка остатков между OrderHub и WMS за сутки.

Стратегия первой волны (MVP Strangler): вынести создание заказа в order-service; legacy продолжает статусы и отчёты. Маршрутизация — через API Gateway (03.06.01 Архитектурные паттерны распределённых систем): новые заказы → новый контур, чтение истории — из legacy до read-модели W3.

Параллельная замена IdM: до W1 Gateway принимает оба типа токена (legacy LDAP claim + новый IAM). Runbook cutover: IAM переключается после smoke W1, не в ту же ночь, что routing 5% магазинов. Admin UI (Replatform, W4) — отдельная волна после стабилизации intake и статусов; до W4 операторы работают в legacy Admin с маппингом ролей из 10.01.11 Шаблон ролевой модели.

ADR: 10.01.13 Шаблон архитектурного решения (ADR) — «Strangler для order intake, ACL между legacy status model и целевой моделью».

3.4. Фаза 3. Детализация требований — связка шаблонов 10.01

Шаблоны образуют цепочку трассировки, а не параллельные опросники. Ниже — решения аналитика и минимальный пример трассировки.

User Story / Use Case — delta AS-IS → TO-BE

Как оператор колл-центра, я создаю заказ в новом UI, чтобы клиент получил подтверждение в течение 3 секунд при пиковой нагрузке.

Delta к AS-IS:

  • UI: новая форма; «тип доставки» — 4 значения вместо 7 (legacy-варианты маппятся при чтении истории);
  • Документированное отличие (не баг): при недоступности WMS — заказ в PENDING_RESERVATION, retry через очередь; в legacy — немедленный отказ. В матрице parity помечено как accepted delta; UAT проверяет retry, а не симметричный refuse;
  • Платёж: до W4 pre-auth остаётся в legacy после dual write; при fail reservation — void pre-auth в legacy в течение 15 мин (BPMN compensation);
  • Критерии приёмки: 02.04.02 Критерии приёмки (Acceptance Criteria) — latency p95 < 3 с; при rollback cutover — 0 потерянных подтверждённых заказов (см. §3.5).

Первый статус при create (end-to-end, W1):

  1. order-service сохраняет header/lines, выставляет внутренний DRAFT (не SoT для бизнес-статуса);
  2. После успешного WMS-reserve или постановки в PENDING_RESERVATION — dual write mirror в legacy;
  3. Legacy listener на OrderCreated создаёт projection и выставляет канонический статус NEW в legacy status log — это SoT до W2;
  4. UI колл-центра читает статус из legacy projection API; order-service хранит legacy_status_ref только для сверки;
  5. AC: клиент видит подтверждение ≤ 3 с; legacy status log содержит запись NEW для 100% dual-write заказов W1.

Поля шаблонов — в 10.01.01 Шаблон User Story и 10.01.02 Шаблон Use Case.

Пример матрицы трассировки

Story IDUse CaseAPI / EventMapping fieldTest / AC type
US-ORD-01UC Create OrderPOST /orders/v1, event OrderCreatedLEGACY_ORD_ID → orders.external_idTC-PAR-03: shadow W0 суммы ±0,01 ₽ — parity
US-ORD-01UC Create OrderWMS timeout pathstatus → PENDING_RESERVATIONTC-DELTA-02: retry ≤ 30 мин, без refuse — accepted delta

Полная матрица — 10.01.15 Шаблон матрицы трассировки, концепция — 02.03.04 Трассировка требований (концепция).

REST API, события и параллельная эксплуатация контрактов

КонтурАртефактНазначение
Синхронный intake10.01.04 Шаблон спецификации REST APIPOST /orders/v1, GET /orders/{id}; legacy SOAP createOrder — deprecated, но доступен для WMS-адаптера до W2
Legacy WMS10.01.05 Шаблон спецификации SOAP APIACL: маппинг статусов и SKU
Producer10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ)OrderCreated v1 для read-модели и BI
Consumer10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ)Legacy listener обновляет projection для отчётов

Синхронный intake vs async events — 03.05.02 Синхронные протоколы (REST, gRPC, GraphQL), 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events). Contract-first — 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf), lifecycle — 03.05.07 Управление версионированием API и жизненным циклом.

BPMN — сквозной процесс

Диаграмма по 10.01.08 Шаблон сквозной фичи (BPMN-процесс); нотация — 03.04.01 BPMN 2.0 - введение и основы. Дорожки: Call Center, Order Service, Legacy OrderHub, WMS, Payment Gateway.

На BPMN явно:

  • dual write (новая БД + legacy mirror);
  • compensation: fail reservation → void pre-auth (legacy), cancel mirror row;
  • escalation при PENDING_RESERVATION > 30 мин;
  • legacy listener: OrderCreated → status NEW в projection.

БД, mapping и bulk migration

10.01.03 Шаблон спецификации БД сервиса + 07.01 Базы данных и SQL на уровне аналитика:

  • TO-BE: orders, order_lines, reservation_refs, legacy_status_ref;
  • LEGACY_ORD_ID → external_id;
  • surrogate UUID в новом контуре; legacy numeric ID — для отчётов.

W3 bulk history: ночное окно 2 ч; выборочная верификация 0,1% записей × 7 лет; legal hold на архивном SFTP (#13); sign-off audit + finance до Retire create path.

NFR, reconciliation, роли

ШаблонЧто фиксируется
10.01.12 Шаблон нефункциональных требований (NFR)RPO ≤ 15 мин, RTO ≤ 2 ч; p95 < 3 с; peak 500 order/min
10.01.11 Шаблон ролевой моделиCALLCENTER_OP → order.create; freeze новых ролей в legacy
10.01.09 Шаблон описания экранной формы и логики на FEСостояния UI при async reservation
10.01.10 Шаблон описания Airflow-триггеров и автоматических процессовDAG сверки: R ops finance, A WMS owner, C duty SA; эскалация — > 0,01%

Теория NFR — 08.02 Нефункциональные требования (NFR) — классификация и стандарты.

3.5. Фаза 4. План миграции, тестирование и cutover

Wave plan:

ВолнаScopeРежимGate (go / no-go)
W0Shadow create без commitCompare payload< 0,1% расхождений по согласованному списку полей (SKU, qty, price, tax, delivery_type); владелец расхождений — SA + legacy dev; no-go блокирует W1
W15% магазинов, новый intakeDual write; SoT = order-service только по header/lines; статус — legacyUAT, reconciliation 7 дней зелёный; legacy status NEW на 100% dual-write; R: IT ops, A: product owner, C: audit (PCI log); R reconciliation — ops finance; R legacy status mapping — legacy dev lead
W2100% createLegacy — статусы, отчётыKPI latency/error; IAM только новые токены
W3Bulk history, Retire createDecommissionAudit sign-off, legal hold OK
W4Admin UI Replatform, Payment StranglerTO-BEОтдельный ADR и PCI re-scope

Gate W1 и multi-entity SoT: формулировка «SoT = order-service» в gate относится только к агрегату header/lines и idempotency create. Статус заказа остаётся master в legacy до W2 — см. таблицу в §3.2.

W0 → W1: артефакты SA, закрывающие разрыв (не только QA-техника):

  • Gate-документ W0 (приложение к ADR): список полей shadow vs production contract POST /orders/v1, порог 0,1%, категории расхождений;
  • Contract delta: при W0 green — версия OpenAPI v1.1 с полями, прошедшими shadow; deprecated поля legacy SOAP помечены в 10.01.04 Шаблон спецификации REST API;
  • Критерий перехода: gate review + sign-off SA и legacy dev; иначе W1 no-go.

W0 — механизм: Gateway дублирует запрос в shadow order-service (dry-run); сравниваются выходные DTO с legacy до commit; расхождения в Jira с категорией (mapping / implicit rule / bug); gate review еженедельно.

Gate IAM (до routing W1):

  • Маппинг всех ролей CALLCENTER_* legacy → IAM claims — в 10.01.11 Шаблон ролевой модели;
  • Negative tests: роль без order.create получает 403 на POST /orders/v1;
  • Freeze новых legacy-ролей соблюдён; нарушение — no-go через CCB.

Test strategy (08.03 Тестирование требований (статическое тестирование), 02.04.01 Верификация и валидация (V&V)):

  • Verification: контрактные тесты OpenAPI/AsyncAPI, mapping-таблицы полей, shadow parity W0, unit/integration на ACL статусов;
  • Validation: UAT на выборке магазинов (синтетика + маскирование PII), business sign-off product owner, сценарий PENDING_RESERVATION как accepted delta;
  • Performance и chaos до cutover.

Перед W1 — чеклист 10.04 Чеклист аналитика перед стартом разработки: scope волны согласован, SoT-таблица подписана, trace matrix покрывает parity и accepted delta, runbook и rollback-критерии в спецификации, NFR и reconciliation с RACI, gate IAM выполнен.

Runbook cutover и rollback данных:

  1. Freeze legacy (02.05.02 Управление изменениями (Change Control Board));
  2. Final sync + reconciliation snapshot;
  3. Переключение routing в Gateway;
  4. Smoke + hypercare 24/7;
  5. Go/no-go по NFR.

Rollback (если fail после W1/W2 routing):

  • Routing → 100% legacy create;
  • Заказы только в order-service без mirror — replay в legacy по external_id / event log (idempotent);
  • Заказы с dual write — legacy mirror остаётся master, новый контур помечает ROLLED_BACK;
  • Kafka: consumer offset rewind или compensating OrderCancelled — SA фиксирует критерии и сценарии в runbook/ADR; детали offset и процедуры rewind — DevOps;
  • Критерий «0 потерянных заказов» = все оплаченные / подтверждённые клиенту ID восстановлены в legacy в ≤ RTO.

3.6. Фаза 5. Hypercare и decommission

Hypercare 4–8 недель после W2: ежедневная сверка, KPI по 02.01.02 Цели, KPI и критерии успеха (SMART, GQM) (error rate, retry backlog, расхождения остатков).

Retire create path (W3): архив, legal hold 7 лет, обновление 03.01.02 Моделирование контекста системы (Context Diagram) TO-BE.

Closure интеграций по волнам (сводка к матрице §3.3):

Волна decommission / switchИнтеграцииДействие
W3 Retire create#1 WMS adapter (legacy SOAP path), #3–#6, #8–#10, #12Отключить legacy create-триггеры; #9 BI — только Kafka
W3 Retire create#13 ArchiveBulk load завершён, legal hold активен
W2–W4 Retain#7 Loyalty, #11 CourierДо миграции статусов (W2+) / W4
W4#2 Payment, #14 Admin LDAPStrangler payment; Replatform Admin UI

Admin UI и платежи — W4; до этого контуры #2 и #14 остаются на legacy.

Уроки кейса:

  • Сработало: явный SoT по агрегатам; строка accepted-delta в trace matrix сняла спор по async reservation;
  • Типичный промах: 6 legacy-статусов только для batch — mapping после W1; владелец mapping не был в RACI gate;
  • Big bang vs поэтапно: при > 10 интеграций и слабом тестовом покрытии — только волны + reconciliation.

4. Типовые ошибки и ограничения

Ограничения контекста OrderHub, не дублирующие таблицы из §3:

  • Неполная документация legacy — discovery непропорционально долгий; assumptions с датой пересмотра обязательны.
  • Big bang при 14 интеграциях и dual write — rollback без replay невозможен.
  • Freeze + параллельный IdM — cutover OrderHub и IAM нельзя в одну ночь без отдельного gate.
  • Audit / legal hold 7 лет — Retire create path до sign-off finance и audit заблокирован.
  • PCI boundary — любое расширение cardholder flow в новый контур требует ADR и re-scope, не только «не расширяем» в prose.

Граница SA: Kubernetes, брокер, PCI implementation, consumer offset rewind — input в ADR и runbook; аналитик держит согласованность требований, контрактов, критериев rollback и приёмки. Детали реализации — команда платформы и 08.07 Основы кибербезопасности для системного аналитика.

Связи с другими разделами базы

Источники и дополнительные материалы

Статьи и обзоры

Руководства и архитектурные гайды

Словари, стандарты и книги