[Blog]()System 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. **[Jonathan Perez]()**Co-founder · Design, product and sales October 8, 2026 · 7 min read **Short answer** A cutover plan must state when the old system stops accepting writes, what the business validates and who authorizes continuing or rolling back. Rehearse recovery and decide how to preserve transactions created after the switch. Restoring an earlier copy without reconciliation can lose orders, payments or movements. ## 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. [Download CSV worksheet]() In this guide - [Choose a window around actual operations]() - [Fictional example: 24 orders and two later entries]() - [Rehearse with people and dependencies available]() - [Write a rollback procedure someone can execute]() - [Close the change with a follow-up review]() ## 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. ## Review your cutover and rollback rehearsal Your latest rehearsal and closing calendar help discuss when to cut over, which failure would stop the change, and which new transactions must be reconciled before returning. We can review them in a free consultation. - Calendar of critical orders, dispatches and closing tasks - Connector, printer and owner list - Latest rehearsal with times and new transactions to reconcile [Book a free consultation]()[Ask on WhatsApp]() Related - [Software consulting]() - [Custom software]() ## Frequently asked questions ### Does a backup make rollback automatic? 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. ### Should both systems operate at the same time? 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. ### Who decides to cancel the change? 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. ### How much time should we reserve? 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 1. [Cutover stage]()AWS 2. [Plan your migration]()Microsoft Last updated: October 8, 2026 ## Keep reading [Data migrationOct 8, 2026 ### Migrating data without duplicates: keys, conflicts and import review]()[Business continuityOct 8, 2026 ### A backup is not enough: testing restoration, data loss and return time]()[Software acceptanceOct 8, 2026 ### Accepting software: business tests and verifiable open issues]() --- Canonical: https://nightlysoftware.com/en/blog/system-cutover-rollback-plan Updated: 2026-10-08 Description: Rehearse a system change, name the person who can stop it and preserve new transactions during recovery. Includes a cutover and rollback worksheet.