This isn't an argument for not modernizing. It's an argument for understanding that the technical question — "how do we rewrite this?" — is downstream of a more important one: how do we change the airplane's engine while it's still flying?
Three patterns handle this well. None of them are new. All of them are routinely under-applied.
1. The strangler-fig pattern
Named after a tropical plant that grows around a host tree and eventually replaces it, the strangler-fig pattern means: route traffic from the legacy system to a new system one capability at a time, until the legacy system has nothing left to do.
In practice this looks like:
- A facade or API gateway in front of the legacy system that can route specific request types to a new service.
- A new service that implements one capability — say, "calculate quote" — with feature parity to the legacy implementation.
- Traffic shifted gradually: 1%, then 10%, then 50%, then 100% — with the ability to revert at every step.
- The legacy implementation of that capability stays online (as a fallback) until the new one has been running clean for long enough to retire it.
The strangler-fig is slower than a big-bang rewrite. It is also dramatically less risky. You never have to make a single irreversible decision — the system gets replaced incrementally, with every step reversible.
2. Dark launches and parallel runs
Before you switch traffic to the new system, you can run the new system against real production load without anyone depending on its output. This is sometimes called shadow traffic, dual-write, or parallel run. The pattern works for both reads and writes:
- Read paths: Send each production read to both the legacy and the new system, return the legacy result to the user, and compare the two answers offline. Discrepancies become a bug list — fixed before any user sees the new system.
- Write paths: Dual-write to both the legacy and the new data store. Reconcile periodically. When the reconciliation has been clean for a defined window, you can stop writing to legacy.
The cost is real — you're running two systems for a period — but the value is that you've validated the new system against actual production traffic before any customer depends on it. Most of the surprises in cutover come from edge cases that lab testing doesn't surface. Parallel runs surface them in production without consequences.
3. Phased cutovers with explicit go/no-go gates
A cutover is not a single event. It is a sequence of progressively larger commitments, each with its own decision point. A well-run cutover looks something like:
- Internal users only — employees of the company using the new system for real work. Catches the obvious bugs.
- 1% of external traffic — a random or geographic subset of customers. The first signal of how it behaves in the wild.
- 10%, then 50% — at each step, a defined hold period to confirm metrics are within tolerance before advancing.
- 100% + legacy as fallback — full traffic on the new system, but the legacy system is still running and routable.
- Legacy decommissioned — only after a defined period of clean operation on the new system.
Each step has a go/no-go gate with explicit criteria: error rates, latency, business metrics. If a gate fails, the traffic shifts back. The migration pauses while the issue is diagnosed and fixed. Reversal is a normal operation, not an emergency.
The biggest predictor of a smooth modernization isn't the quality of the new architecture. It's whether the team running the migration treats every cutover decision as reversible. Teams that build for reversibility ship modernizations on time. Teams that build for "we'll get it right the first time" ship them late, with at least one production incident.
How to sequence: business risk, not technical preference
The order in which you modernize components matters. Most teams sequence by technical convenience — start with the easiest piece, work toward the hardest. That ordering optimizes the wrong thing.
Sequencing by business risk looks at three factors:
- Blast radius if it breaks. What's the worst-case business impact if this capability fails for an hour? A day? A week? Modernize the smallest blast-radius components first to build operational confidence.
- Rate of change. Capabilities that change frequently (regulatory, market-driven) are where modernization pays back fastest — you save delivery time on every subsequent change. Prioritize these once the team has its sea legs.
- Dependency depth. Capabilities at the bottom of the dependency stack (data, identity, core domain models) are highest risk to change but unlock everything above them. These usually go in the middle of the sequence — after operational confidence is built, but before downstream changes need them.
The output of this exercise is a sequenced backlog, not a "which technology should we use" debate. The technology choice is a follow-on decision per component, not a global mandate.
When to pause
The hardest discipline in modernization is knowing when to stop for a quarter — even when momentum is good. A few signals that warrant a pause:
- Operational incidents related to the new architecture are increasing, not decreasing.
- The team is burning down stories faster than they're being defined — usually a sign that work is being scoped to fit velocity rather than reality.
- A major business event (peak season, regulatory filing, M&A close) is in the near horizon. Cutovers don't happen during peak. Period.
Pausing is not failure. Pausing is the move that prevents a small problem from becoming the incident that ends the program.
The honest takeaway
Modernization is rarely a technology problem. It's a sequencing and risk-management problem with a technology component. The teams that ship modernizations on time are the teams that treat every step as reversible, instrument for production-shaped validation early, and pause when the signals say to pause.
That discipline isn't glamorous. It's also the thing that separates the modernizations that show up in case studies from the ones that show up in post-mortems.