Snowflake ↔ Databricks migrations, benchmarked before cutover.
We run migrations in both directions. Before anyone commits to a date, we benchmark your real workloads on the target platform and build a cost model from your own query history. Then we run both systems in parallel until the numbers agree.
How we work
- Both directions: Snowflake → Databricks and Databricks → Snowflake
- Parallel run until row-level reconciliation passes
- Rollback path documented at every phase
- Cost model from your query history, not a vendor calculator
Why migrations go wrong
Almost never because of the data movement. The failures we get called in to fix cluster in four places.
The cost model was a guess
Someone compared list prices instead of running the actual workloads. The new platform is cheaper per credit and more expensive per month, and nobody finds out until the second invoice.
SQL was translated by hand
Thousands of lines of dialect differences — date handling, window semantics, JSON access, implicit casts — converted without a test harness. The queries run. The numbers are subtly wrong.
There was no parallel run
A cutover weekend with no way back. Discrepancies surface on Monday, in a board report, instead of in a reconciliation job the week before.
Governance was an afterthought
Roles, row-level policies, and masking rebuilt from memory rather than exported and mapped. Access ends up broader than it was, and nobody notices until an audit.
Four phases, each with a defined deliverable
You know what you receive at the end of each phase before we start. Phase one is useful on its own: if it says do not migrate, you have saved the rest.
- 1
Assess
2–3 weeksWe inventory what actually runs: queries, jobs, dependencies, and who consumes what. Then we benchmark a representative slice of your workloads on the target platform and build a cost model from your real query history.
Deliverables- Workload inventory with dependency graph
- Benchmark results on the target platform
- Cost model with sensitivity analysis
- Risk register and a go / no-go recommendation
- 2
Parallel run
4–8 weeksWe stand up the target platform, translate the SQL with an automated harness plus review, and run both systems on the same inputs. A reconciliation job compares outputs row by row and reports every discrepancy until the list is empty and understood.
Deliverables- Target platform provisioned as code
- Translated models under automated test
- Row-level reconciliation reports
- Governance mapping: roles, policies, masking
- 3
Cutover
1 weekendConsumers are repointed in a planned sequence, not all at once. The source platform stays warm and the rollback path stays open until you decide otherwise. Downtime is limited to the switch itself, which is why we call it zero-downtime rather than instantaneous.
Deliverables- Sequenced cutover runbook
- Rollback procedure, tested beforehand
- Consumer migration checklist
- Post-cutover verification suite
- 4
Optimize
2–4 weeksThe first version of a migrated workload is rarely the cheapest. We tune clustering, file layout, warehouse or cluster sizing, and caching against real usage, then hand over the runbooks and the reasoning.
Deliverables- Tuned configuration with before / after numbers
- Cost monitoring and alerting
- Runbooks and architecture documentation
- Handover sessions with your team
Technical FAQ
The questions that come up in every assessment call. Short answers here; longer ones on the call.
Will there be downtime?
Read paths stay available throughout. The only interruption is the switch of each consumer, which is sequenced and typically measured in minutes per system rather than hours for the whole estate. We keep the source platform running and the rollback path open until you explicitly retire it.
How do you handle SQL dialect translation?
Automated translation first, then review, then a test harness that runs the original and translated query against the same data and compares results. The differences that matter are rarely syntax — they are semantics: date and timestamp handling, window function frames, NULL ordering, implicit casts, JSON path behavior, and floating point aggregation order. Anything the harness cannot prove equivalent gets reviewed by a person.
How do you model cost, and how often is the estimate wrong?
We build the model from your query history: actual compute time, concurrency patterns, and data volumes, replayed on the target. We give a range rather than a single number, and we state the assumptions the range depends on. Where a workload does not translate cleanly into a cost comparison, we say so instead of interpolating.
What happens to our governance model?
It gets exported, mapped, and diffed — not rebuilt from memory. Roles, grants, row access policies, and column masking are translated to the target's equivalents, and we produce a diff showing where the target model is broader or narrower than the source. Broader is a finding, not a footnote.
Can we migrate incrementally instead of all at once?
Usually yes, and often it is the right call. We migrate by domain or by consumer group, keeping a federated read across both platforms during the transition. It takes longer in calendar time and reduces risk per step. The assessment phase tells you which shape fits your dependency graph.
Which direction do you recommend?
Neither, until we have benchmarked. Both platforms have gotten good at the other's original strength, so the honest answer depends on your workload mix, your team's skills, and what you already pay for. If the assessment says your current platform is the right one, that is what the report will say.
What do you need from our team?
Read access to query history and metadata for the assessment, a technical counterpart who knows why things are the way they are, and someone who can approve the cutover sequence. During the parallel run we need a review path for reconciliation findings, since some discrepancies turn out to be bugs in the source that were never noticed.
Migrations we run
Both directions, with the same process and the same reconciliation discipline.
Snowflake to Databricks migration
Typically driven by consolidating ETL and ML on one platform, Delta Lake and open table formats, or Spark workloads that are awkward to run as warehouse compute. We translate Snowflake SQL to Databricks SQL and Spark, map warehouses to clusters or SQL warehouses, and rebuild governance in Unity Catalog.
Databricks to Snowflake migration
Typically driven by a mostly-SQL analytics workload, a team that is stronger in SQL than in Spark, or concurrency patterns that fit a warehouse model better. We translate Spark SQL and PySpark transformations to dbt on Snowflake, map cluster sizing to warehouse sizing, and rebuild governance with Snowflake roles and policies.
Start with the assessment
The assessment is scoped and priced on its own, and it ends in a recommendation — including the recommendation not to migrate. That is the cheapest possible outcome if it is the right one.
Book a migration assessment