A migration will take eighteen months, during which old and new systems both serve production. How should the coexistence period be designed?

The decisions that must be made explicitly

• Which system is authoritative for each entity, and how a request knows. Routing by entity — this policy is on the new system, that one is on the old — is usually cleaner than routing by operation, because it avoids a single entity's state being split across two systems.
• How data flows between them. One-directional if possible: the authoritative system publishes and the other consumes. Bidirectional synchronisation during a migration is the source of most coexistence incidents, because conflicting updates have no good resolution.
• What happens to cross-entity operations that span both systems. These need an explicit protocol — a saga, a queue, or a rule that such operations are routed to one side — rather than being discovered when they fail.
• How long the period lasts, with a date. A coexistence period with no end date becomes permanent, and the organisation carries two systems indefinitely.

What must be true for it to be survivable

• Both systems observable together, with a single view of an entity's state regardless of which system holds it. Support and operations cannot be asked to know which system a customer is on.
• Consistent identifiers across both, so records can be correlated. Different identifier schemes make every investigation a join through a mapping table.
• Reconciliation running continuously, not as an end-of-migration activity. Divergence detected on day three is a bug; divergence detected in month twelve is a data quality project.
• A rollback per entity, so a migrated entity that behaves incorrectly can be returned rather than requiring the whole migration to pause.

The organisational cost

Everything is done twice. Every incident is investigated in two systems, every feature is either implemented twice or withheld, and the team's context is split. This cost is why the period must be time-bounded and why migrating faster is usually cheaper than migrating carefully over a long period.

The specific risk in a regulated domain

A policy or claim whose lifecycle spans the cutover is governed by rules and data in both systems. The design must decide whether such records migrate mid-lifecycle — which requires the new system to accept in-flight states — or complete on the old system, which extends the coexistence period to the longest lifecycle.

That choice is frequently the single largest determinant of the migration's duration, and it is made early and often without being recognised as a decision.