A ride-hailing platform operating in eight South-East Asian markets of the kind Grab serves is replacing its legacy dispatch system market by market behind a routing layer. Two small markets are fully migrated; the largest is next. Each market follows a four-step sequence - shadow reads, dual writes with the legacy store authoritative, new store authoritative with legacy still written, legacy writes off. Which step is the point of no return?

The sequence and what each step is for

• Shadow reads. Serve from legacy, also ask the new system, compare. The gate to move on is not "it works" but a mismatch rate with every remaining mismatch explained — a useful bar is under 0.1% over a full week including a weekend peak, with each residual difference attributed to a known cause.
• Dual writes, legacy authoritative. Both stores receive the write, legacy answers reads. Needs an idempotency key per write so a retry is not applied twice to one side.
• New store authoritative, legacy still written. Reads come from the new system; the legacy copy is maintained as insurance.
• Legacy writes off. The old system is now inert for that market.

The point of no return

It is step three, not step four, because that is when the legacy copy stops being a restorable snapshot.

The new system exists because it models things the old one could not: a trip state the legacy schema has no column for, a fare breakdown with more components, a driver assignment with a reason code. The moment the new store is authoritative, it starts accepting writes that the reverse translation into the legacy model cannot represent without loss. The legacy rows keep being written and keep looking healthy, so the illusion of a rollback path survives the day it actually ends.

How to keep the valve open longer: constrain the new system to the legacy model's expressive range until that market is finished, and run the reverse translation as a job whose untranslatable-record count is a monitored number, separate from its error count. The first day that counter leaves zero is the day rollback ended, and you want to learn it on that day.

Why the other options fail

• Legacy writes off. This is the step that feels final, and by then nothing changes: the ability to go back was lost when divergence began. Switching it off is bookkeeping.
• Dual writes with legacy authoritative. Fully reversible — the new store is a replica nobody reads, and rollback is a routing change plus discarding it.
• Shadow reads. Reversible by deleting a comparison job. It is the step most often cut short for schedule, which is why mismatch analysis is the cheapest insurance in the whole programme.

Where data can diverge and how you would know

Dual writes diverge whenever one side fails and the other succeeds, so the signals are a continuous reconciliation over a sliding window of keyed state per market, reporting two separate numbers: records that differ, and records that could not be translated at all. The second is the one that bounds reversibility and the one nobody builds.

How long it really takes

The first market is bespoke; the second market is the test of whether you built a process or a one-off, and it is the one to schedule honestly. Markets do not run in parallel, because a defect found in one has to gate the rest. A sound planning assumption is that market one takes about as long as markets two to eight combined, and that both systems stay in production for the entire programme — the coexistence period, measured in quarters, is the real cost, not the cut-overs.

When not to migrate market by market

When markets share state. Cross-market trips, one global driver identity, a shared pricing table or a single accounting ledger all mean the market is not a cut point, and routing by market gives you the appearance of isolation with none of the substance. Slice on the boundary where the data actually separates — if that is capability rather than geography, migrate by capability and accept that every market is exposed to each step.