A wallet platform must migrate from a monolith to services while serving live traffic. What sequence minimises risk, and which step is usually done in the wrong order?

The sequence that works

1. Put a façade in front. All traffic routes through a layer that can direct a request to either the monolith or a new service. Without this, every subsequent step requires a client change, and clients are the slowest thing to move.
2. Extract reads first. Build the new service, populate its store from the monolith by change data capture, and serve reads from it behind a flag. Reads are reversible: if the new service is wrong, flip the flag and nobody lost data.
3. Verify with shadow traffic: send production reads to both, compare results, and fix the differences before serving anything from the new path. This finds the semantic divergences that no amount of code review will, and it is cheap.
4. Move writes, which is the expensive and irreversible step. Dual-write briefly, verify, then cut over with the monolith's table becoming a read-only replica.
5. Remove the old code path, deliberately, with a date. This is the step that is skipped, leaving the estate permanently carrying both.
6. Decommission, including the data, the infrastructure and the on-call rota entry.

The step usually done in the wrong order

Moving writes before verifying reads. It is tempting because writes are where the interesting logic is, and it forecloses the cheap reversal. A write migration that turns out to be wrong is a data reconciliation exercise; a read migration that turns out to be wrong is a flag flip.

What must be true throughout

• The old system remains authoritative until the cutover, and everything else is a projection. Two authorities for one fact is the state that produces permanent reconciliation work.
• Every step is individually reversible, or it is not a strangler — it is a rewrite with extra ceremony.
• The façade is not a permanent architectural component. It is scaffolding, and leaving it in place after the migration is a common way the estate ends up with an unnecessary hop and an owner nobody remembers.

The specific consideration for a wallet

Balances cannot be temporarily wrong. So the write migration for the ledger is the one place a dual-write-and-compare period is mandatory rather than optional, and the comparison must be a full reconciliation rather than a sample — because a discrepancy in a sample means an unknown discrepancy everywhere.