Coexistence Patterns
Running old and new together for years without corrupting either.
5 to work through
-
advanced
A migration will take eighteen months, during which old and new systems both serve production. How should the coexistence period be designed?
2 min answer -
advanced
During a multi-year migration, old and new systems must coexist. Which coexistence patterns are sustainable and which accumulate debt?
2 min answer -
advanced
Eighteen months into a coexistence period, customer records are authoritative in the new system and order records are still authoritative in the old one. A refund credits the customer and cancels the order line. What happens the first time the credit commits and the cancellation is rejected?
3 min answer -
advanced
Old and new stores both hold 42 million customer records during a coexistence period. The nightly full-row comparison now takes 6 hours 40 minutes against a 4-hour window, and the legacy side serves the export at about 1800 rows per second. Roughly what does a hash-bucket comparison cost instead, and which assumption decides whether it fits?
3 min answer -
advanced
Your cutover plan says switch reads, then switch writes, then decommission. A reviewer asks what happens at 02:00 if the new store turns out to be wrong after writes have moved. What mechanism makes the write switch reversible, and what is the honest unavailability window?
3 min answer
4 terms in this topic
Coexistence Period
The interval during which old and new systems both operate and must be kept consistent, which is longer, more expensive and riskier than most plans assume.
patternPer-Entity Migration State
A field on each business entity naming the system currently authoritative for it, which makes the unit of migration one row rather than one capabilit…
patternReverse Replication Cutover
Keeping a replication stream flowing from the new store back to the old one after writes have moved, so that rolling back stays a routing change inst…
patternWrite-Ownership Boundary
The line drawn during coexistence that names exactly one system as the writer for each piece of state, placed along business transaction boundaries s…
Neighbouring topics
Legacy Modernization
General material on modernising existing systems.
Legacy Assessment
Understanding what a system does before deciding what to do with it.
The Six Rs
Rehost, replatform, refactor, repurchase, retire, retain — per application.
Rehosting
Lift and shift: fastest, cheapest, and capturing none of the benefits.
Replatforming
Targeted changes that capture operational wins without a rewrite.
Refactoring & Re-architecting
Changing structure incrementally while the system keeps running.
Rebuild vs Re-architect
Why greenfield replacement fails, and the narrow cases where it does not.
Strangler Fig
Routing capabilities to new implementations behind a facade, one at a time.
Application Decomposition
Finding seams in a monolith, starting from the data.
Database Migration
Moving engines, versions and schemas without losing data or uptime.
Data Migration Strategies
Backfill, dual-write, reconciliation and verification.
Zero-Downtime Migration
Expand, migrate, contract — and the contract phase that never happens.
Parallel Run
Shadowing the old system to discover the rules nobody documented.
Cutover Planning
Rehearsals, go/no-go criteria and a rollback that has been executed.
Legacy Integration Patterns
Anti-corruption layers, adapters and CDC against systems that cannot change.
Mainframe Modernization
Batch windows, COBOL, and the risk profile of core banking systems.
Migration Risk
Bounding blast radius, staging by cohort, and honest readiness reporting.
Modernisation Business Case
Pricing tail risk so deferred maintenance becomes fundable.
Decommissioning
Actually switching the old system off, and proving nothing depended on it.