Most warehouse migrations don’t fail technically. They fail politically. The new platform stands up, the pipelines copy over, the dashboards mostly render — and then a finance VP notices a number that’s $40K off the legacy report and the program loses six months of credibility in an afternoon. The cautious version of this project assumes that outcome and engineers around it from week one. Below is the playbook we use when moving mid-market analytics off Teradata or Oracle onto Snowflake, BigQuery, or Databricks. It is slower than the vendor reference architecture. It is also the one that survives executive scrutiny.

1. Discovery before design

Before a single object is provisioned in the target platform, you need a defensible inventory. Vendors will tell you their assessment tooling can handle this in two weeks. It cannot, because the question isn’t “what objects exist” — query history will give you that. The question is “what does the business actually depend on,” and that requires reconciling three sources that never agree:

  • System catalog and query logs — every table, view, stored procedure, and the last 90–180 days of access patterns. Sort by query count, by user count, and by downstream dependency. The long tail is real; assume 30–40% of catalogued objects are dead and another 20% are used only by their author.
  • BI and reporting layer — every Power BI dataset, Tableau workbook, Looker model, and direct ODBC consumer. Map each one back to the warehouse objects it touches. This is where you discover the “shadow critical” tables: rarely queried, but feeding the CFO’s monthly board pack.
  • Human inventory — interviews with the analysts and engineers who own each domain. Twenty 30-minute conversations will surface things no log captures: the quarterly close job that runs from a laptop, the Excel macro that hits the warehouse over a linked server, the regulator-facing report whose definition exists only in one person’s head.

The output is a tiered list. Tier 1 is revenue-critical or regulator-facing. Tier 2 is widely used internal reporting. Tier 3 is exploratory and ad-hoc. Tier 4 is dead. You will migrate tiers 1–3 with very different levels of rigor, and you will not migrate tier 4 at all. Be willing to defend the deletion list in writing.

2. Schema and semantics, not just SQL

Translation tools have improved markedly — SnowConvert, BigQuery’s translation service, and Databricks’ Lakehouse Federation will handle most syntactic conversion. The hard work is semantic: legacy warehouses encode decades of business logic in places translators can’t see. Implicit type coercion in Oracle behaves differently than Snowflake’s explicit casting. Teradata’s QUALIFY clauses and multi-statement requests need careful re-expression. Stored procedures that mutate session state don’t port at all and have to be re-architected as pipelines.

Treat schema migration as the moment to pay down old debt, but ration the appetite. Renaming columns, fixing types, and consolidating duplicate dimensions are all reasonable inside a migration. Restructuring star schemas into a fundamentally different model is not — that’s a separate project, and conflating it with the platform move is how programs slip by twelve months.

3. The dual-run period is the entire deliverable

Everything before dual-run is preparation. Everything after is cleanup. The dual-run itself — the period when both warehouses are loading the same source data, both are serving queries, and you are systematically reconciling outputs — is where trust is built or destroyed.

Three rules govern dual-run:

  • Reconcile by output, not by query. Comparing two SQL statements is theater. Comparing the row counts, sums, and distinct keys of the resulting tables is real. Build a reconciliation harness that runs nightly, computes a small set of checksums (row count, primary-key hash, sum of every numeric column, min/max of every date) on tier-1 tables in both systems, and writes the diffs to a dashboard. Investigate anything non-zero immediately.
  • Reconcile the consumer layer too. A correct table feeding an incorrect dashboard is still a failed migration in the eyes of the audience. Run the top 25 BI assets against both warehouses and diff the rendered outputs. Most discrepancies will be timezone handling, NULL semantics, or rounding — all of which are surfaceable and fixable, none of which surface if you only diff the warehouse layer.
  • Set a minimum dual-run duration in advance. For tier-1 reporting, we recommend a full quarter — long enough to cover monthly close, quarterly close, and any seasonal pattern in the data. Shorter durations leave you exposed to the “the new platform is wrong about Q4” conversation you cannot have.

During dual-run, the new platform is read-only for end users on tier-1 workloads. They look at it, they trust-but-verify against the legacy, they raise discrepancies. You do not turn off the legacy.

4. Decommission criteria, written down before you start

The cleanest way to avoid an indefinite dual-run — which is the most common failure mode — is to write the decommission criteria into the program charter before kickoff. We recommend five, all of which must be true before any tier-1 object on the legacy platform is read-disabled:

  1. Reconciliation is clean for two consecutive close cycles. Zero variance on tier-1 checksums across one quarterly close and one monthly close.
  2. Top-25 BI parity is signed off. Each asset owner has reviewed the new-platform version against the legacy and signed an artifact acknowledging the move.
  3. Operational runbooks are migrated. Every alert, every on-call playbook, every incident-response procedure references the new platform and has been exercised at least once.
  4. Cost steady-state is understood. You have at least one full month of post-cutover billing data and the run-rate is within the band you committed to leadership. Surprise bills are how migrations get paused.
  5. Rollback path is documented and tested. You can re-point consumers back to the legacy within a defined window if a tier-1 issue surfaces in the first 30 days. This is the criterion most programs skip; it is also the one that lets you decommission with confidence rather than hope.

When all five are met for a workload, you read-disable the legacy copy, watch for two weeks, then begin the formal decommission. License termination, hardware return, and contract wind-down follow on a deliberate timeline — typically 90 days behind the cutover, never simultaneous with it.

The cautious playbook is not the fastest path to a press release. It is the path on which the CFO still trusts the numbers eighteen months later, which is the only metric of a migration that matters.