BlogSystem cutover
Changing systems: rehearsal, cutover and rollback conditions
Returning to an old system after new orders have been entered requires reconciliation. Decide that condition before switching.
Test worksheet: System cutover: rehearsal and rollback plan
Returning to an old system after new orders have been entered requires reconciliation. Decide that condition before switching. Record inputs, expected outcome, evidence, owner and observed result.
Choose a window around actual operations
The quietest time is not always the best time to switch. A carrier may dispatch overnight, a distributor may receive orders at closing and a factory may run continuous shifts. Choose a window when owners are available and agree how work will be recorded during an outage. Note the time zone and the final valid document in the old system.
Microsoft recommends presenting tested rollback procedures and naming decision authority. AWS distinguishes returning before data changes from returning after new transactions. The same distinction matters for a business system: changing an access address does not, by itself, preserve data created during cutover.
Fictional example: 24 orders and two later entries
A distributor rehearses stopping the old system at 18:00. Its control file contains 24 open orders and their reservations. At 18:20 the team validates the new system; at 18:25 it enters N-025 and N-026. At 18:30 route printing fails. This synthetic example is not a migration performed by Nightly.
Returning to the 18:00 copy would remove N-025 and N-026. Before reopening, the owner must decide whether to fix printing in the new system or export and enter those orders in the old one, preserving references and preventing double reservations. The rehearsal must cover both possible routes. Simultaneous writes to two systems are not proposed without designed reconciliation.
| Stage | Question before continuing | Stop condition |
|---|---|---|
| Before pausing entry | Are copies, users and integrations ready? | Missing access or untested recovery |
| After import | Do orders and reservations reconcile by status? | Unexplained differences |
| Before accepting new work | Can the team complete the critical flow? | Unable to dispatch or confirm |
| After new entries | Will rollback retain every new transaction? | No executable reconciliation procedure |
Rehearse with people and dependencies available
The test needs more than opening a homepage. Include lookup, entry, approval, printing and export, as well as attachments and external connections. A connector still reading the old system can produce inconsistent information even if the new interface works. Name the person who pauses each automated task and the person who checks its restart.
| Rehearsal case | Expected result | Evidence to retain |
|---|---|---|
| Pause entry at 18:00 | No new orders enter the old system | Final reference and blocking record |
| 24 open orders | Same amounts and reservations per order | Identified comparison |
| Rerun the initial batch | No additional orders or duplicate reservations | Counts and references |
| Failure before new entries | Return to the old system within the agreed time | Rehearsal timeline |
| Failure after N-025 and N-026 | Both survive exactly once | Order reconciliation |
| Connector restarted | Resumes at the agreed point without replaying closed work | Connector record |
Write a rollback procedure someone can execute
Each step needs an owner, prerequisite, observed duration and final verification. “Restore the backup” leaves questions open: which version, where, with which credentials and what happens to files and queued work? Timing starts when the outage is declared and ends when the business can complete the agreed flow. Test backup restoration separately before cutover.
Set a decision deadline and communication channel. If verification is delayed, mark it unknown; silence does not mean approval. Provider restrictions, transfer speeds and team availability affect the plan. A failed rehearsal informs scope changes or a different date, rather than providing a reason to hide the problem.
Close the change with a follow-up review
During the agreed observation period, review created documents, differences and queued tasks, rather than availability alone. Retain the old system as permitted by your contract and data policy; a responding first screen is not a reason to delete it. For identity resolution, see data migration without duplicates; for delivery criteria, use business acceptance tests.
In the downloadable worksheet, record the time, owner and observed rehearsal result before reserving a real window. An operating calendar, connection inventory and anonymized order samples can make a free consultation for software consulting useful in defining what must be demonstrated before switching.
Frequently asked questions
No. It may exclude work created later. Restoring a database also does not guarantee restoration of files, access or connectors. The rehearsal must verify the business flow and explain how new transactions will be preserved.
Only with an explicit rule for where writes happen and how results reconcile. Entering one order twice without stable keys and reconciliation can duplicate work. Keeping one system available for lookup may be simpler than allowing dual writes.
A business-authorized person should own the decision, supported by data and operations reviewers. Document conditions and a deadline. The supplier can explain technical risk; acceptance of the operating outcome belongs to the agreed business owner.
Use a comparable rehearsal and allow time to verify and communicate. File size is not enough: dependencies, permissions, people and integrations matter. Do not promise a window from a test that measured only a database copy.
Sources
- Cutover stageAWS
- Plan your migrationMicrosoft
Last updated: