Migration wave planning splits a large data warehouse into groups of workloads that can be moved, validated and switched off together, ordered by business value, dependencies and risk. A good wave plan lets you retire parts of the legacy platform early, learn from the first wave before the hard ones, and avoid a single big-bang cutover that nobody can roll back.
We at DWHPro have spent more than twenty years with large Teradata environments and now lead their migrations to cloud platforms. In large programmes, the wave plan is the document that decides whether the migration delivers steadily or stalls in a long parallel phase. This article explains how to build one, what to insist on and where plans usually fail.
Why waves, not a big bang
A large warehouse is rarely one system. It is hundreds of data feeds, thousands of tables and reports, and many teams who depend on them. Moving everything at once means one enormous reconciliation exercise, one risky weekend and no way to learn before it counts. Waves reduce that risk:
- Each wave has a manageable scope that business owners can actually test and sign off.
- Early waves expose problems in tooling, data models and processes while the stakes are low.
- Completed waves can be switched off on the legacy side, so dual-running cost goes down over time instead of staying flat.
The trade-off is that waves need interfaces between old and new platforms while both are live. Planning those interfaces is part of the wave plan, not an afterthought.
Step 1: Know what you have
Waves are only as good as the inventory behind them. Before planning, establish which sources feed the warehouse, which pipelines build which tables, which reports, extracts and applications consume them, and how heavily each part is used. Query logs from the legacy platform are the most reliable source here, because documentation is usually out of date.
The inventory also tells you what not to migrate. In most mature warehouses a share of tables, jobs and reports is no longer used. Retiring them before the migration reduces every later wave.
Step 2: Group workloads into units that can move together
The unit of a wave is not a table. It is a group of sources, pipelines, data and consumers that can be moved and validated as one piece, typically aligned with a business domain such as sales, finance or supply chain. The test is simple: once this group has moved, can its owners sign off their results and can the legacy side stop running it?
Shared core data, such as customer, product or calendar, needs special handling. It is used by almost every domain, so it usually moves early and is then made available to whichever platform still needs it.
Step 3: Order the waves
| Factor | Question | Effect on order |
|---|---|---|
| Dependencies | What does this group need from others? | Shared data and upstream groups go first |
| Business value | Does moving it deliver something visible, such as faster reports or new use cases? | High value earlier helps keep support for the programme |
| Risk and complexity | How much hidden logic, how many consumers, how critical? | Not in the first wave; schedule once the method is proven |
| Business calendar | Are there closing periods, peak seasons or audits? | Avoid cutovers in those windows |
| Team capacity | Who must test and sign off? | Do not load the same business owners in consecutive waves |
We usually recommend a first wave that is real but contained: a domain with production users and a committed owner, but not the most critical finance or regulatory reporting. It proves the method end to end, including reconciliation and switch-off, and gives you realistic effort figures for the rest. Our article on migration cost explains how to extrapolate from such a pilot.
Step 4: Define what “done” means per wave
Every wave needs the same exit criteria, agreed upfront: results reconciled at the agreed level, consumers moved, a full business cycle run on the new platform, operations handed over, and legacy components switched off. The last point matters most. A wave that is “migrated” but still running on the old platform has not reduced cost or risk. Validation levels and acceptance criteria are covered in how to prove a migration before cutover.
In our Swiss retail case study, a Teradata to Snowflake migration, the work covered workload analysis, target data models, rebuilding critical ETL pipelines, automated reconciliation and knowledge transfer. Discrepancies were investigated before cutover, and production workloads moved to Snowflake. See our case studies.
Where wave plans go wrong
- Waves by technical layer. Moving “all staging tables” first sounds logical but produces nothing the business can sign off.
- No switch-off. Waves complete on paper while the legacy system keeps running everything.
- Hidden consumers. An extract to a partner or a spreadsheet connected to a table is found only after cutover.
- Fixed dates without slack. Each wave reveals surprises. Plans need buffer between waves, not just inside them.
- Tooling assumptions. Code conversion and virtualisation tools can shorten waves. Snowflake, for example, now offers automated translation of legacy ETL to dbt and the option to run Teradata workloads on Snowflake without rewriting them first. Treat such options as something to prove in the first wave, not as a planning assumption for all of them.
How DWHPro helps
We build and run wave plans for large warehouse migrations: inventory and usage analysis, grouping and ordering of workloads, exit criteria and reconciliation, and steering the programme through switch-off. For Snowflake targets, see our Teradata to Snowflake migration service. If the target platform or the case for migrating is still open, start with an independent data platform assessment or read whether to optimise or migrate.
Common questions
How many waves does a large migration need?
There is no standard number. It follows from the number of business domains, their dependencies and how many owners can test at the same time. Fewer, larger waves raise risk; very many small waves raise coordination effort.
What should go into the first wave?
A real production domain with a committed owner and moderate complexity, so the full method, including switch-off, is proven before the critical waves.
Can waves run in parallel?
Yes, if they do not depend on each other and do not need the same people for testing and sign-off. Shared core data should be settled before parallel waves start.
Planning a Teradata-to-Snowflake migration?
Review the assessment, conversion, reconciliation and cutover work needed for a controlled transition.