When not to migrate off your on-prem SQL Server

I get paid to migrate companies off SQL Server. One of my published case studies is exactly that: SQL Server 2012 to Snowflake for a German company. So when I tell you that some of you should stay put, I’m arguing against my own invoice.

The pressure to migrate rarely starts with the data. It starts with a conference talk, a new hire who wants a modern stack on their CV, or a cloud vendor’s TCO calculator that quietly assumes your workload is spiky. Before any of that, ask one question: what specifically hurts? If the answer is vague, the migration is a want, not a need. Here are the four situations where I’d tell you to keep the box.

Your workload is steady

Usage-based pricing wins when compute sits idle most of the day. It loses when it doesn’t.

Rough math. A medium Snowflake warehouse burns about 4 credits an hour. At roughly €3 per credit, running it around the clock costs €8,000 to €9,000 a month, before storage, before the serverless extras. A 16-core SQL Server Standard license you already own costs you the Software Assurance renewal and the hardware you already have. If your ETL and reporting load keeps the box busy at 50 to 70 percent all day, every day, per-second billing is the most expensive way to buy compute.

The cloud warehouse pitch is built on elasticity. No elasticity in your workload, no benefit from the pricing model. Plenty of mid-sized companies have exactly this profile: nightly loads, business-hours reporting, no seasonal spikes worth naming.

Your data is small and growing slowly

The company in my migration case study had 50TB growing 20 percent a year and a hard cap of 50 concurrent users. Moving made sense.

If you have 2TB growing 5 percent a year, you are not that company. A current SQL Server version with clustered columnstore indexes handles analytical queries on a few terabytes without drama. I’ve seen columnstore turn a 40-minute aggregation into 90 seconds on the same hardware. People who decided the engine was slow in 2014 often never tried what it can do now.

The real problem is your model, not your engine

This is the most common one. The complaint is “the warehouse is slow,” and then I look and find a 900-table schema with no layering, business logic buried in nested views five levels deep, and three departments computing revenue three different ways.

Move that to Snowflake and you get the same mess with a bigger bill. The migration even adds a fresh layer of confusion, because now half the logic lives in the old stored procedures and half in the new stack.

dbt runs against SQL Server. You can build a tested, layered, documented transformation layer on the database you already have. If the model is the problem, fix the model first. Worst case, you’ve made the eventual migration cheaper, because clean models port and tangled stored procedures don’t.

The database is welded to your ERP

In a lot of German manufacturers, the SQL Server isn’t a data warehouse that happens to sit near the ERP. It is the integration layer. Stored procedures feed the shop floor system, CDC jobs sync Navision or SAP tables, and some operational process nobody fully remembers writes back into the same database every night at 2 a.m.

The cost of migrating that system is not in moving the data. It’s in the archaeology. Every one of those couplings has to be found, understood, and rebuilt, and the riskiest ones are the undocumented ones that only fail at month-end close. If nothing else is forcing a move, this is the project to defer until you can fund the untangling properly, not just the data transfer.

When you actually should move

The honest counterweight. You should migrate when reports run overnight and the business needs them hourly. When you’ve hit a concurrency wall and analysts queue behind each other. When compliance asks for lineage and audit trails on personal data and the platform can’t answer. When you’re on 2012 or 2014, support is gone, and staying current would mean repurchasing licenses anyway. That last one resets the cost math entirely, because then both paths cost real money and the comparison is fair for the first time.

Two or more of those, and migration is worth pricing seriously. None of them, and the cheapest, fastest, least risky project is the one you don’t run.

What I’d do differently

For years my assessment template started from “how to migrate” and worked backwards. I’ve since added an explicit stay-put scenario to every platform review, with its own cost line, so the do-nothing option competes on equal footing instead of being the unstated default everyone is embarrassed to pick. I’d have added it sooner. The reviews where staying won were the ones clients trusted most, and two of them came back later with the projects that did need doing.