The cutover completed on time. The target database was healthy, the new workflow accepted cases and the old application could be restored from backup. Then customer communications sent from the new path conflicted with notices already released by the old one. Payment instructions had crossed an external boundary. The technical rollback could not reverse the business.

This is the flag-day trap. Many changes are grouped into one apparently decisive event: interface, data, workflow, model, policy, roles, authority and writes. A successful deployment can still fail as a migration because the organisation cannot reconstruct which state governed, compensate external commitments or return work to a coherent operating point.

AI intensifies the trap. Model behaviour can change case selection or evidence interpretation while new orchestration changes timing, responsibility and system writes. If those shifts occur together, disagreement between old and new paths has no single cause. Recovery becomes guesswork precisely when consequence is highest.

Migration without a flag day changes a bounded unit of authority at a time. The unit may be a cohort, case type, capability, region or outcome slice. It is chosen because its state, consumers, side effects and recovery can be isolated. The organisation compares, adjudicates, transfers authority, watches the result and contracts legacy under evidence.

What migration actually movesInterface visibility is not authority transfer

An interface-first migration can appear complete while nothing consequential has moved. Users work in a new AI-assisted screen, but staff rekey every approved decision into the old platform. Reports, controls and customer communications still depend on legacy state. Adoption may be high and authority unchanged.

A migration unit is complete only when outcome-bearing work has transferred. The record names the current and target systems of record, the decision owner, permitted commands, evidence retained, recovery route and consumers. Feature enablement is merely one event. Authority transfer occurs when the target governs the bounded unit and legacy can no longer create a conflicting state for it.

The unit must be isolatable in business terms. A random share of traffic may hide cross-case dependencies, joint balances, household relationships or batch settlement. A case type or region can still share reference data and external feeds. The team maps state and side effects before selecting the cohort, then states which dependencies remain outside the migration boundary.

Progress is therefore counted as completed operating units with reconciled authority, not code converted, records copied or users enabled. A unit remains in transition while unresolved divergence, old writes or untested recovery persist. This prevents a programme from declaring ninety per cent movement while the remaining authority and contraction work carries most of the risk.

Isolation is tested through a migration topology, not accepted from organisational boundaries. The team follows identifiers, balances, limits, queues, scheduled processes, communications and control reports across the proposed unit. It asks whether a case outside the cohort can change the unit’s decision, whether the unit can change a shared aggregate and whether an external party sees both paths. Any shared state is either brought inside the boundary, protected by a versioned command contract or used as evidence that the unit must be narrower.

Volume is chosen to exercise consequence and variation rather than to manufacture an easy success. The cohort includes ordinary work, known exceptions, state changes near the cutover boundary and cases that invoke manual recovery. A tiny homogeneous group may prove connectivity while saying little about authority transfer. A representative bounded group creates useful evidence without loading the adjudication and recovery systems beyond their capacity.

Incremental legacy migration has long been used to avoid the risk of wholesale replacement.[1] Legacy systems remain difficult because their organisational dependence and embedded knowledge exceed their technical surface.[2] Continuing software evolution means target and source keep changing during the migration.[3] The control plane records those moving versions rather than assuming a frozen world.

That version record includes data mapping, source interface, model, prompt or decision policy, workflow, control and recovery procedure. A change to any one can invalidate part of the comparison. The programme states which evidence remains portable and which cases must be rerun. This avoids combining results from materially different paths into one apparent proof population.

Compatible movementExpand, migrate, then contract under evidence

The sequence begins by expanding compatibility. The target accepts the semantic and command contracts needed for one bounded unit. The source can emit authoritative events or provide governed reads. Identity, version and idempotency are established. No authority moves yet; the purpose is to create a comparison and recovery boundary.

Migration then moves one declared unit. It may start with shadow reads, progress to paired decisions and finally give the target command authority. Data backfill carries provenance and valid time. Model, prompt or policy and workflow versions remain attached to every case. Divergence is classified and adjudicated before the unit advances.

Contraction removes the old capability only after stability evidence. Writes are disabled for the migrated unit. Jobs, feeds, credentials and hidden consumers are discovered and retired. Archives and retention remain accessible through a governed route. Vendor and infrastructure obligations close. The sequence is incomplete if traffic moved but the old operating cost and risk remain live.

The rival objection is valid: incremental migration prolongs duplication, constrains target design and invites compatibility work to dominate transformation. The control plane accepts that cost and gives it an expiry. Each adapter, dual-run path and fallback has a full cost, owner and stop date. If bounded rollback is impossible and dual operation introduces greater danger, a larger controlled wave may be justified through explicit risk acceptance and rehearsed recovery.

Expand-migrate-contract is not a licence for permanent two-way synchronisation. The expansion serves a named migration unit. The migration produces evidence. The contraction removes a path or records an honestly governed permanent coexistence model. When no contraction decision exists, the programme is building another long-lived operating architecture.

Original synthesisThe nine-register migration control plane

The migration control plane is this article’s synthesis. It is not a central runtime orchestrator. It is the joined decision record that lets business, operations, architecture, data, security, risk and engineering control one migration wave. Each register names evidence, owner, version, expiry and the decision it supports.

The unit register prevents a migration wave from being defined only by traffic allocation. It records volume and consequence, but also joint state, external actions and dependency isolation. A cohort that shares an account-level limit with cases outside the cohort is not isolated merely because routing can separate it.

The authority register removes interface ambiguity. During shadow mode, the source remains authoritative. During paired decisioning, one declared comparator governs. At cutover, decision and command rights change for the unit. The target’s visible interface may precede or follow these events, but the record keeps presentation separate from authority.

The state register treats backfill as a semantic operation. Data carries source, observation time, effective time, mapping version and correction rule. Historical records that cannot satisfy the target contract are quarantined or handled by an explicit exception path. A completed copy count does not prove that target state means the same thing.

The divergence register freezes classifications and tolerances before results arrive. Otherwise teams can redefine acceptable disagreement to protect a deadline. It distinguishes data, timing, policy, model, workflow, human override and execution differences. Each class has an owner, consequence rule and closure evidence.

The cutover, rollback and watch registers make movement operational. Preconditions include comparison coverage, unresolved divergence, capacity, recovery rehearsal and command ownership. Enhanced watch observes customer, control, workforce, model and technical signals through a period tied to volume and risk, not a convenient calendar alone. Incidents can pause the cohort or return future work without corrupting completed external commitments.

Register governance separates evidence production from gate ownership. Delivery teams supply traces, comparisons and rehearsal results. Named business, control and operations owners accept the transfer and residual exposure. Definitions and tolerances are frozen before the decisive run; later changes require a recorded rationale and new evidence boundary. This prevents schedule pressure from turning a failed precondition into a softer metric after results are known.

The contraction register gives retirement equal status with deployment. It enumerates remaining legacy writers, batch jobs, feeds, credentials, reports, consumers, archives, infrastructure and vendor terms. Each item receives a removal receipt or an approved residual obligation. Migration is complete only when target authority is stable and unnecessary source obligations are gone.

Shadow and paired operationComparison needs ground truth and adjudication

Shadow mode lets the target read the same governed inputs and produce a result without affecting authority. It tests semantic translation, model and workflow behaviour, latency and observability. Its value is diagnostic. It cannot prove command execution, downstream side effects, customer response or recovery from a live failure.

Comparator quality matters. A legacy result is not automatically truth, especially if migration seeks to correct its weaknesses. The comparison contract defines the governing policy and evidence source, then allows an adjudicator to identify when the target is better, worse or simply different. Independent review is required for consequential disagreement.

Dual-run without adjudication is a negative control. Teams record agreement rates while conflicting cases accumulate in separate states. An aggregate figure conceals whether disagreements concern harmless ordering or account closure. The control plane pairs cases, classifies each material divergence and selects one authoritative outcome before cutover evidence is accepted.

Adjudication capacity is itself a gate. If reviewers cannot resolve expected disagreement within the operating tolerance, adding volume merely creates a growing evidence queue. The next action may be a narrower capability slice, better semantics or more shadow coverage. A migration wave is not delayed by this choice; it has discovered that its proof system cannot support the proposed consequence.

Negative controls are inserted into comparison deliberately. A stale source event tests whether the target exposes freshness rather than producing a plausible answer. A duplicated command tests idempotency. A policy boundary case tests the comparator and escalation route. A missing entitlement tests rejection. An external timeout tests unknown command status. Passing normal cases without these controls demonstrates throughput, not a safe migration boundary.

Machine-learning systems can accumulate hidden data dependencies, feedback loops and undeclared consumers.[4] The comparison ledger therefore records model, prompt or policy, workflow and data versions, along with whether earlier model output enters later inputs or labels. A result cannot be reproduced by naming the model alone.

The counter-case moves a regulated case cohort. Shadow mode reconstructs evidence and compares proposed decisions. A bounded dual-run adds typed commands while the old path remains authoritative. Adjudicators resolve divergence. After the gate clears, target authority moves for the cohort, enhanced watch inspects control and customer outcomes, and contraction receipts remove the old route.

The moment of transferPass reads, decisions and writes deliberately

Authority is a baton with several grips. The target may first gain read access, then permission to propose, then decision authority, then command authority. Reporting and correction may move later. The control plane records each transfer so teams do not infer authority from traffic or interface visibility.

Cutover preconditions are specific to the unit. Required state is reconciled, divergence within the frozen tolerance is closed, the command owner is present, change and recovery windows are reserved, capacity is available and monitoring is live. The source enters a declared mode for the cohort: read-only, command proxy or fully withdrawn.

Legacy writes after transfer are especially dangerous. A batch job, service account or manual screen can silently overwrite target state. The contraction inventory begins before cutover and enforcement blocks unauthorised source changes for the migrated unit. Attempts are logged as migration incidents because they reveal a hidden writer or consumer.

A model or prompt change near cutover creates another authority ambiguity. The migration record pins model, policy and workflow versions through the comparison and watch period unless a governed incident demands change. If a version changes, its evidence boundary is clear and comparison may reopen. Release convenience cannot merge migration proof from unlike behaviour.

Enhanced watch begins before the baton passes so the team knows the baseline. After transfer it monitors outcome quality, override and exception patterns, rejected and unknown commands, queue age, customer contacts, control breaches, reconciliation status and manual workload. Thresholds map to actions: investigate, pause new admissions, return future cases, compensate affected work or declare stability. The watch closes only when its required case volume, variation and time-dependent processes have been observed.

Watch evidence stays cohort-specific. Enterprise dashboards can conceal a small migrated population inside stable totals, while raw incident counts can exaggerate risk when volume changes. The receipt links each signal to eligible cases, source and target versions, prior baseline and action owner. Leaders can then distinguish migration effects from ordinary variation and close the watch without losing the audit trail.

Recovery realismSeparate restorable state from irreversible external action

Rollback fantasy begins with a database snapshot. Engineers can restore technical state, so the plan says the migration is reversible. Yet customer notices have been sent, payments instructed, regulatory submissions filed or physical work dispatched. Restoring a database does not recall those commitments, and replay may create duplicates.

The rollback envelope classifies effects before cutover. Internal technical state may be restored or replayed. External actions may be cancellable within a window, compensatable through another action, or irreversible. Human decisions and customer expectations may need remediation even when system state is correct. Each class has an owner, time limit and recovery evidence.

For the migrated unit, commands carry idempotency keys and external correlation identifiers. The recovery team can ask which effects were accepted, pending, rejected or unknown. Unknown is treated as a separate state that blocks blind retry. Compensating action follows a business rule and retains the original event, so audit history does not pretend the first effect never occurred.

A recovery rehearsal exercises an interrupted cutover with in-flight work. It restores or replays state, identifies affected customers, tests manual capacity, verifies reports and shows that source and target agree on the resumed authority point. The receipt records residual harm and any action that cannot be reversed. Leaders accept that exposure before the gate opens.

The rollback boundary also defines direction. Returning future cases to the source may be safe while moving already accepted target commands backwards is not. The plan can freeze new admissions, finish in-flight cases on the target and compensate a small affected set without reactivating general legacy writes. Calling every response “rollback” hides these different operations and encourages a dangerous two-way path.

Operational-resilience guidance focuses attention on critical operations and tolerance for disruption.[11] Digital operational resilience requirements address ICT risk, incident response, testing and third-party arrangements.[13] A migration recovery plan connects these concerns to a specific cohort, dependency and external consequence.

Finish the migrationContract jobs, feeds, credentials and commercial obligations

The never-contract migration moves traffic but leaves the source alive. Nightly jobs still extract data, service accounts retain writes, reports read old tables and a vendor contract renews. Teams call the system a fallback, although nobody rehearses returning authority. Cost and attack surface remain, while hidden consumers keep retirement risky.

Contraction starts with observability. The team maps calls, file transfers, scheduled jobs, credentials, database writes, report queries and manual screens by migration unit. Owners confirm purpose and successor. Unidentified activity is investigated before removal. Quiet does not always mean unused; quarter-end, annual and incident-only processes need an appropriate observation window.

Legacy write removal is stronger than routing traffic away. Permissions are revoked, endpoints reject migrated-unit commands and scheduled processes are disabled. A watch detects attempted use and sends it to the migration incident route. This converts hidden dependence into evidence while a bounded recovery option still exists.

Archive is distinct from continued operation. Historical state, decisions and evidence are retained in an accessible, immutable form with legal and control ownership. The archive does not preserve a general write path. Reconstruction tests show that a reviewer can understand the governing record without restarting the legacy application.

Retirement receives a post-removal watch. Attempted calls, missing reports, access requests, reconciliation breaks and customer or control enquiries are routed to the migration owner. A bounded restoration package may remain available for investigation, but it does not recreate routine write authority. The watch proves that removal is stable and discovers infrequent consumers while commercial and technical knowledge is still available.

Third-party exit includes data return or deletion, credential revocation, open incident and command disposition, portability and contract termination. Current Basel third-party-risk principles treat exit and continuity as lifecycle obligations.[12] A vendor bill ending is an economic receipt; data and access closure are separate technical and governance receipts.

The duplicate-cost expiry forces a portfolio decision. If evidence is insufficient at expiry, leaders can fund a defined additional comparison tranche, narrow the unit, accept a larger controlled wave or retain coexistence as a priced operating model. Automatic extension is excluded. This keeps compatibility work connected to authority movement and prevents two estates from continuing because contraction has no visible sponsor.

GAO’s recent review of a large financial-management modernisation highlights the value of fully incorporating key modernisation practices.[5] Its technology-readiness guidance also stresses evidence of maturity and integration rather than assertion.[6] The contraction register applies the same evidence discipline to removal, where programme attention often fades.

Interactive instrumentNo-Flag-Day Migration Gate

The gate selects the next bounded action rather than calculating a readiness score. A technically strong target may still need shadow evidence. A high-quality comparison may need more adjudication. A broad cohort may need narrowing. Unsafe authority or external-action recovery holds the migration regardless of delivery pressure.

ConclusionMove authority in bounded, provable steps

A migration is not complete because a new interface is live or most traffic reaches a target. It is complete when a declared unit of outcome-bearing work has transferred authoritative state, decision rights, controls and recovery without unresolved divergence, and the old path has contracted to an approved residual obligation.

Expand-migrate-contract creates a compatible boundary, moves one bounded unit under evidence and removes source obligations after stability. The nine-register control plane joins isolation, authority, comparison, state, divergence, cutover, rollback, watch and contraction into one decision record. Model, policy and workflow versions remain attached to the cases that proved the move.

Shadow comparison is valuable but limited. Dual-running is useful only with a governing comparator and adjudicator. Cutover passes a staged authority baton. Rollback distinguishes technical restoration from external commitments that require cancellation, compensation or remediation. Enhanced watch holds the cohort inside a visible incident and recovery boundary.

Incremental migration carries duplicate cost and compatibility constraints. Those costs receive owners and expiry. When a larger wave is safer, leaders accept its risk explicitly and rehearse recovery. When two-way operation must remain, it is governed and priced as an operating model rather than disguised as unfinished migration.

Legacy contraction finishes the work. Jobs, feeds, writes, credentials, consumers, archives, infrastructure and vendor obligations each produce a receipt. This makes progress less dramatic than a flag day and far more consequential: the enterprise can show exactly which authority moved, why it was safe and what no longer needs to run.

Evidence spineReferences

1. Brodie, M. L. and Stonebraker, M. (1995), Migrating Legacy Systems: Gateways, Interfaces and the Incremental Approach, Morgan Kaufmann. ACM record.
2. Bisbal, J., Lawless, D., Wu, B. and Grimson, J. (1999), ‘Legacy Information Systems: Issues and Directions’, IEEE Software, 16(5), 103–111. doi:10.1109/52.795108.
3. Lehman, M. M. (1980), ‘Programs, Life Cycles, and Laws of Software Evolution’, Proceedings of the IEEE, 68(9), 1060–1076. doi:10.1109/PROC.1980.11805.
4. Sculley, D. et al. (2015), ‘Hidden Technical Debt in Machine Learning Systems’, Advances in Neural Information Processing Systems 28. NeurIPS record.
5. US Government Accountability Office (2026), Financial Management Systems: DHS’s Modernization Plans Should Fully Incorporate Key Practices, GAO-26-107863. GAO.
6. US Government Accountability Office (2020), Technology Readiness Assessment Guide, GAO-20-48G. GAO.
7. National Institute of Standards and Technology (2022), Secure Software Development Framework Version 1.1, NIST SP 800-218. doi:10.6028/NIST.SP.800-218.
8. National Institute of Standards and Technology (2023), ‘AI Risk Management Framework: Core’. NIST AIRC Core.
9. National Institute of Standards and Technology (2023), Artificial Intelligence Risk Management Framework 1.0, NIST AI 100-1. doi:10.6028/NIST.AI.100-1.
10. Board of Governors of the Federal Reserve System, Office of the Comptroller of the Currency and Federal Deposit Insurance Corporation (2026), ‘Revised Guidance on Model Risk Management’, SR 26-2. Federal Reserve letter.
11. Basel Committee on Banking Supervision (2021), Principles for Operational Resilience. Bank for International Settlements.
12. Basel Committee on Banking Supervision (2025), Principles for the Sound Management of Third-Party Risk. Bank for International Settlements.
13. European Union (2022), ‘Regulation (EU) 2022/2554 on Digital Operational Resilience for the Financial Sector’. EUR-Lex.
14. International Organization for Standardization and International Electrotechnical Commission (2023), ‘ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system’. ISO standard record.