During a multi-year migration, old and new systems must coexist. Which coexistence patterns are sustainable and which accumulate debt?

Sustainable patterns

1. Ownership migrated per entity, with one authoritative system at a time. Each entity type has exactly one system of record; the other consumes changes from it. Clear, verifiable, and it has a defined end state reached entity by entity.

2. Read-through with fallback. The new system serves reads, falling back to the old for data not yet migrated. Self-limiting: as migration proceeds, fallbacks decline to zero, which is a measurable progress indicator.

3. A façade routing per capability, so each capability is served by exactly one implementation and the routing table is the migration's progress record.

4. Change data capture from the authoritative system, so the non-authoritative copy is derived rather than independently written. One writer, one truth.

Patterns that accumulate debt

1. Bidirectional synchronisation. Both systems write, changes propagate both ways. Maximum flexibility and maximum danger: conflicting concurrent writes, propagation loops, and drift that is invisible until reconciliation. It also has no natural end state — nothing about it forces completion, so it persists.

2. Application-level dual-write with both systems authoritative for the same data. Not atomic; a failure between the two writes diverges the data permanently, and without reconciliation the divergence is silent.

3. Feature-by-feature splits within one entity, where the old system owns some fields and the new owns others. Every consumer must know which is which, and the knowledge spreads.

4. Temporary translation layers with no owner or expiry, which become permanent infrastructure nobody can remove.

What makes coexistence bounded rather than permanent

• A dated end state per slice, with decommissioning as the deliverable — a slice is not migrated until the old path is removed.
• Reconciliation with alerting, so drift is detected rather than discovered.
• Progress measured by fallback rate or routing table, so the programme's completion is visible.
• Coexistence cost measured and reported, so its accumulation is visible to whoever funds the programme. This is the mechanism that keeps pressure on completion.

The failure to design against

Coexistence that becomes the architecture. The synchronisation layer acquires business logic, consumers depend on it, and removing it becomes its own migration. At that point the organisation has not migrated; it has added a system.