Skip to content

Migration Planning

Many designs do not start from a green field; they replace something. Migration planning makes the replacement itself first-class: the plan covers what is added, what changes, and what is decommissioned, instead of pretending the target architecture appears from nothing.

How a Migration Design Is Modeled

The outgoing system appears in the design as a legacy component: its real technology is stated, it stays inside the authorization boundary until cutover (it still holds your data), and the design review treats its internal shortcomings as transition context rather than blockers; the reason you are migrating is not an argument against the migration.

Flows between the new components and the legacy system are the migration's real work: the data bridge, the sync during coexistence, the cutover feed. They appear on the diagrams and generate integration work in the plan.

The Migration Delta

For a package that revises or replaces an approved predecessor, delivery planning can generate in migration mode: instead of a full build-everything breakdown, the plan is the delta between the approved old design and the new one:

  • New components → build work, as in a standard plan.
  • Changed components → the change work, tied to what specifically changed.
  • Removed components → decommission work, so switch-off is planned rather than remembered.

The plan records its migration provenance, the business case reports it, and the export and twin work exactly as they do for standard plans.

The End of the Legacy System

Cutover is a design decision: a revision that removes the legacy component from the design, goes through review and approval, and updates the baseline. From that moment, drift detection expects the legacy system to be gone, which closes the loop: decommissioning is verified, not assumed.