Migration · 10 min read
Eight questions to answer before migrating a critical data platform
A readiness framework for inventory, dependencies, validation, security, performance, cutover, rollback, and operational ownership.
A critical migration is a controlled business change
A data-platform migration is ready when evidence meets agreed acceptance criteria—not when a copy job can start. The team needs a validated inventory, dependency map, approved target architecture, reconciled data, performance and security evidence, a rehearsed cutover and rollback runbook, and named decision owners.
The questions below apply to databases, warehouses, lakehouses, ETL and CDC pipelines, semantic models, reports, and the applications that depend on them.
If any readiness answer depends on hope rather than reviewable evidence, reduce the scope or resolve the gap before cutover.
1. Why are we migrating?
State the intended business or operating outcome before choosing the target. Examples include shorter report latency, a defined recovery objective, removal of unsupported technology, stronger residency or security controls, lower cost to serve, or faster delivery of governed data products.
Do
- Record the current baseline and target measure.
- Name an executive sponsor and a data or business owner with authority to accept the result.
- Give readiness, rehearsal, and cutover tasks to named people.
Do not
- Define success as “the data moved” or “the new platform is live.”
- Begin with a preferred product and invent the reason afterward.
- Allow a deadline or sunk cost to override agreed exit criteria.
2. Do we know the estate?
Create a controlled inventory that can support scoping, architecture, testing, and ownership decisions. Record data assets and volumes, engines and versions, keys and schemas, pipelines and schedules, criticality, retention, service levels, backup and recovery, identities, classifications, peak workload, cost, and owners.
Configuration files alone rarely reveal the full production contract. Include spreadsheets, file drops, dormant month-end jobs, partner feeds, manual extracts, and other work that automated discovery can miss.
3. Do we understand the dependencies?
Map upstream and downstream reads, writes, APIs, messages, files, batch and streaming flows, shared databases, BI reports, semantic models, authentication, network paths, and external parties. For each dependency, record the business effect if data is late, missing, duplicated, or unavailable.
Validate tool-generated maps with workload owners. Identify components that must move together and any temporary hybrid connections required when they do not.
4. Is the target architecture approved?
The target is more than a destination service. Record decisions for data models and keys, transformations and history, batch and streaming patterns, retries and idempotency, capacity and workload isolation, region and residency, network, identity and secrets, observability, cost controls, backup and recovery, and ongoing ownership.
Warning signs
- The target was selected before performance, security, availability, or residency requirements were known.
- Average load was used for sizing while peak concurrency and growth remain untested.
- Legacy permissions and workarounds are being copied without review.
- Engine conversion, rule redesign, semantic-model replacement, and every report are bundled into one cutover without accepting the combined risk.
Protect the comparison baseline: freeze avoidable change
Delivery lesson: once requirements and the source baseline are approved, freeze avoidable changes to source data structures, ETL logic, business rules, and reporting definitions until the migrated platform is in production and stable.
A migration or ETL conversion has a specific purpose: reproduce the agreed behaviour and results on a different platform. It is not automatically an end-to-end re-engineering programme. When the source system keeps changing during implementation, developers must repeatedly update mappings, conversion logic, tests, and documentation. That rework creates a moving target and can affect both the project schedule and the planned production cutover.
Changing business requirements creates a second problem. The team loses the stable reference needed to prove that the target is equivalent to the previous system. If a calculation, rule, data definition, or expected report changes during conversion, a difference may come from the migration or from the new requirement. The result becomes difficult to reconcile and acceptance becomes subjective.
Do
- Approve and version the source schema, ETL logic, business rules, semantic definitions, and expected outputs used as the migration baseline.
- Define a change-freeze window from requirements sign-off through production stabilisation.
- Defer enhancements and business-rule redesign to a separately scoped post-migration phase.
- Use a formal exception process for urgent security, regulatory, production-defect, or operational changes.
- For every approved exception, record the owner, reason, source impact, target change, schedule impact, new test evidence, and updated reconciliation baseline.
Do not
- Allow routine source-system releases to change tables or ETL jobs without migration impact review.
- Mix conversion and redesign while keeping the original schedule and acceptance criteria unchanged.
- Change a KPI, calculation, or business definition and still compare it directly with the old result.
- Accept undocumented emergency changes or expect developers to absorb repeated rework without re-planning.
A freeze does not mean ignoring a critical production need. It means every unavoidable change is controlled, applied consistently to both the source and target where required, reflected in the test baseline, and included in the cutover decision. If the volume of exceptions becomes significant, the programme should re-baseline its scope and schedule instead of pretending the original migration plan is unchanged.
5. Can we prove that data and business outputs are correct?
Define reconciliation before conversion. Technical checks should cover expected objects and schemas, compatible types, keys and constraints, completeness, duplicates, ordering, transformations, inserts, updates, deletes, sequence values, checkpoints, and restart behaviour.
Row counts are useful but not enough. Add business checks such as balances, totals by legal entity or status, temporal and referential integrity, report and KPI parity, and samples of high-value, boundary, null, duplicate, and historical records. Assign an owner and disposition to every material mismatch.
6. Has the full workload passed testing?
Test the platform people will actually operate, not only the transfer tool.
| Test layer | What it must prove |
|---|---|
| Migration mechanics | Initial load, CDC, restart, transformation, delete handling, recovery, and validation |
| Functional and integration | Pipelines, applications, APIs, BI, semantic models, schedules, external parties, and end-to-end flows |
| User and regression | Critical user journeys and historical comparison with accepted source outputs |
| Performance and capacity | Daily and peak traffic, batch overlap, concurrency, throughput, source load, and target utilisation |
| Security | Identity, least privilege, network restrictions, encryption, secrets, audit, masking, and denied-access paths |
| Reliability and operations | Backup, restore, disaster recovery, monitoring, alerting, replay, runbooks, and support handover |
| Cutover and rollback | The timed production sequence, checkpoints, decision thresholds, recovery validation, and communications |
Use production-like data variation and representative contention. A functionally correct workload that misses its operating window is not ready.
7. Can we cut over and recover safely?
Choose the cutover method from the approved business tolerance:
- Offline: simplest consistency model, but the longest write outage.
- CDC or flash-cut: reduces downtime, but adds replication lag, final-drain, and source-load controls.
- Active-active: supports gradual traffic movement only when every write conflict can be resolved deterministically.
- Wave-based: reduces one-big-cutover risk when components have clear ownership and dependency boundaries.
Do not promise zero downtime. Use a measured disruption window and a timed runbook with prerequisites, owners, success criteria, evidence links, go/no-go checkpoints, communications, and the latest safe rollback decision.
A rollback plan must explain the data. If the target accepts writes, decide beforehand how those changes will be preserved, reconciled, replayed, or abandoned if traffic returns to the source. Rehearse the recovery and validation, not only the routing change.
8. Can the team operate the target?
Before production transfer, confirm monitoring and alerts, runbooks, access, backup and restore, incident paths, on-call ownership, training, capacity and cost review, enhancement responsibility, and hypercare exit criteria.
Do not decommission the source as soon as traffic moves. Wait for stable regression, reconciliation, health, performance, security, backup, and business-acceptance evidence.
Readiness gate
| Gate | Evidence | Stop sign |
|---|---|---|
| Purpose | Outcome, baseline, target, sponsor, data owner | No measurable reason or accountable owner |
| Estate | Assets, volumes, classifications, service levels, owners | Unknown data or orphan workloads |
| Dependencies | Owner-validated upstream and downstream map | Discovery is tool-only |
| Architecture | Approved design for data, capacity, security, recovery, and cost | Compatibility or residency assumptions remain open |
| Correctness | Technical validation and business reconciliation | Only row counts or unexplained mismatches |
| Testing | Functional, performance, security, recovery, and rollback evidence | Happy paths and average load only |
| Cutover | Rehearsed runbook, decision thresholds, and data-aware rollback | Both systems writable without conflict rules |
| Operations | Monitoring, runbooks, support ownership, and training | The project team leaves immediately after go-live |
How to measure migration benefit
Compare the target with the source baseline. Useful measures include data freshness, pipeline and report cycle time, availability, tested RPO and RTO, query response and throughput, reconciliation and incident rates, manual interventions, operator effort, cost per workload, and time to onboard a new source or deliver a governed change.
Rows copied, jobs converted, and services provisioned show delivery progress. They do not prove the business outcome.