Migration is a coexistence problem

Migration is a period in which old and new services coexist, information moves and authority may change. It should be designed as an operating model in its own right. A programme can describe the target architecture clearly while leaving the transition service ambiguous. Users then decide locally which system to trust, duplicate work across both and reconcile conflicts through informal channels. The migration plan should identify the authoritative source and permitted work at each meaningful transition state.

Consider a fictional materials-request service moving from a legacy register to a new governed catalogue and case workflow. Some open requests began under the old item descriptions and approval rules. New requests may use improved identities. A technical import can preserve fields while leaving the meaning of historical cases unresolved. The migration must determine which cases transfer, which remain in the old route and how users identify the controlling record. It should not declare equivalence merely because the target accepts the imported data.

The transition should state its scope and population. A staged migration may begin with recognised routine items while complex substitutions remain in the legacy service. That can reduce risk and create learning, provided users understand the boundary and exceptions remain owned. The programme should avoid presenting a partial population as an enterprise-wide cutover. The approval record should identify what is included, what remains and what evidence will permit the next stage.

Coexistence creates a reconciliation obligation. If users can update both services, the enterprise needs a rule for resolving differences and a way to identify them. If one service is read-only, users need a legitimate route for corrections. If the old service remains authoritative for selected cases, the new interface should not imply that its copy can approve or close those cases. The operating design should express these distinctions clearly enough for routine users to act without consulting the programme team every time.

The continuing service owner must be involved before cutover. A delivery team may manage technical migration while the operating team inherits unresolved records and duplicated work. The sponsor should state the handover conditions, funded resources and authority needed to run the transition and target service. A successful data-load report is relevant evidence within that wider acceptance, not a substitute for it.

Migration acceptance should test whether the new service preserves the information and decisions required for its intended use. Record counts can help identify missing data, but equal counts do not establish equivalent meaning. An old item relationship may become several target records; several legacy labels may reconcile to one governed identity. The programme needs a controlled mapping and an explanation of these transformations. A numerical equality that ignores the transformation can be misleading.

The materials service should inspect representative operating cases, including routine, unresolved and changed requests. The review examines whether identity, approval history and current obligation remain intelligible in the target. A closed request should not become apparently open because its state label was translated mechanically. An unresolved technical substitution should not become approved because the target has no equivalent hold field. These cases test meaning rather than merely format.

Reconciliation should identify discrepancies, their decision consequence and the responsible resolution route. A harmless description difference may be accepted with a record. A changed authority or missing controlling instruction may block the case's intended use. The migration team should not assign all discrepancies the same status. Its objective is a usable and accountable service, not the disappearance of every difference through arbitrary correction.

The programme should preserve the mapping version and the basis of important corrections. If the mapping changes during migration, the enterprise needs to know which cases used which rule. It should also determine whether already migrated records require review. A correction applied only to future imports can leave inconsistent meanings across the target population. The operating owner should authorise the resolution and maintain the evidence needed to explain the resulting records.

The acceptance record should state the limits of inspection. A test population does not establish every record's correctness unless the method and coverage actually support that conclusion. The study does not invent a sample size or defect rate. For a real programme, the enterprise should choose inspection and reconciliation methods appropriate to the consequence, disclose remaining uncertainty and retain controls where wider evidence is incomplete.

Rollback is often described as returning to the old system. The operating question is whether the enterprise can return to a coherent service after legitimate work has occurred in the new one. New approvals, physical events and commercial commitments cannot simply be erased. The rollback design should identify which actions are reversible, which records must be reconciled and who authorises continuation. A technical backup alone does not answer those questions.

In the fictional materials migration, a new request is approved after cutover while an older unresolved substitution remains in the legacy route. If a target defect requires rollback, the new approval must retain its authority and history. The old system may need an authorised record of that event or a linked continuity record. A user should not be required to reconstruct the approval from memory. The service needs a designed route for legitimate transition work.

Rollback conditions should be defined before the cutover decision. An inability to preserve controlling authority, an unresolved identity transformation or an unavailable exception service may be a reason to hold or reverse a stage. Other defects may be manageable within a controlled correction route. The sponsor should identify which consequences are unacceptable for the intended use rather than use an arbitrary technical defect count as a universal decision threshold.

The decision to roll back should have a named authority and usable evidence. Technical specialists can establish the defect and feasible response options. Operating owners assess continuity and affected decisions. The sponsor or delegated release authority approves the service action under the actual governance arrangement. The route should function when the usual programme leaders are unavailable, otherwise an urgent migration incident can expose the same coverage gap as an ordinary operating exception.

A rollback test should include reconciliation after restoration. It should examine whether the authoritative record, open cases, approvals and user instructions agree. The test may reveal that a staged pause with a continuity route is safer than a full technical reversal. The operating plan should allow a justified response within its approved authority. The aim is coherent permitted work, not loyalty to a predefined technical manoeuvre.

The cutover seam can fail even when the opening import and the final record counts agree. In the fictional materials service, a legacy request reserves an item before its migrated copy becomes active. A receiving team then posts a physical receipt in the target, while a cancellation already authorised in the legacy route arrives later through the interface. The service must distinguish when each event occurred from when each system learned about it. Overwriting the older-looking record can discard a legitimate event; replaying the same message can create a second apparent reservation. The problem is event lineage, not simply agreement between current field values.

Preserve the business event identity, the originating record, its mapping version and its relationship to the event it changes. A correction to the item identity should link to the original reservation rather than silently turn it into an unrelated request. A repeated message with the same business event identity should be recognised as a repeat. A cancellation with a different identity still requires an authority and scope check; it cannot be discarded merely because the target has already received the item. The linked account must explain the coexistence of reservation, physical receipt and commercial cancellation without implying that any record can undo a physical event.

The reviewer can examine this seam by replaying the preserved business events in different arrival orders. The controlling record should retain the same legitimate obligation when the events are unchanged; any order-dependent result needs an explicit operating rule. Include a repeated delivery, an authorised correction arriving after cutover and an event whose source identity cannot be matched. The unmatched event belongs in an exception account with its original payload and unresolved relationship, rather than in an invented target identity. This is an author-designed acceptance scenario, not a report that the fictional service has passed a test or that a production interface is idempotent.

Reversal has a different consequence after dispatch. Restoring an earlier software copy can reopen the request while equipment has already left the store. The continuity record must therefore retain the dispatch fact, establish the current custody question and identify the authorised next instruction. If a receipt is disputed, a restored backup provides historical evidence but does not settle custody. The event account supplies the specific acceptance and reconciliation work that a delivery schedule must represent. It also identifies what a cutover report should retain: the authoritative event chain, unmatched events, decisions needed to reconcile them and the mapping version used. A clean import count alone cannot discharge that work.