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.
Every incremental migration has one, and it is routinely treated as a brief transitional inconvenience when it is a distinct operating state with its own architecture, cost and failure modes.
What must be designed for it, rather than improvised: data consistency between the two, with a chosen direction of authority per entity and a synchronisation mechanism; identity mapping, since the same customer or order exists in both with different keys; reporting, which must produce correct aggregate figures across a split estate; support, where staff must know which system a given customer is on; and integration, since every third party connected to the old system needs a plan.
The cost is the part that surprises steering committees: during coexistence you pay for both systems, plus the synchronisation machinery, plus the operational overhead of running a split estate. The business case usually models the before and after states and omits the middle, which can run for years.
The risk that follows is a programme that stalls in coexistence — the state that is more expensive than either endpoint and is politically easy to remain in, because the remaining migration is the hard, unglamorous portion.
The countermeasure is to plan the coexistence period explicitly: a defined duration, a named owner, funded synchronisation, and a decommissioning date treated as a commitment rather than an aspiration.