Migrate Off a Legacy System

Goal: replace an existing system end to end: designed, approved, delivered, and decommission verified, not assumed.

1. Model the Migration Honestly

In the design, the outgoing system appears as a legacy component: real technology stated, inside the boundary (it still holds your data), never a gap. The flows between new and old: the data bridge, the sync during coexistence: are first-class design elements, because they are where migrations actually fail. (Migration modeling)

2. Assure Without the Legacy Excuse

The design review scopes by ownership: the legacy system's internal shortcomings are transition context, never blockers; the reason you are migrating is not an argument against the migration. Integration into it: an unencrypted bridge, missing cutover controls: is fully in scope, at full severity.

3. Approve, Then Plan the Delta

After approval, generate the delivery plan in migration mode: build work for what is new, change work for what changes, decommission work for what goes away; switch-off is planned, not remembered. Export to your tracker; progress syncs back onto the diagrams.

4. Coexistence, Watched

During the long middle, drift detection watches both directions: the new estate appearing (discovery confirms components exist), delivery executing in order, and the legacy vendor's contract status while you still depend on it.

5. Cut Over as a Revision

The end of the legacy system is a design decision: revise to remove the legacy component, approve, and the baseline updates. From that moment drift expects the system to be gone: if it is still observed running, that is a finding. Decommissioning is verified by the same machinery that watched everything else.

The Whole Point

Most migration plans end at "go live". This one ends at "the old system is provably off"; the difference is which one survives an audit.