There's a version of cloud migration that lives in vendor slides: you pick everything up, put it down in Azure, and by Monday you're modern. Then there's the version you actually live through, which is less of a lift and more of a long, careful negotiation with a system that has opinions about where it lives. I've been in the middle of moving an on-premises SQL Server data warehouse to Azure, and these are the field notes — the things I'd have wanted to know before I started.

"Lift and shift" is a starting move, not a strategy

The first temptation is to take the on-prem warehouse exactly as it is and drop it, unchanged, onto infrastructure in Azure. And you can — put SQL Server on an Azure VM and it'll run much as it did in the server room. There's even a real argument for doing this first, as a de-risking step: get it running in the new place before you start changing how it works.

But if that's where you stop, you've mostly just moved your electricity bill to someone else's data centre and made it recurring. The on-prem warehouse was shaped by on-prem assumptions — fixed hardware you'd already paid for, so nobody minded a wasteful overnight batch; storage and compute welded together because on a physical box they are together. Move that design unchanged to a place where you pay by the hour for compute and separately for storage, and every one of those inherited assumptions becomes a line on an invoice.

So my working rule has become: lift-and-shift to get there safely, then re-architect to actually benefit. Treat the move as a chance to reconsider, not just relocate. (I feel strongly enough about this that it deserves its own post — but for now, field notes.)

Where the effort actually goes

The surprise, doing this for real, is which parts are hard. It's rarely the headline "move the database" step. It's everything around it.

  • Connectivity and identity. How does the migrated warehouse talk to the sources that didn't move? How do the people and processes that need it authenticate now? A meaningful slice of the project is networking and access, not data — and it's the part the demos skip entirely.
  • The SSIS packages come along too. All that ETL has to keep running. Some of it lifts cleanly; some of it makes on-prem assumptions (file paths, local resources) that quietly break the moment the ground moves. Every package needs checking, and the ones that "should just work" are exactly the ones that surprise you.
  • Data movement itself is a project. Getting the existing data up there — the initial bulk load over a network, validating it arrived intact, keeping old and new in sync during the cut-over window — is real work with real edge cases. "Copy the database" is a sentence; doing it safely for something large is a plan.
  • Cost behaviour changes shape. On-prem, the cost was sunk the day you bought the hardware. In Azure it's continuous, and it responds to how you build. An inefficient query that was "free" on owned hardware now has a running meter attached. You start caring about efficiency in a way you didn't have to before — which is healthy, but it's a mindset you have to actually adopt.

The cut-over is the scary part — so rehearse it

The moment that keeps you up isn't the building, it's the switch: the point where the new system becomes the real one and the old one is retired. Get it wrong and you're either down, or — worse — running two systems that quietly disagree.

What's saved me is treating the cut-over as something to rehearse, not perform live for the first time. Run the migration into the new environment while the old one is still the source of truth. Compare them. Reconcile the row counts and the totals until they match, and understand every discrepancy rather than waving it away. Only when the new system has been proven to agree with the old one do you actually switch. The cut-over should be boring by the time you do it for real, because you've already done it three times in rehearsal.

What we moved first, and what we left till last

A word on sequencing, because the order you migrate in turns out to matter almost as much as the how. The instinct is to start with the important, complicated thing to "get it out of the way." That's backwards.

Move the low-risk, low-dependency pieces first — the isolated stuff whose failure wouldn't hurt much. It lets you learn the migration mechanics, the connectivity quirks, the reconciliation process, on something forgiving. By the time you reach the critical, tangled core, you've already made your beginner mistakes on things that didn't matter, and you're running a rehearsed process rather than improvising on the one system nobody can afford to have wobble.

And leave the genuinely entangled legacy piece — the one with a dozen undocumented dependencies — until you understand it properly. Migrating something you don't fully understand isn't a migration, it's a gamble with extra steps. Map it first; move it last.

What I'm taking from it

Two things, mainly.

First, the technology is rarely the hard part. The connectivity, the identity, the reconciliation, the sequencing — the organisational plumbing around the migration — is where the real work and the real risk live. The database engine mostly behaves.

Second, and I keep relearning this: a migration is only worth the disruption if it changes what's possible, not just where things run. Moving the warehouse to Azure and keeping every on-prem assumption intact is a lot of risk for a bigger invoice. The point is to come out the other side able to do things you couldn't do before.

Lift-and-shift gets you across the water safely. It's what you build after you land that decides whether the trip was worth it.

More on that "after you land" part soon — it's where the actual argument is.