SQL Server Migration

It’s Not Just Backup / Restore

Author

Kevin Hill
October 10, 2025

At some point every company faces it: the SQL Server that’s been quietly running for years is due for retirement. Maybe the hardware is old, the lease is ending, or your CIO wants to move workloads to the cloud.

From the outside, a SQL Server “migration” can sound like a simple lift-and-shift. Just copy the databases over, right? The reality is closer to moving offices. You don’t just grab every box and throw it into a new building. You measure the space, update the wiring, decide what gets upgraded, and make sure everyone can find their desk again on Monday.

The Big Picture

Predict & Provision

The new environment needs to handle both today’s workload and tomorrow’s growth. Simply matching your old CPU, RAM, and storage can be a mistake if your business has grown since the last server was purchased. In the cloud, it’s even more important to right-size. Too small and you’ll choke performance, too large and you’ll bleed money. Planning capacity up front avoids both. For cloud VMs, provision low during testing and bump up the size as needed.

Install & Configure

SQL Server isn’t plug-and-play. A fresh installation with updated patches and best-practice settings sets the stage for stability. This is where you decide things like where to place (and separate) data and log files, how many tempdb files to allocate, and which default settings to avoid. A solid foundation here can prevent countless problems later.

Tune the Source Before the Move

One of the biggest mistakes in any migration is bringing old baggage (technical debt) into a new system. Giant log files, bloated indexes, and unnecessary jobs can cause just as much trouble on shiny new hardware as they did before. Tuning the source first is similar to decluttering your house before moving - you start fresh without dragging the junk along. Or cleaning the bathroom before your housekeeper shows up 😉

Move the Data

Databases aren’t the only things that need to come across. Logins, SQL Agent jobs, linked server definitions, and security settings are just as important. If you miss these, users may not be able to connect, backups may not run, or nightly jobs could fail. Successful migrations treat this as a holistic move, not just a database restore. There are multiple approaches to this, depending on your data size and cutover window.

Test, Test, Test

Once the new server is up, applications need to prove they can connect and perform. Something as small as a changed network name or a forgotten firewall rule can cause chaos. Testing gives you a safe window to discover what doesn’t carry over cleanly. It’s also a chance to capture new performance baselines so you can measure improvement.

Final Cutover

The actual “move day” should be planned, short, and closely monitored. Typically this means scheduling downtime, running one last backup and restore, and redirecting applications or DNS. The next 48 hours are critical: you’re confirming not only that the server is online, but that backups succeed, jobs run, and performance holds steady. With good prep, the cutover feels more like flipping a switch than rolling the dice.

For large databases in the TB+ range, a full backup/restore during the week with only a Differential needed on cutover day can reduce the amount of time dramatically.

Why Preparation Matters

Here’s the piece many companies miss: migrations are an opportunity to fix what wasn’t working. If you had jobs that failed silently, indexes that were never used, or security shortcuts, they’ll follow you into the new system unless you address them first. Treating the migration as a reset, or a chance to leave bad habits behind, means the business not only gets a new server, but a more reliable platform for the future.

The Bottom Line

A SQL Server migration is less about moving bits and more about moving confidence. With the right planning, you don’t just get a new server - you get a healthier, more reliable foundation for your business applications.

Free Disaster Readiness Quiz

I’ll trade you an email address for an honest assessment

SQL tidBITs:

Testing isn’t just about making sure the app can connect. It’s also where you discover the surprises, like a database using Service Broker, CLR (C#) objects, or other uncommon SQL Server features that no one mentioned in the planning meetings. Better to find those before the cutover than after users start calling.

Brent Ozar’s First Responder Kit: https://www.brentozar.com/first-aid/

Glenn Berry’s Diagnostic Queries: https://glennsqlperformance.com/resources/

Microsoft Docs – SQL Server Migration Guide: https://learn.microsoft.com/en-us/sql/sql-server/migrate/

Please share with your friend that wants to Lift and Shift 23TB of data and call it good.

Reply

or to participate.