Migration support playbook for teams that cannot lose reporting continuity.

A migration is controlled when the team can explain what will move, how each important result will be validated, who can stop the cutover, how service will be restored if the target fails, and what evidence is required before responsibility transfers to operations.

This playbook applies to database, warehouse, ETL, reporting, application-data, and cloud-platform migrations. It can guide a complete program or a defined support workstream such as migration development, QA, reconciliation, performance review, reporting continuity, cutover readiness, rollback evidence, or handover.

The migration control model

1. Define scope, ownership, and success

Start with a migration charter that names the business sponsor, program owner, technical leads, source and target owners, validation owner, security approver, cutover manager, operations owner, and rollback decision authority. Define what is in scope, explicitly out of scope, and dependent on another team.

Success should be measurable. Examples include reconciliation thresholds, allowed downtime, maximum data lag, report availability, transaction success, target performance, accepted defects, and the date by which legacy operation can end. Avoid a single criterion such as “all rows loaded.” A technically complete load can still fail because business rules, reports, permissions, or operating procedures do not work.

2. Map systems and reporting dependencies

Build a dependency map from source capture through databases, files, integrations, transformations, semantic models, dashboards, exports, and operational consumers. Record schedules, owners, service expectations, credentials, network paths, data classifications, and business deadlines.

Pay particular attention to dependencies that are easy to miss: direct analyst queries, spreadsheets fed by extracts, scheduled email reports, vendor files, hard-coded connection strings, personal service accounts, archived tables used for audits, and month-end jobs that do not run during a short test period.

3. Profile the source before designing the move

Profile row volumes, growth, key distributions, nulls, duplicates, invalid values, encoding, timestamps, large objects, referential integrity, and historical anomalies. Separate defects that already exist in the source from defects introduced by migration logic. Decide whether each source issue will be corrected, preserved, quarantined, or explicitly accepted.

Record source-to-target mappings as versioned rules. For every transformed field or entity, document source, target, conversion logic, default behavior, rejected-value handling, business owner, and test case. If a rule cannot be explained to a reviewer, it is not ready for an irreversible production run.

4. Design validation at multiple levels

Validation should prove completeness, correctness, usability, and control. Use multiple methods because no single check detects every failure.

• Volume: row counts, file counts, partitions, date ranges, and expected incremental changes.
• Control totals: sums, balances, quantities, distinct entities, and other business totals by meaningful segment.
• Field rules: data types, formats, mapping logic, defaults, null handling, truncation, and precision.
• Relationships: primary keys, duplicates, orphan records, referential integrity, and hierarchy behavior.
• Sampling: representative normal, high-value, boundary, historical, and known-problem records.
• Business workflows: end-to-end transactions, updates, reversals, approvals, exports, and operational queries.
• Reporting: dashboard values, KPI definitions, refresh timing, filters, drilldowns, and reconciliations.
• Nonfunctional controls: performance, concurrency, security, audit logging, backup, recovery, and monitoring.

Define thresholds and owners before testing. A difference may be expected because of timing, cleansing, or changed business logic, but it still needs evidence and approval. Store results so the team can compare rehearsals and prove what changed.

5. Build repeatable migration execution

Migration scripts, pipelines, infrastructure changes, and validation checks should be versioned and repeatable. Record run identifiers, input boundaries, start and finish times, row counts, rejected records, warnings, errors, retries, and code versions. Re-running a step must not silently duplicate or corrupt data.

Separate the migration into restartable stages where practical. A failed late-stage validation should not require repeating every extraction if verified intermediate outputs can be preserved safely. Define how partial runs are detected, cleaned up, resumed, or abandoned.

6. Rehearse the complete cutover

A rehearsal should use production-like volume, permissions, topology, and operating constraints. Execute the actual runbook with the people expected to perform the cutover. Time every stage, capture manual decisions, record defects, and test communications as well as technical steps.

At minimum, rehearse extraction or synchronization, transformation, load, validation, application connection changes, report refreshes, performance checks, monitoring, issue triage, stakeholder updates, and rollback. Update the duration estimate using measured evidence and preserve contingency inside the window.

7. Establish cutover gates and rollback criteria

The cutover runbook should identify each task, owner, expected duration, prerequisite, completion evidence, and escalation path. Gates should be explicit: source freeze confirmed, final synchronization complete, critical validation passed, applications connected, priority reports reconciled, monitoring active, and business owner approval recorded.

Define rollback before the team is under pressure. State which failures trigger immediate rollback, which can be repaired within the window, who decides, the latest safe decision time, how source and target changes will be reconciled, and how users will be informed. Test the rollback path during rehearsal rather than treating it as a diagram.

8. Protect reporting continuity

Reporting continuity deserves its own plan. Identify which reports must remain available during the move, acceptable data staleness, final legacy refresh, first target refresh, reconciliation owner, and temporary distribution method. A migration may be acceptable for the application while still creating an executive or regulatory reporting failure.

Freeze metric definitions during cutover unless a planned change has been approved and communicated. Compare source and target results at the same business cutoff. Document expected differences caused by timing or redesigned logic and obtain business-owner acceptance rather than leaving analysts to explain differences after launch.

9. Staff cutover and hypercare for decisions

The cutover roster should cover migration execution, source, target, applications, infrastructure, security, validation, reporting, business acceptance, communications, and incident management. Name primary and backup contacts, working hours, escalation channels, and decision authority. More people are not automatically safer; every participant needs a defined responsibility.

Hypercare begins when the target enters service. Increase monitoring and reconciliation frequency, maintain rapid triage, review issues daily, and keep the project and operations teams connected. Track incidents, validation exceptions, performance, user impact, report timeliness, workarounds, and backlog ownership.

10. Exit hypercare with evidence

Do not end hypercare only because a fixed number of days passed. Define exit criteria such as stable processing across required business cycles, accepted reconciliation results, no unresolved critical defects, normal performance, successful backups, tested support escalation, current runbooks, trained operators, and ownership of the remaining backlog.

Complete an operating handover using Datrick's database operations handover checklist. Archive the final migration package: scope, architecture, mappings, scripts, test evidence, decision log, exceptions, known issues, runbooks, monitoring, restore procedure, and post-migration improvement backlog.

Migration readiness checklist

• Scope, exclusions, success measures, owners, and decision authority are documented.
• Source, target, application, integration, reporting, security, and operational dependencies are mapped.
• Source data has been profiled and existing defects have explicit treatment.
• Mapping rules and migration logic are versioned, reviewable, logged, and restartable.
• Validation covers technical, business, reporting, performance, security, and recovery requirements.
• A production-like rehearsal has measured duration and exposed operating defects.
• Cutover gates, owners, evidence, communication, and go/no-go authority are explicit.
• Rollback criteria, decision time, execution steps, and reconciliation are tested.
• Reporting continuity and temporary workarounds are approved by business owners.
• Hypercare coverage, monitoring, triage, exit criteria, and operating handover are ready.

Frequently asked questions