Redshift to Snowflake is the most common warehouse migration we are asked to run, and it fails in predictable ways when it fails. Scope is estimated from a table count rather than from the logic embedded in stored procedures. Business logic that lived in the platform is discovered halfway through. Nobody validates row-level equivalence, so a subtle difference in null handling goes unnoticed until a quarterly report disagrees with last year.
This is how we approach it, including the parts that are unglamorous and the parts where staying put is the right answer.
Why teams move
Cost is the usual trigger, specifically the shape of the cost. Redshift provisioned clusters are sized for peak and charged around the clock, so a warehouse that is busy for four hours at month-end costs the same at 3 AM in the third week. Snowflake separates storage from compute, suspends idle warehouses and bills per second, which suits spiky analytical workloads far better.
Concurrency is the second reason. When finance, operations and a BI tool all query at month-end, provisioned clusters queue. Multi-cluster warehouses absorb that by scaling out and back automatically.
Third is semi-structured data. Native JSON handling without a flattening pipeline removes a whole layer of engineering for teams ingesting API and event data.
And fourth, quietly: workload isolation. Being able to give the data science team their own compute without affecting the finance team's month-end is worth more organisationally than it looks on a feature list.
The semantic differences that break reports
These look trivial and are not. Date and timestamp handling — time zone assumptions, truncation behaviour and what happens to data collected across daylight boundaries. Numeric precision and rounding, which changes a financial total in the third decimal and therefore in the annual figure. Null handling in aggregates and joins. String collation and case sensitivity, which changes join results. Empty string versus null, where different platforms have different histories.
Each produces a small, plausible, wrong number. We handle them by cataloguing the differences relevant to the specific source and target pair before writing any translation, then testing each rule against production-volume real data rather than samples.
This is also where you discover the old system was wrong. On a recent migration a revenue figure differed by 0.3% and investigation showed the legacy query had been double-counting a category of returns since 2019. The migration did not create that; it exposed it. Handling the discovery well — surfacing it, quantifying it, letting the business decide — is part of the job.
| Difference | Symptom | Handling |
|---|---|---|
| Timestamp time zone assumptions | Rows land in the wrong day at boundaries | Explicit TZ conversion rules, tested at boundaries |
| Numeric precision and rounding | Financial totals differ in later decimals | Explicit cast and rounding policy, reconciled |
| Null in aggregate functions | Averages and counts differ subtly | Documented rule per measure |
| Collation and case sensitivity | Joins match different row counts | Normalise keys explicitly during translation |
| Empty string vs null | Filters behave differently | Decide once, apply consistently, document |
Dual running is the whole method
Both systems run in parallel for six to fourteen weeks. Data flows into both. Queries run against both. An automated reconciliation compares outputs continuously — row counts by partition, control totals on financial measures, and full row-level comparison on critical tables.
Results are published to a dashboard the business can watch, so trust is built by evidence rather than assertion. A difference is investigated and either fixed or explicitly accepted with a documented reason. Cutover happens only when reconciliation has been clean for a defined period, typically three consecutive full reporting cycles.
We also shadow queries: production queries replayed against the target with results compared automatically. This catches the long tail of report-specific differences that table-level reconciliation misses, and it is what allows a confident statement that repointing the BI tool will not change any number on any dashboard.
Where the cost saving actually comes from
Across our completed migrations the median platform cost reduction is 41%, and very little of it comes from the pricing model alone. A lift-and-shift without tuning can absolutely cost more.
The saving comes from four things. Suspending idle compute aggressively — auto-suspend at sixty seconds unless there is a measured reason otherwise. Separating warehouses by workload so loading, transformation and BI are sized independently rather than everything running on one oversized cluster. Clustering keys chosen from actual query filter patterns, verified with pruning statistics rather than assumed. And eliminating queries that scan whole tables unnecessarily, which in most estates is a small number of scheduled jobs nobody has reviewed since they were written.
This is why tuning belongs inside the migration rather than as a follow-up phase. A migration that lands and then gets optimised six months later spends six months paying for the untuned version.
In practice
What a realistic timeline looks like
For a mid-sized estate — a few thousand tables, a few hundred pipelines, a hundred or so reports — expect four to seven months end to end, of which six to fourteen weeks is dual running. The build is rarely the long pole; verification and the business's confidence-building are.
A useful early win: inventory usage as well as objects. In a typical estate, thirty to forty per cent of objects have not been queried in a year. Identifying and dropping them is the single largest scope reduction available, and it is free.
Anyone quoting six weeks for a full warehouse migration is either working with a very small estate or planning to skip verification. Both are worth clarifying before signing.
When to stay on Redshift
If your workload is steady rather than spiky, provisioned capacity is genuinely efficient and the pricing advantage narrows considerably. If you are deeply integrated into the AWS ecosystem and value that consolidation, staying has real operational merit — and Redshift Serverless addresses a good part of the idle-cost problem without a migration.
If your team knows Redshift well and the current pain is a handful of badly written queries rather than the platform, fixing those queries is a two-week engagement rather than a five-month one. We have recommended exactly that more than once, and it is usually the better commercial decision.
Key takeaways
- Cost shape, concurrency, semi-structured handling and workload isolation are the four genuine drivers.
- Semantic differences — dates, precision, nulls, collation — are what break reports, and they must be catalogued before translation.
- Dual running with published reconciliation is the only credible way to prove equivalence.
- The 41% median saving comes from tuning, not from the pricing model. Tune during the migration.
- Expect four to seven months for a mid-sized estate; anyone quoting six weeks is skipping verification.
Frequently asked
They should not, and query shadowing is how we prove it — production queries replayed against both systems with results compared automatically. Where a difference appears, it is either a semantic difference we translate explicitly or an error in the legacy system that we surface for the business to decide on. Any accepted change is documented and communicated before cutover.
Usually yes, and it reduces risk considerably. Subject area by subject area, with both platforms serving different domains during transition and a federation layer if a report needs to span both. The main constraint is reports that join across domains — those either wait for both sides to move or use a temporary federated view.
It happens on roughly half our migrations. We surface it with evidence, quantify the impact, and let the business decide whether to correct going forward, restate history, or deliberately accept the legacy behaviour. What we will not do is quietly reproduce a known error to make reconciliation look clean.
For warehouse migrations, effectively none — cutover is repointing BI tools and pipelines once reconciliation is clean, which takes minutes. The legacy platform stays running and current for a defined period afterwards, usually thirty days, so rollback remains a repointing exercise rather than a restore.