Data migration and cutover in large public‑sector systems: a pragmatic board pack for approving go‑live

The real problem: why migration and cutover still fail in 2026

Failures are rarely single technical bugs. They are system failures in the sociotechnical sense: incomplete data mapping, environment differences that let defects pass testing, mismatched supplier runbooks, weak reconciliation, insufficient shift‑pattern staffing and decision ambiguity in the first 72 hours. Public‑sector EPR and multi‑module programmes repeatedly show the same pattern: early-stage design and procurement focus on features and headline savings; the invisible, cross‑cutting tasks that define a safe cutover (final extract design, reconciliation, runbook automation, capacity verification and clear Go/No‑Go authority) are deprioritised until they become critical path risks.

The evidence base is clear. NHS clinical migration guidance codifies staged data checking and sign‑off; programme boards repeatedly require a defined data‑check cadence and an agreed final cutover window. Gate‑style readiness reviews (Gate 4 / Readiness for Service) explicitly require a migration plan, demonstrable data reconciliation criteria and a glide‑path to decommissioning legacy systems. Audit reports and trust board papers show cost, schedule and safety harm arise from unclear sign‑offs and weak early‑life support.

How the elements interact: process, data, systems, people, suppliers and controls

Process: migration succeeds when the end‑to‑end cutover process is fully defined, rehearsed and owned. That means runbooks that sequence extract → transform → final extract → import → reconciliation → live acceptance, with decision points and timeboxes. Change and release controls must be separate from deployment execution: a single Go/No‑Go authoriser must exist, not a dispersed committee.

Data: the project must show traceability from requirements and regulatory obligations to each migrated dataset: what fields migrate, mapping rules, record‑age cutoffs, transformation logic, and acceptance criteria. Where production data is used in testing, there must be documented anonymisation or legal approval and a reconciliation plan for anything transformed during testing.

Systems: environment parity is not aspirational. Staging must reproduce critical integrations, authentication flows and performance characteristics. A passing test in a mismatched environment is not evidence. The test architecture must include the same interface endpoints and test harnesses used during cutover rehearsals.

People: cutover is a 72‑hour operations exercise. Shift rotas, escalation paths, floorwalkers and clinical champions must be staffed and reimbursed. Early‑life support teams require documented runbooks and rapid supplier‑to‑trust escalation paths.

Suppliers: contracts should mandate migration deliverables (extract format, reconciliation reports, tools, automation, number of rehearsal runs, responsibility for data‑fixes). Commercial and contractual levers must be explicit in supplier statements of works and acceptance criteria.

Controls and governance: the board decision must be supported by artefacts that show traceability, not assertions. Commit to Go only on completed, evidence‑rated inputs (see next section).

The lifecycle stages you should expect to see (and the specific evidence for each)

1) Discovery and mapping — artefacts: data inventory, field‑level mapping matrix, legacy extraction samples, risk register with data‑critical items. Evidence leaders should see sampled legacy records mapped to target records with explicit transformation rules.

2) Build and configuration — artefacts: configuration baselines, requirements‑to‑configuration traceability matrix (RTM), automated migration scripts in source control. Evidence: signed RTM pages for clinically critical workflows and tagged configuration commits corresponding to acceptance tests.

3) Testing and rehearsal — artefacts: environment parity attestation, performance and integration test reports, synthetic and obfuscated test datasets, and at least two full end‑to‑end rehearsal cutovers that include final extract and reconciliation. Evidence: rehearsal logs, reconciliation exception lists and time‑to‑fix metrics.

4) Final extract and pre‑go‑live window — artefacts: final extract specification, checksum/hash reports, full reconciliation reports and a signed Data Migration Acceptance Certificate. Evidence: confirmation of extraction success, reconciliation within agreed thresholds (see below) and an approved cutover runbook.

5) Decision point: Go/No‑Go — artefacts: Go/No‑Go checklist signed by named authority, capacity confirmation (network, compute, helpdesk), staffing rosters, supplier shift and escalation roster, incident and rollback playbooks. Evidence leaders should require the signed checklist with attachments: test evidence, reconciliation, and operational readiness confirmation.

6) Early‑life (first 72 hours) and stabilisation — artefacts: early‑life support roster, monitoring dashboards, triage queues and validated rollback triggers. Evidence: real‑time dashboards, number of high‑severity incidents, average time to fix, and a formal stabilisation review at the end of the early‑life window before any decommissioning activity.

Concrete gates, thresholds and failure modes (what to hard‑stop on)

Hard evidence thresholds to require before you approve Go: (a) reconciliation pass rate for critical records at a defined sample size (e.g. 99% match on a statistically valid sample with remaining exceptions classified and mitigated), (b) at least two successful end‑to‑end rehearsals including final extract and import, (c) environment parity attestation demonstrating identical integration endpoints and equivalent load characteristics, (d) named Go authority with documented escalation rights, and (e) staffed early‑life rosters for at least 72 hours post‑go‑live.

Failure modes to hard‑stop on (examples): – Unresolved reconciliation exceptions for clinically material fields (e.g. allergies, medications) above threshold. – No tested rollback path for critical data imports. – Test environment lacks critical integrations (queues, identity providers, reporting endpoints). – Insufficient supplier presence for data‑fix tasks or lack of clear supplier remediation SLAs. – No signed Data Migration Acceptance Certificate or incomplete Go/No‑Go checklist.

If any single hard‑stop condition is present, the conditional action is either to pause go‑live until the issue is closed and re‑rehearsed, or to adopt a staged go‑live limited to non‑critical modules with an explicit remediation window. The board must avoid binary pressure that forces an unsafe decision.

What a board pack should contain (exact items to ask for)

1) One‑page risk‑rated summary with the Go/No‑Go recommendation and the named decision authority. 2) The Go/No‑Go checklist with attachments: final rehearsal logs; reconciliation summary and sample reconciliation files; environment parity attestation; capacity tests; staffing rosters; supplier shift schedules and contact trees; migration runbook and rollback playbooks; legal and data protection sign‑off (where production data has been used for testing). 3) A short exception report listing unresolved items, action owners, mitigations, and an estimated time to closure. 4) A post‑go‑live stabilisation plan with KPIs and an explicit date for the stabilisation review. 5) The contractual remediation and acceptance schedule that links supplier deliverables to payment or exit conditions.

Boards should demand that every evidence item be machine‑readable or reproducible (rehearsal logs, CSV reconciliation attachments, tagged commits), not a high‑level narrative. That makes the decision auditable and the acceptance binary in evidence terms rather than in rhetoric.

Sequenced, conditional recommendations for senior leaders

Recommendation 1 — Require the evidence pack: do not accept a go‑live paper without the Go/No‑Go checklist and the reconciliation artefacts. If the pack is incomplete, defer the decision. The only exception is an explicit, documented staged go‑live with limited scope and independent acceptance criteria.

Recommendation 2 — Insist on two full rehearsals that include final extract and reconciliation under production‑like load. If only one rehearsal is available, accept only a staged module go‑live with a stabilisation fence and an agreed date for full go‑live after repeat rehearsal.

Recommendation 3 — Make the approval conditional on early‑life staffing and supplier commitments: a signed roster for 72 hours plus evidence of supplier on‑call availability and SLAs for migration fixes. If staffing is insufficient, require corrective staff augmentation before go.

Recommendation 4 — Quantify acceptance: demand a sampled reconciliation threshold and explicit remediation SLAs for exceptions. Exceptions above threshold must carry a named remediation owner and a contingency plan that is rehearsed.

Recommendation 5 — Require a stabilisation review before legacy decommissioning and any invoice retention tied to stabilisation KPIs. Do not permit legacy decommissioning until stabilisation KPIs are met and the stabilisation review has been completed.

Antares recommended actions

These are Antares's recommended first actions for organisations turning the issues in this article into practical governance and delivery.

1. Demand a single, signed Go/No‑Go checklist with attached reconciliation files, rehearsal logs and environment parity attestation before any business go‑live approval.
2. Require two full end‑to‑end rehearsals that include the final extract and import under production‑like conditions; otherwise accept only a limited staged go‑live.
3. Insist on staffing and supplier rosters for at least the first 72 hours, with named escalation points and tested contact trees.
4. Make legacy decommissioning conditional on a formal stabilisation review and measured stabilisation KPIs; tie final supplier payments or retention to those KPIs.
5. Ask for machine‑readable evidence (tagged commits, CSV reconciliation, logs) so the decision is auditable and the acceptance criteria are objective.