Migration begins before the import script
A migration plan must define what happens to data created while the move is in progress. Inventory entities, identifiers, relationships, timestamps and attachments. Decide which system owns writes at each point. A script that imports yesterday’s snapshot correctly can still lose today’s changes. Name the business owner who accepts the result and the operator who can stop the cutover.
Rehearse with representative, protected data
Use sanitized data that includes duplicates, missing values, old status codes and large records. Check totals and relationships, then verify a sample of complete business journeys. For a fictional membership service, matching the member count is insufficient: active entitlements, payment references and cancellation state must also reconcile. Record how long rehearsal steps took in that environment rather than promising an unmeasured outage window.
Define reconciliation beyond record counts
Prepare checks for counts, key relationships and business meaning before writing the migration script. In the membership example, verify that a current entitlement points to the correct member and subscription, and that a cancelled membership is not accidentally reactivated. Check attachments and reference identifiers as well as the main table. Keep a list of records intentionally excluded, with the reason and the person who approved it. An unexplained difference is a failed check, even if the total number of imported rows looks reassuring.
Write the cutover as operator actions
Create an ordered runbook naming the action, operator, expected evidence and stop condition at each step. Include communication to staff, control of new writes, final data capture, import, reconciliation, application switching and observation. Rehearse the sequence in an isolated environment and revise it where someone needed an undocumented decision. The rehearsal duration describes that environment only; it should inform the plan without becoming a promise about an untested production move. Arrange access and an escalation route before the window, so an operator does not have to find the account owner during a blocked step.
Protect changes created after the switch
The moment users start writing to the new system, reversal needs more than a database copy. Identify the records created or changed since the cutover, their external effects and how they will be preserved if service returns to the old application. Where reverse transfer is not safe, define a controlled forward-recovery route and make that limit explicit before launch. Decide who can make the stop-or-continue call and which evidence they need. After a successful transition, keep the agreed recovery material protected and retire temporary access and duplicate jobs according to the runbook.
A rollback needs a write policy
A brief write freeze simplifies reconciliation but interrupts work. Parallel operation can reduce interruption while increasing synchronization and conflict-handling effort. Restoring the old application is not a valid rollback if users have already made changes only in the new database. Define a point of no return, reverse synchronization where feasible, or a controlled recovery path that preserves those changes.
Prepare the cutover sheet
Ask Orvun Labs to review the migration alongside the replacement software. Keep a timed sequence, named owners and objective stop conditions accessible to the operators. Do not rely on the same person improvising both the migration and its recovery.
- Which checks must pass before opening writes?
- How are late changes and failed imports reconciled?
- Who can pause the launch, and on what evidence?
- How will new-system changes survive a reversal?
