The situation. Eleven production databases — about 700 GB in total — were still running on SQL Server 2008. The version was past end of support, the hardware underneath it was aging, and every month the databases stayed there added risk: no security patches, no vendor support if something broke at 2 a.m., and a growing gap between what the business ran on and what anything new expected to talk to.
The ask was simple to say and easy to get wrong: move all eleven to SQL Server 2017 on new hardware, with as little downtime as possible, and don't lose anything on the way. And do it without over-buying — the workload didn't need Enterprise Edition, so we stayed on Standard Edition and kept the licensing bill to what the requirement actually called for.
What was at risk
A migration like this fails in the seams, not the middle. Restoring 700 GB of databases is the easy part. The parts that break a cutover are the ones nobody inventories first — logins that don't come across, jobs that silently stop firing, linked servers pointing at the old box, and a downtime window that quietly stretches from "an evening" to "why is the office still down at noon."
Diagnosis before the cutover
Before moving anything, I built the picture: what was actually running, what depended on what, and where the risk really lived. That meant a full inventory — databases, sizes, compatibility levels, logins and permissions, SQL Agent jobs, and every dependency that would need to follow the data to the new server.
Then the part most rushed migrations skip: I set up log shipping from the old environment to the new one and rehearsed the cutover before doing it for real. Log shipping is fully supported on Standard Edition, so there was no need to reach for a pricier edition to get a clean, low-downtime move. The goal was a migration where the production switch was the boring part, because everything risky had already been tested against copies.
What I did
- Stood up the new SQL Server 2017 Standard environment on new hardware and configured backups from day one.
- Seeded and synchronized all 11 databases with log shipping between old and new, and wrote out failover and failback instructions — a tested path back if the cutover went wrong, which is the difference between a migration and a gamble.
- Ran the production cutover inside the agreed maintenance window, moving all 11 databases together with logins, jobs, and dependencies intact.
- Tuned queries after the move — a new version means a new cardinality estimator and new plans, so post-migration is exactly when performance surprises show up. I caught them before users did.
The outcome
All eleven databases came across to SQL Server 2017 Standard on supported hardware, with downtime held inside the agreed maintenance window and a documented rollback path that never had to be used. Staying on Standard Edition kept the licensing cost aligned with what the workload actually needed. The deliverable wasn't just a migrated server — it was a written runbook, a rehearsed rollback, and an environment the team could support without me.
A migration you can roll back is a migration you can sleep through. The rehearsal is the product.
More case studies: Retiring SQL Server 2012 — 84 databases, one quiet cutover · Tuning a struggling SQL Server on AWS RDS. For the full method, see the SQL Server Migration & Upgrade Playbook.
Running something on an end-of-life SQL Server version? See how the migration model works, review more client results, or get in touch.