Migration is an operating event
A new service can look complete while the old records still live elsewhere. Bringing those records across is not simply a file import at the end of the build. It changes where officers look for evidence, how they find a current case and which system they trust for the next action. A migration therefore needs an operating plan as well as a technical script.
A rehearsed migration gives the team a way to test that plan before relying on it. The rehearsal should use the intended sequence, defined checks and named responsibilities. It should produce evidence that can be reviewed: what was transferred, what was rejected, what was reconciled and what remains unresolved. “The script ran” is a starting observation, not the acceptance decision.
Define what is moving
The first task is an inventory. Identify the records, attachments, identifiers and relationships the new service needs. Determine which system is authoritative for each field. An application without its supporting document may not be usable. A payment reference without its relationship to the application may be confusing. The unit of migration is the record in its operating context, not merely a row count.
Rules for duplicates, incomplete records and historical categories should be agreed before the import. These are decisions about the meaning of the record. The engineering team can identify inconsistencies and implement agreed treatment, but it should not quietly invent policy to make the data fit. Unresolved cases need a visible exception list and a responsible reviewer.
The mapping between old and new identifiers also deserves deliberate treatment. Officers may still receive correspondence that references an old number. A useful migration preserves the ability to connect that reference to the new record. The history of a service does not disappear because the application has a different database schema.
Rehearse the full sequence
The rehearsal begins before the import. Confirm the source snapshot, access permissions, destination configuration and the conditions under which work will be paused or redirected. Run the versioned migration in the intended order. Record timing and errors. Apply the same validation steps planned for cut-over. The purpose is to discover the gaps while there is still time to change the plan.
Counts are necessary and insufficient. Reconciliation should check meaningful relationships and outcomes. Do attachments open against the correct records? Are statuses mapped as agreed? Can an officer find an application and perform the next permitted action? Are historical decisions still understandable? A row that exists in the database can still be operationally wrong.
User acceptance testing and migration validation meet at this point. Scripted cases should include migrated records, not only records freshly created in the new system. The officer needs to test the experience they will actually encounter at go-live. Defects should be recorded, assigned and retested through the same disciplined process used for the application build.
Write the decision points
A cut-over plan should say who can decide to proceed, pause or return to the previous arrangement. It should specify the checks that inform that decision. A plan that assumes success at every step offers little help when a critical validation fails. The point of a decision gate is to make the response clear before the pressure of launch arrives.
Restoration and rollback are related but different questions. A backup may restore a system to an earlier state. Returning to an earlier operating arrangement can also require reconciling work accepted during the change. The team should examine both. Rehearsing restoration tests a technical capability; agreeing the treatment of intervening transactions tests an operating policy.
Communication belongs in the plan. Officers need to know which system to use, when access changes and where to report a problem. Applicants may need clear information about service availability. The internal support team needs a known route for triage. Good engineering does not remove the need to tell people what is happening.
The first month is part of delivery
Go-live is the beginning of real operating feedback. Heightened support provides a defined period in which defects, questions and unexpected patterns receive concentrated attention. The service should have a way to distinguish an application defect from a data issue, a permission problem or a training need. Those categories lead to different fixes.
Written incident reports preserve what the team learned. A useful report explains the impact, the sequence, the response and the action taken to reduce recurrence. It should be specific enough to help the people maintaining the system later. The record is part of handover, not an embarrassment to hide once the incident has passed.
The handover package should include the migration scripts, mapping decisions, validation evidence and operating runbooks alongside the source code and data. A ministry should be able to understand how its records arrived in the new service. The next team should be able to repeat the checks without relying on the memory of the engineer who performed the first import.
A rehearsal should end with a short review of the evidence and an updated runbook. Record the steps that took longer than expected, the checks that needed clarification and the people who were missing from a decision. Give each unresolved item an owner. The next rehearsal can then test the revised sequence rather than repeating the same exercise with the same assumptions. This is particularly useful when the cut-over depends on several teams. A shared list of actions and decision points makes the dependency visible before the final migration window has been agreed and announced.
A rehearsed migration does not promise that nothing unexpected will happen. It establishes that the team has practised the work, made its assumptions visible and prepared a controlled response. That is the delivery standard that matters when a public service changes the system underneath its daily operation.