A zero-downtime data-warehouse migration runs the old and new platforms in parallel, keeps the new one continuously synchronised, and moves users and downstream systems across in controlled steps with a tested way back. “Zero downtime” is a design goal, not a guarantee: it costs dual running, adds complexity, and in practice still needs short, planned freeze windows.
We at DWHPro lead migrations from Teradata to cloud platforms, building on more than twenty years of Teradata work. When a programme sponsor asks for zero downtime, our first job is to find out what they actually need: no interruption to reporting, no interruption to data loads, or simply no surprise. Those are three different architectures with three different price tags.
The building blocks
Every architecture that keeps the business running during a migration has the same five elements. How much you invest in each is the real design decision.
- Initial load. A bulk copy of history into the target, reconciled and then frozen.
- Continuous synchronisation. A way to keep the target current while the old warehouse stays in production: repeated batch loads, change data capture, or running the rebuilt load pipelines against the same sources in parallel. The right choice is usually made table by table, according to how stale each dataset may be during cutover.
- Parallel run and comparison. Both platforms produce the same outputs for the same period, and differences are explained before anyone switches. Our article on proving a migration before cutover covers validation levels and acceptance criteria.
- A switching layer. Something between consumers and the warehouse that lets you redirect them without rebuilding every report: a semantic layer, connection definitions managed centrally, or a gateway.
- A rollback path. The old platform stays current enough to take back production until formal sign-off.
Three architectures, three trade-offs
| Pattern | How it works | Strength | Cost and risk |
|---|---|---|---|
| Phased cutover by subject area | Move one business domain at a time; each has its own short switch | Limits the blast radius; teams learn as they go | Cross-domain reports need data from both platforms for a while |
| Parallel pipelines | Rebuilt loads feed the new platform from the same sources as the old | Target is independent of the old warehouse; clean architecture | Two full sets of loads to operate and pay for; differences in logic surface late |
| Replication from the old warehouse | Old warehouse stays the master; its tables are copied across continuously | Fastest to set up; outputs match by construction | Carries old design forward; the new pipelines still have to be built later |
In our experience the first pattern, combined with the second for the critical domains, gives the best balance for most enterprises. Pure replication is useful as a bridge, but it postpones rather than removes the hard work.
The switching layer is where downtime is won or lost
Data can be synchronised perfectly and users can still face an outage, because hundreds of reports, extracts and applications point directly at Teradata. If each one must be edited and retested at cutover, the cutover becomes a weekend of firefighting.
Insist on an inventory of every consumer early in the programme, and on a plan for how each one is redirected. Where a BI tool has a central semantic model, switch the model, not the reports. Where applications connect directly, centralise connection definitions before cutover, not during it.
Gateways are a further option. Snowflake offers AIM for Virtualization of Teradata, a gateway that translates Teradata SQL to Snowflake in real time so existing applications can run against Snowflake without rewrites. According to Snowflake’s documentation it is generally available but offered only to select customers. A gateway can remove the need to touch every consumer at once, but it is another production component to size, operate and validate, and you still need a plan for eventually retiring the translation.
Why “zero” needs an asterisk
We are direct with sponsors about the trade-offs:
- Dual running costs money. Two platforms, two sets of loads and often two support teams for the whole parallel period. The longer you aim for seamlessness, the higher the bill; see Teradata migration cost.
- Freeze windows still exist. At the moment of switch, someone must stop changes to models, load logic and reference data long enough to confirm both sides agree. That window can be short and outside business hours. It is rarely zero.
- Complexity creates its own failure modes. Synchronisation can fall behind, replays can create duplicates, and schema changes on the source can break the stream. Every component you add to avoid downtime needs monitoring and an owner.
- Change freezes on the business side. New requirements during the parallel period must be built twice or postponed. Agree which before the programme starts.
What to insist on
- A definition of “downtime” signed off by the business: which reports, which loads, for how long.
- A cutover runbook rehearsed at least once end to end, including the rollback.
- Go/no-go criteria based on reconciliation results, not on the calendar.
- A fixed end date for the parallel run, so dual-running cost does not drift.
In our Swiss retail Teradata to Snowflake migration, the requirement was to keep the business results used for inventory, sales and supply-chain reporting intact while the warehouse moved. Automated reconciliation compared row counts, aggregates and business-logic checks, and discrepancies were investigated before cutover. Production workloads moved to Snowflake with no data loss reported across the migrated datasets. More on our case studies page.
How DWHPro helps
We define what “no downtime” means for your business, choose the pattern that fits your risk and budget, and lead the parallel run and cutover. For an independent view of your options before you commit, start with our data platform assessment.
Common questions
Is a truly zero-downtime migration possible?
For many consumers, yes: they never notice the switch. Across a whole enterprise warehouse, expect at least one short, planned freeze at cutover. Plan for it rather than promising it away.
How long should the parallel run last?
Long enough to cover the business cycles that matter, such as a month-end close, and no longer. Set the end date and the exit criteria before the run starts.
Does a SQL translation gateway replace the migration?
No. It can reduce how many consumers must change at cutover, but data movement, validation and the eventual modernisation of load logic still have to happen.
Planning a Teradata-to-Snowflake migration?
Review the assessment, conversion, reconciliation and cutover work needed for a controlled transition.