Migration Readiness Checklist — Replatform · replatform.in
R Replatform
Migration Readiness Checklist · v1.0 · June 2026

Are you ready to run a cloud or data platform migration?

A 20-item checklist a CTO, VP of Engineering, or platform lead can run through before committing budget and team time to a cloud or data platform migration project. Each item maps directly to one of the six stages of a structured migration pipeline: Inventory, Plan, Convert, Validate, Reconcile, Report.

Six pipeline stages · 6 sections · 20 items · Score rubric included

How to use this checklist. Work through each item against your current infrastructure and team state today — not your aspirational state. Check the box if the item is fully satisfied. Leave it unchecked if it is partially done, unknown, or not yet addressed. Items tagged BLOCKING represent gaps that will surface as unplanned work during execution; addressing them before signing a migration SOW reduces the risk of scope and timeline overrun.

Stage 1 · Inventory Inventory Readiness

A migration cannot be scoped or priced without a complete, verified inventory of everything in scope. Gaps here cause scope creep at exactly the wrong moment — during conversion and parallel run.

You have a full object-count by type across your source platform Blocking
Tables, views, stored procedures, UDFs, scheduled queries, dbt models, and BI artifacts — you know the count and can enumerate them. An INFORMATION_SCHEMA query or equivalent metadata export suffices; the number does not need to be exact, but it must be grounded in a real query or catalogue pull, not a rough estimate from memory.
Downstream consumers are documented by name and owner
You know which dashboards, reverse-ETL jobs, ML pipelines, and customer-facing reports read from the source platform. Each has a named owner who will need to sign off on the parallel-run diff. Undocumented consumers that appear after conversion starts are the single largest source of cutover delay.
You have identified any objects not managed by version control
One-off SQL scripts, manually-created stored procedures, ad-hoc views built directly in the console — these sit outside your dbt or Terraform graph and require manual discovery. The metadata sweep surfaces these; knowing they exist before scoping prevents them from appearing as surprises mid-engagement.
Data volumes and growth rate are documented per major table
For your ten largest tables, you know the current row count, approximate storage size, and the daily or weekly growth rate. This drives the wave batching strategy, the parallel-run window, and the initial load plan — particularly relevant when the source is Teradata or Redshift with large fact tables and complex partition schemes.
Stage 2 · Plan Stakeholder Alignment

Wave planning requires business owners, not just engineering owners. If stakeholders are not aligned before the plan is written, the plan will need to be rewritten mid-execution.

Executive sponsorship is confirmed above the platform team Blocking
The migration has a named sponsor at the VP or C-level who controls the budget and can unblock dependency decisions. Platform-team-only buy-in is insufficient when cutover requires a parallel-run sign-off from a BI team, a finance analytics owner, or an ML pipeline owner who reports to a different VP.
Cutover blackout windows are pre-agreed with business stakeholders
Finance close periods, product launch windows, peak trading seasons — these create hard constraints on when parallel runs can begin and when cutovers can happen. Knowing them before wave planning means the schedule is built around real constraints, not retrofitted after stakeholder review discovers a conflict.
Wave sequencing has input from downstream consumer owners Important
Each wave should be sequenced so that downstream consumers with the lowest blast radius go first. This requires knowing which consumer owners are willing and available to sign off on parallel-run diffs. Waves driven purely by data engineer preference — rather than consumer availability — tend to block on sign-off at the worst time.
Stages 2–3 · Plan & Convert Technical Decisions

Architectural decisions left open past the wave plan become blockers during conversion. Each item below is a choice that must be made — and documented — before the first object is translated.

Target platform account / project structure is decided Blocking
Single-project vs. multi-project (BigQuery), single-account vs. multi-account (Snowflake/Databricks), Unity Catalog adoption scope, workspace topology — these choices determine how translated DDL is laid out and how access controls are structured. Deferring them to "after we see how conversion goes" causes rework.
Partitioning and clustering strategy is mapped source-to-target
DISTKEY/SORTKEY (Redshift), PRIMARY INDEX (Teradata), and CLUSTER BY (BigQuery) do not have one-to-one semantic equivalents on all targets. The migration plan must document the intended mapping per major table — including tables where the source clustering will be intentionally dropped because the target optimizer handles it differently.
Source-specific features without direct target equivalents are inventoried Important
Snowflake time-travel and zero-copy clone on Databricks, JavaScript UDFs on a Python-only target, BTEQ macros in Teradata, semi-structured SUPER columns in Redshift — these require explicit design decisions, not just translation. Each one needs a named owner and a documented approach before conversion begins.
ETL / orchestration migration approach is decided separately from table migration
If the source uses SSIS packages, Informatica PowerCenter sessions, or Glue jobs, the pipeline migration is a separate workstream from the DDL/DML translation — with a different skill set, timeline, and validation surface. Treating it as an afterthought to table migration is one of the most common causes of cutover delay.
Stage 4 · Validate Validation Prep

Validation is deterministic: row counts, schema parity, float-tolerant checksums, and query-result diffs run against every object before the parallel run begins. But it can only run against queries you have agreed on in advance.

A test-query battery is agreed with the platform team before conversion starts Blocking
Deterministic query-result diffs require a pre-agreed set of test queries that both teams treat as acceptance criteria. Without this, "validation" becomes a subjective review rather than a formal gate. The battery should include the top-frequency queries and the top-cost queries from your query history — at minimum 20, ideally 50.
Float-tolerance thresholds are defined for numeric aggregate comparisons
Cross-platform floating-point representation differences produce false checksum failures if tolerances are not set in advance. The tolerance level (e.g., 1e-6 relative error on SUM columns) needs to be agreed with whoever signs off on reconciliation — not chosen unilaterally by the migration team.
Source-platform read-only credentials are available for the validation phase
Validation runs checksums against both source and target simultaneously during the parallel run. If the source platform decommissions or restricts access before validation completes, the comparison evidence cannot be generated. Confirm that read-only access to the source will be maintained through the end of the parallel-run window.
Stages 5–6 · Reconcile & Report Cutover Readiness

Parallel run is where most migration projects stall. The items below represent the structural preconditions that keep the reconciliation window on schedule instead of extending indefinitely while consumer owners remain unavailable.

Per-consumer sign-off owners are named and available during the parallel-run window Blocking
Each downstream consumer — dashboard, ML pipeline, reverse-ETL feed — needs a named individual who will review the daily diff reports and sign off that the target matches the source before that consumer cuts over. "We'll figure that out when we get there" reliably produces a reconciliation window that extends to twice the planned duration.
A documented rollback plan exists for each wave
If the parallel run surfaces a blocking reconciliation failure after cutover has begun, what is the procedure to revert consumer traffic to the source platform? The rollback plan should name the steps, the person who executes them, and the data-freshness window it covers. A written plan that was reviewed once is significantly faster to execute than one improvised under pressure.
The parallel-run window duration is agreed before conversion starts Important
A parallel run without a defined end condition tends to run until someone loses patience and calls cutover without completing sign-offs. Agreeing a target duration — typically 2–4 weeks per wave for mid-market estates — and a set of explicit exit criteria (all consumer owners signed, zero blocking diffs for 5 consecutive days) creates accountability on both sides.
Post-cutover Post-Cutover Readiness

The migration does not close when the last consumer cuts over. Observability gaps, cost regression, and decommissioning delays are the most common post-cutover problems — and all three are preventable with upfront planning.

Target platform monitoring and alerting is scoped before go-live
Query cost anomaly detection, slot/warehouse utilization alerts, failed-job notifications, and SLO tracking need to be in place at cutover, not retrofitted two months later when the first bill arrives. The monitoring scope is simpler to define during wave planning than after the source platform has been decommissioned.
Source platform decommissioning criteria are written and owned
The source platform continues to cost money until it is formally decommissioned. Without written criteria (all consumers off, final backup complete, contract cancelled or downscaled) and a named owner responsible for executing them, parallel billing drags for months after cutover. This is one of the least visible cost drivers in a migration programme.
Target platform cost baseline is established before the first production load
Set the cost baseline — slot commitments, warehouse sizes, storage tier selections — before production traffic hits the target. Retrospective rightsizing against a live estate is significantly harder than sizing correctly at launch. If a FinOps review is planned post-migration, schedule it for 30 days post-cutover, not six months.
Score yourself
Count the unchecked boxes

Each unchecked item is a gap that will surface as unplanned work, scope creep, or timeline extension during an engagement. This is not a pass/fail — it is a triage tool. Use the bands below to decide what to do next.

0 – 5
Ready to scope
Strong pre-conditions are in place. A Discovery Sprint will surface the remaining gaps and produce a reliable wave plan with a fixed execution quote.
6 – 10
Scope first
Multiple structural gaps. Address the items tagged BLOCKING before committing to an execution budget. A scoping conversation can help prioritise which gaps to close first.
11 +
Run a Discovery Sprint
Significant pre-conditions missing. Committing to execution now carries high re-scoping risk. A structured Discovery Sprint will surface the full gap list and produce a realistic wave plan before any budget is committed to execution.
What to do with your score

0–5 unchecked: book a 30-min scoping call at replatform.in/contact. Bring the completed checklist — it cuts the scoping conversation time in half.

6+ unchecked: the Discovery Sprint is the right first step — 10 business days, fixed fee, delivers a full inventory, wave plan, and execution quote with no obligation to proceed.

Have a cost question first? Run the free FinOps Quick-Check — two minutes, no email required, returns an indicative waste range and named levers.

replatform.in/resources/migration-readiness-checklist ↗