A database migration can finish without an import error and still leave the business unable to work. Customer records may exist but belong to the wrong account. Totals may match while attachments are missing. Plan the move around what users must be able to do with the data after cutover.
The runbook below is a planning sequence for a business-system move, not a set of commands to run against a live database. The technical method depends on the source, destination, scale and acceptable downtime.
Before the rehearsal: define the contract
Inventory the source systems, record types, attachments, audit history and integrations. Name the person who can approve the meaning of each important field. “Customer status” may be a sales label in one system and a billing rule in another.
Create a mapping with source field, destination field, transformation, default and rejection rule. Include stable identifiers so records can be related correctly. Decide how duplicates, missing values, time zones, historic currencies and deleted accounts are handled. Keep the original export unchanged as evidence; transformations should happen in a controlled working copy.
The evidence pack
- A dated source inventory and agreed migration boundary.
- A field map approved by business owners.
- Expected counts and meaningful reconciliation totals.
- A list of known exclusions and unresolved data problems.
- Named owners for execution, validation and the go/no-go decision.
Rehearsal day: use an isolated destination
Run a trial with representative data and restricted access. Avoid copying personal information into general development environments when masked or reduced data will answer the question. Keep migration logs useful without exposing passwords, tokens or unnecessary customer details.
Separate data transfer from account provisioning and application configuration. A successful record import does not prove that user roles, scheduled jobs, file storage or external connections are ready.
Use the database vendor's documented backup and restore method. For example, PostgreSQL's SQL dump documentation explains format and restoration choices. That documentation is specific to PostgreSQL; it is not a universal procedure for moving data between unrelated products.
Validation: compare meaning, not only counts
Reconcile record counts by useful groups, then sample linked journeys: a customer with several orders, a cancelled order, an account with historic invoices and a record with attachments. Confirm dates, decimal values and relationships. Totals should be explained, including documented differences caused by agreed exclusions.
Ask real business users to check visibility and ordinary tasks with their intended roles. A manager seeing a record does not prove that the right department can access it or that another customer cannot. Microsoft's migration acceptance-test guidance illustrates the importance of validating data access through the application.
Cutover: control changes on both sides
State when the old system stops accepting changes and how any final changes are transferred. If both systems remain writable, somebody must resolve conflicting updates. An uncontrolled period of parallel use can undermine an otherwise sound import.
Write the sequence for disabling old jobs, applying the final transfer, validating the destination, enabling new jobs and reconnecting integrations. Record what “ready” means at each step and who can pause the release.
The rollback question to answer in advance
If users create new orders in the destination before a fault appears, how will those orders be retained if you return to the old system? Restoring yesterday's source does not automatically preserve today's new work. Agree that reconciliation before cutover, including the point after which a forward repair is safer than reverting.
After release: keep the old evidence available
Monitor rejected jobs, reconciliation differences, access complaints and key business tasks. Keep the old system read-only for the agreed retention period where appropriate, with access controlled and licensing understood. Retire it through a deliberate decision rather than deleting it as soon as the homepage loads.
Put a retention owner on the export
“Keep the original” does not mean retain every copy forever. List the location, permitted users and approved retention period for exports, rehearsal databases and logs. Include those temporary copies in the post-migration cleanup plan. Preserve required evidence through controlled retention rather than leaving untracked personal data on a developer's machine.
For the business-user checks, use the UAT worksheet. Include the migration boundary, rehearsal and recovery responsibilities in any bespoke software project, rather than treating data movement as an incidental upload.
