The founder-call scene below is illustrative — the conversation shape recurs; the specifics are anonymized.
A founder caught the Replatform founder on a Friday call. He had two slides up. One was a Snowflake bill — $48K/month, trending up. The other was a back-of-the-envelope BigQuery projection from his data lead — $19K/month for the same workload, allegedly. “We’re moving,” he said. “How fast can you get us off Snowflake?”
The answer was probably not at all.
(This is a strange sentence to write on the blog of a company whose entire delivery practice is platform migrations. We sell migrations. We have a rule library, a generic pipeline, a cutover playbook. The economics of our delivery model assume that some percentage of conversations like the one above end with a signed scope. So when the Replatform founder tells a founder not to migrate, he is turning down work he could plausibly close. Worth being honest about that up front.)
The reason for telling him no had nothing to do with Snowflake versus BigQuery on the merits. The two warehouses are close enough on capability that the answer to which one is better depends almost entirely on workload shape and team skill. The reason was that the $19K projection was wrong, and so were the assumptions underneath it.
Here is the rough shape of when Snowflake → BigQuery is the right answer, and the much larger shape of when it isn’t.
The math nobody runs honestly
The $19K projection his data lead gave him was a back-of-envelope: “we process X TB a month, BigQuery on-demand is $6.25 per TiB, multiply, done.” That math is missing about seven things.
First, the projection assumed the same query patterns would run on BigQuery as on Snowflake. They won’t. Snowflake’s caching model and BigQuery’s scan-pricing model reward completely different query habits. A dashboard that costs $0.40 to refresh on a warm Snowflake warehouse can cost $4 on BigQuery on-demand if it scans a wide unpartitioned table, because BigQuery doesn’t cache the result the same way and bills you for the bytes regardless of warm/cold state. (Snowflake’s result cache is genuinely good — it is the feature people most underestimate when they leave.)
Second, the projection assumed clean partitioning and clustering on day one. Migrations don’t work that way. Costs run noticeably above steady-state during the first three months as the team learns the platform’s specific partition + cluster + materialisation discipline. Independent analyses (Flexera State of the Cloud 2024) and prior-role engagement experience consistently show this ramp falls in the 1.5–2x range during the first 90 days post-cutover.
Third, the projection ignored the storage tier. Snowflake’s storage is roughly $23/TB/month. BigQuery’s active storage is $20/TB/month, long-term is $10. On the surface BigQuery wins. But Snowflake’s storage is heavily compressed by default, and BigQuery storage is also compressed but the ratio is different per workload — for some, BigQuery storage costs end up higher than Snowflake’s despite the lower headline rate. Ask anyone who’s done a side-by-side on the same dataset. The compression ratio depends on the data.
Fourth, and biggest: the projection ignored the cost of the migration itself.
The cost of the migration
A real Snowflake → BigQuery migration for a workload at that scale (around 200-300 dbt models, a moderately complex Looker layer, a Fivetran graph with thirty-odd sources, an ML feature store, four data engineers on the team) costs somewhere between $400K and $800K all-in, depending on how clean the source platform is and how much of the rewrite can be mechanised by a rule library versus how much needs a human in the loop. That range is not because we’re trying to extract margin — it’s because Snowflake-specific SQL constructs, stored procedures, Snowpark, dynamic tables, and Snowflake-flavoured window functions have to be either translated, redesigned, or absorbed into BigQuery-shaped equivalents, and the long tail of edge cases is where the engineering hours live.
Plus, six to nine months of calendar time. Plus, six to nine months of running both warehouses in parallel during cutover — call it another $200K-$350K depending on how aggressively you can wind down Snowflake.
Total: somewhere between $600K and $1.15M before you save your first dollar.
The arithmetic before you save your first dollar — and payback assumes the optimistic steady-state delta holds.
If the steady-state saving is the difference between $48K/month on Snowflake and $19K/month on BigQuery — call it $29K/month, optimistically — then the payback is roughly 21 to 40 months. Before you factor in the first-90-day ramp, before you factor in the result-cache loss, before you factor in the engineer hours diverted from product work for a year.
A more honest steady-state delta — once you’ve correctly modelled the patterns from Post 1 in this series, applied them to both platforms, and re-priced — usually shrinks the headline gap by 30-60%. Sometimes the gap inverts. The founder has watched this pattern invert in prior-role engagements.
When migrations are the right answer
This isn’t an argument that migrations are never right. Here are the situations where the math is unambiguous:
The team is already on the wrong workload shape for the current warehouse. Snowflake punishes unpredictable, bursty, single-tenant analytical workloads — its credit model assumes warehouses stay warm. BigQuery on-demand handles those workloads better because you pay for the scan, not the warm warehouse. If your workload is genuinely sporadic and you’re paying for credits you’re not using, the migration math can work even at modest scale.
The team is already on the wrong vendor relationship. Some Snowflake contracts I’ve audited have minimum commits that the team is nowhere near using, locked in for two more years, with discounts that disappear if usage drops. Some BigQuery slot reservations I’ve seen are the same — committed at the wrong size during a panic, now locked. The right migration in these cases is often off the committed platform and onto on-demand pricing, regardless of which vendor is on the other side.
There’s a regulatory or data-residency forcing function. GCP region availability, BAA terms, FedRAMP scope, customer contractual obligations that name a cloud — these collapse the analysis. If you have to be on GCP, you’re moving to BigQuery; the math discussion is about whether to move now or at the next contract renewal.
There’s a strategic platform consolidation. If the rest of the data and ML stack is on GCP — Vertex, Dataflow, Pub/Sub, the whole vertical — having Snowflake sit awkwardly alongside it has a real coordination cost, even if the warehouse-only math looks neutral. The integration savings are hard to model but usually real.
The team is genuinely BigQuery-skilled and Snowflake-grudging. This sounds soft but it’s the single biggest predictor of post-migration success the founder has seen across prior-role engagements. A team that wanted to use BigQuery from day one and got overruled into Snowflake will adapt fast and tune aggressively. A team that loved Snowflake and got overruled into BigQuery will spend a year writing SQL that fights the platform.
Note that “the Snowflake bill is high” is not on this list. A high bill is a symptom. Migrating without diagnosing the cause means you’ll have a high BigQuery bill in eighteen months.
What we told the founder
Three questions on the call.
One: do you know which queries account for 80% of your $48K monthly bill? He didn’t. His data lead had a sense, but no attribution chain. (This is the same gap from Post 1 in this series. It is the gap that hides everything.)
Two: how many of those queries would be cheaper on BigQuery without changing the SQL? He didn’t know. Neither did his data lead. Most teams genuinely cannot answer this because they have not modelled the per-query cost on the target platform.
Three: what’s the next strategic project on your data roadmap, and would it take longer if your four data engineers were doing a migration cutover for the next six months? He thought about that one. The next project was a real-time personalisation feature that the product team had been asking for. It would be on hold during a migration. It would probably ship six months later. The lost revenue from a six-month-delayed personalisation feature was likely more than the entire steady-state Snowflake-vs-BigQuery delta over three years.
He went quiet for a minute. Then he asked if there was something cheaper than a migration that would help him understand whether the $48K was the right number.
That is the entire pitch for an audit instead of a migration. The audit costs $100 if you start with a Cloud Cost X-Ray, credited to execution if you sign — that’s the first decision point before any migration scope gets written. The migration costs $400K-800K. The audit will tell you, with real numbers, whether the migration is worth the $400K-800K. Most of the time it isn’t, not because Snowflake is better than BigQuery, but because the workload running on Snowflake is misconfigured in ways that would also be misconfigured on BigQuery.
The honest version of the “should we move to Snowflake?” or “should we move off Snowflake?” question almost always comes out of a pre-migration discovery before any migration scope gets written, rather than a vendor bake-off.
The pattern beneath
Most of the migration RFPs that land in our inbox start with a CFO who got scared by a bill. The fear is reasonable. The reaction — switch vendors — is almost never the cheapest way to address it. Switching vendors is the most expensive way to address a high bill, because it bundles the bill problem with a one-year engineering disruption, a six-month productivity dip, and a 30-60% chance that the steady-state savings are smaller than the projection assumes.
The cheapest way to address a high bill is to find out what the bill is paying for. That is a six-week diagnostic. Sometimes the diagnostic surfaces a $300K/year saving on the current platform that nobody saw, and the migration discussion goes away for two years. Sometimes the diagnostic confirms the move is right, and we walk into the migration with a phase-zero report that justifies the spend to the board on the first page. Both outcomes are good. The wrong outcome is signing the migration scope before the diagnostic.
I’m aware that this is a strange post for a company that sells migrations to publish. I think we’re going to keep selling more of them, not fewer, by writing it. The teams that sign with us after reading this are teams that have already done the math honestly, and those are the engagements that don’t blow up in month four.
If your honest answer to should we migrate? is we don’t know, and our projection is back-of-envelope, the answer this quarter is no. Maybe yes next quarter, after you’ve found out what the bill is actually paying for.