Reverse Sync

The day after a cutover, the rollback plan is usually fiction. Writes have been accepted by the new system and the legacy platform's state stopped at go-live, so reverting traffic produces a system that cannot fulfil yesterday's orders or reconcile yesterday's payments. The code can be rolled back; the data cannot.

Reverse sync is the mechanism that keeps the option alive. Every write the new system accepts is translated into the legacy schema and applied there, for an agreed period, so the old platform stays current enough to take traffic back.

Why it matters

Because the window in which a migration can be undone is measured in hours by default, and the defects that force an undo are often found in weeks. A wrong rounding rule, a mis-mapped tax code or a broken entitlement produces plausible output, so it is found by a human comparison or a month-end reconciliation rather than by an alert.

Reverse sync also changes the politics of go-live. A cutover with a credible rollback can be scheduled on a normal Tuesday; one without becomes an all-hands event that only happens when everyone is certain, which is how go-lives slip by quarters.

Implementation patterns

• Derive it from the same mapping as the forward path, inverted and tested, rather than written separately. Two independently written mappings drift and the divergence is silent.
• Decide the lossy cases in advance and write them down. New fields with no legacy column, new enumeration values, new relationships: each needs a documented choice - default value, shadow column, or reject the write - because each choice has a visible consequence in the legacy system.
• Keep legacy-side identifiers stable so a reverted system recognises records it never created. An identity scheme chosen for the new system's convenience makes reverse sync impossible.
• Make it idempotent and replayable from a durable log, so an outage of the legacy side pauses rather than loses the stream.
• Monitor lag and diff, not just liveness: reverse sync that is running and 40 minutes behind offers a rollback with 40 minutes of data loss, which is a number the business must know.
• Set the closing date with its evidence when it is built, usually after one full business cycle including month-end.

Industry example

Reverse sync is routine in regulated replacements and rare elsewhere, which matches where its cost is justified. Core banking and insurance ledger replacements commonly run a write-back path for weeks after cutover so the authoritative system of record can be restored if a calculation defect emerges; the same shape appears in payments platform migrations, where the ledger - not the application - is what cannot be rebuilt. Published accounts of large retail and SaaS migrations more often describe partitioned cutover instead: Notion's 2021 sharding work and Slack's multi-year keyspace-by-keyspace move to Vitess both reduced exposure by moving a slice at a time rather than by preserving a reverse path.

Failure scenarios

• An untested reverse path that has been running for weeks and fails on first use, during the incident.
• Silent lossy mapping, where new-model data is flattened to a legacy default and the reverted system serves subtly wrong values.
• Identity collisions when the legacy system generates ids for records that already have new-system ids.
• Loops: the legacy write triggers forward sync, which triggers reverse sync again. Origin tagging on every write is the standard guard.
• A coexistence period with no end date, so two systems and two mappings become permanent architecture and the migration is never finished.
• Reverse sync lag ignored, so the rollback that was promised as clean loses an hour of transactions.

Trade-offs

What is gained is a real rollback for a defined period, which is sometimes a regulatory requirement rather than a preference. What is paid is the harder half of the mapping, double write capacity, engineering attention on a system being retired, and a continuing obligation to keep the legacy schema working. The honest comparison is against a partitioned cutover: going live for one country or tenant at a few per cent of volume bounds the exposure without any reverse path, and for most products that is the better trade. Reverse sync wins when the data is financial or regulated, when repair-forward is not credible, or when the legacy system must remain the system of record until a sign-off.

When not to use it

Skip it when forward repair is credible - content, workflow and most operational data can be recomputed or corrected in place, and the reverse mapping is insurance against an event you would handle differently anyway. Skip it when the legacy system is being decommissioned immediately and its hardware or licence ends on a date, because keeping it current costs the thing the migration was for. And do not build it where the new model is radically richer: if half the new fields have no legacy representation, the reverse path is a lossy fiction that will be trusted in an emergency, which is worse than having no rollback and knowing it.

Interview question

Q: Your payments platform cuts over in six weeks. The sponsor asks whether rollback will be available after go-live. What do you commit to, and what do you build to make that commitment true?

What a strong answer covers: stating that rollback stops being a code decision within hours of the first accepted write; committing to a bounded window with a stated cost rather than an open-ended promise; building reverse sync derived from the inverted forward mapping, idempotent and replayable, with origin tagging to prevent loops; writing down the lossy cases and their chosen handling; monitoring lag as the data-loss figure of any rollback; proposing a partitioned cutover as the cheaper risk reduction; and fixing the closing date after one full month-end.

Quick check

Quiz: Why is the reverse direction harder to map than the forward one? The new model is usually richer, so fields, relationships and enumeration values exist that the legacy schema cannot represent, forcing documented lossy choices.

Flashcard: What guards against a forward-reverse sync loop? Tagging every write with its origin and refusing to re-propagate writes that arrived from the other side.