During a multi-year architecture transition, a team keeps a legacy monolith and a new microservices platform running in parallel for over a year, with dual-write synchronization keeping both in sync. What risks does this long-lived transition state introduce, and how would you mitigate them?

## What a dual-run state is A **dual-run transition state** keeps two systems — typically a legacy system being retired and its replacement — operating side by side for an extended period, with some mechanism keeping their data consistent so that both can serve reads, and sometimes writes, correctly. Two mechanisms, with very different risk: - **Application-level dual writes** — the riskiest version of this. The calling code, or two separate client paths, writes the same logical change to both systems as two separate operations, one after another, with no distributed transaction spanning them. Because there is no atomicity across the two writes, any partial failure — the first write succeeds and the second times out, retries, or fails outright — leaves the two systems in different states with nothing forcing them back into agreement. - **A single source of truth with replication** — a safer mechanism that achieves the same goal differently. Designate one system as the single source of truth for a given entity, and derive the other side via **change-data-capture (CDC)** or event-driven replication reading off the source's transaction log, so there is exactly one write path and the second system is an eventually-consistent, derived read replica rather than an independently-written peer. ## Why organizations accept it Organizations accept this messier intermediate state because a hard, all-at-once cutover from an old system to a new one is usually too risky to attempt directly on a system carrying live production load — customers, revenue, or regulatory data can't tolerate an unplanned outage or corruption if the cutover goes wrong, so a period where both systems are live and can be compared and gradually shifted between is the practical way to build confidence and allow safe rollback. The dual-run period exists specifically to buy the organization the ability to reverse course cheaply if the new system misbehaves, and to migrate traffic incrementally rather than betting the whole system on a single cutover event. ## The trade-off The trade-off is that every additional week of dual-run buys risk reduction and reversibility at the cost of **doubled operational surface area**: - two systems to monitor, patch, capacity-plan, and staff on-call for, and - two data stores that both need to keep working correctly even though one is explicitly being phased out. Teams also face a **scope-freeze tension** — neither system gets meaningful new investment, because the legacy side is 'going away soon' so bugs get patched but features don't, and the new side is still mid-migration so it can't yet take on unrelated feature work either — which can leave the business unable to respond to changing requirements on either front for the duration of the transition. ## Failure modes 1. The signature failure mode of true dual writes is **silent data drift**: some fraction of records diverge between the two systems because of partial write failures, differing validation logic, or race conditions between concurrent writers, and without an active reconciliation process, nobody notices until a downstream consumer — finance, a customer complaint, an audit — surfaces the mismatch, often long after the drift began. 2. A second failure mode is **the transition state becoming permanent**: without a calendared decommission date and an accountable owner, the 'temporary' bridging state loses priority to newer funded initiatives, and the organization ends up paying the double-operational-cost tax indefinitely — years past the original estimate is a common real-world outcome, with dedicated engineers effectively permanently assigned just to keep the legacy side alive and in sync. 3. A third is **reconciliation debt**: teams intend to build drift-detection tooling 'later' but never prioritize it over feature work, so the sync mechanism runs unmonitored and any drift compounds silently for the entire life of the transition. ## A worked example, and the mitigation playbook Consider a payments team migrating account balances from a legacy monolith to a new microservices ledger, using application-level dual writes for six months before finance discovers roughly 2% of accounts have quietly diverged, traced to write failures on the second leg of the dual write during periods of elevated latency, with no reconciliation job in place to catch it. The concrete fixes illustrate the general mitigation playbook for long transition states: 1. **Replace true dual writes** with a single-source-of-truth-plus-CDC design so there is exactly one authoritative write path and no write-path race to fail. 2. **Add automated reconciliation jobs** that continuously diff the two systems and alert on divergence. 3. **Treat the transition state itself as a first-class architecture** with its own monitoring, SLAs, and on-call ownership rather than an informal hack. 4. **Set a hard, calendared decommission date** for the legacy side with a named executive sponsor accountable for hitting it. 5. **Where possible, use an incremental strangler-fig cutover**, migrating one capability or customer segment at a time behind a routing facade, so any single slice's dual-run window is measured in weeks, not the entire system sitting in a fragile, long-lived intermediate state for a year or more.