Migration Overview: How to Approach Any Migration

Every migration decision sits at the intersection of two different kinds of pressure (Golding, ch. 13, "The Migration Balancing Act"):

A migration chosen purely for the second reason, in a technical vacuum, tends to lose executive support the moment it stops looking urgent to the business. The strategy — what to migrate, in what order, and how fast — has to be driven by the business motivators; the technical desires ride along on whatever budget and priority the business case earns, not the other way around.

Two timing strategies compete for every migration (Golding, "Timing Considerations"):

In practice, "modernize first" rarely survives contact with the business: customers and the market do not pause while an architecture is rebuilt, and early feedback from whatever ships first usually reveals that the target design needs to change anyway. That feedback loop is what tips the balance toward incremental modernization for almost every real migration — not because it is architecturally purer, but because it is the only strategy that keeps learning from real usage throughout the migration instead of only at the end.

However the timing question is answered, one choice is off the table: rewriting the whole system from scratch and cutting over in one release. As Richardson attributes to Martin Fowler, "the only thing a Big Bang rewrite guarantees is a Big Bang" (Richardson, ch. 13.1.2) — a single, high-risk cutover with months or years of accumulated divergence between the old and new systems, tested only at the very end, with no way to walk any part of it back independently.

The alternative every migration path in this section follows instead is the strangler fig, Martin Fowler’s StranglerFigApplication: named for the strangler fig tree, which grows around a host tree, gradually replacing it, until the host can eventually be removed while the strangler continues standing on its own. Applied to software, new functionality is built around the edges of the legacy system, one capability at a time, routed to through the same seam — typically the gateway --, until the legacy system has been reduced to nothing worth keeping.

A handful of principles recur, independent of which specific migration path applies:

Each path-specific page below calls out how its situation avoids these five pitfalls concretely; named once here, they are the same five failure modes underlying every one of them: