How to move a system that cannot stop

A routing layer sits in front of the legacy system, and newly built features are served by the new system while everything else continues to hit the old one. That state is held for months while features move across one by one, and the legacy system is retired when the last one lands.

The point of this approach is that it is always reversible. If the new system misbehaves you revert the routing. A big-bang cutover has no such option.

Prerequisites

Three things are always settled before the first move.

• Data ownership — which system may write to which tables. Once both systems write to the same table, reversal is gone.
• Session and identity — both systems must recognise the same session, or users get logged out mid-migration.
• Observability — during migration you must be able to tell which side served a request. Distributed tracing goes in first.

Data migration

Data moves before the code and more slowly than the code: dual write, a verification window, reads switched over, and only then legacy writes turned off. Each step has a written rollback procedure that we actually rehearse.