The situation. Eighty-four databases were still running on SQL Server 2012 in the client's datacenter. The version was past end of support — no security patches, no vendor backing — and every month on it added risk to a platform a large organization depended on. The job was to get all 84 onto SQL Server 2019, on a new server, with as little downtime as the business could schedule, and without losing anything on the way.
Two constraints shaped the whole plan from the start. First, the count: 84 databases isn't one migration, it's the same migration done 84 times, which makes discipline and repeatability matter more than cleverness. Second, cost: the workload didn't need Enterprise Edition, and Enterprise licensing is a large, recurring bill at this scale. We stayed on Standard Edition — the right edition for the requirement, not the most expensive one that would technically work.
What was at risk
An 84-database migration fails in two ways. It fails slowly — a marathon restore window that stretches from an overnight change into a business-hours outage. Or it fails in the details — one database out of 84 that doesn't come across clean, a log chain broken, a cutover step done from memory at 2 a.m. and done wrong. With that many moving parts, and a large organization watching the clock, "we'll figure it out live" isn't a plan; it's a coin flip repeated 84 times.
The approach: sync ahead, cut over fast
The edition choice quietly settled the architecture. Full Always On Availability Groups are an Enterprise Edition feature (Standard offers only single-database Basic AGs — and an AG can't bridge 2012 to 2019 anyway); on Standard Edition, database mirroring is the supported synchronous path — and it happens to be an excellent tool for a minimal-downtime, cross-version migration. The plan was to seed the new 2019 server ahead of time and keep it continuously synchronized, so the actual cutover was a quick, controlled failover rather than a long restore.
What I did
- Stood up the new SQL Server 2019 Standard instance on a fresh VM (VM01) in the client's datacenter, configured and ready to receive the databases.
- For each database: took a full backup on the 2012 source and restored it to VM01 with NORECOVERY, then took a log backup and restored the log with NORECOVERY — leaving each target database in a restoring state, seeded and waiting.
- Established database mirroring from the 2012 principal to the 2019 mirror, so every subsequent change streamed to VM01 and the new server stayed continuously in sync with production — across all 84 databases.
- Ran the cutover as a failover inside the agreed window, promoting VM01 to primary. Because the databases were already synchronized, the entire cutover — all 84 databases plus validation — came in at about 2 hours 25 minutes, rather than the day-long outage a restore-from-scratch would have meant.
- Validated the new 2019 environment after cutover and confirmed all 84 databases were online, current, and healthy.
Lessons learned — the dry runs were the reason it went smoothly
The migration went smoothly, and that wasn't luck. Before touching production, I rehearsed the whole thing — practiced the migration end to end and wrote every step down into a runbook: the backup and restore sequence, the mirroring setup, the failover, and the validation checks, in order. Rehearsing surfaced the rough edges while they were still cheap to fix, and a written, repeatable procedure is exactly what you want when the same steps have to be executed correctly across 84 databases and one narrow window.
It also respected a one-way door in the design: once you fail over to 2019, the databases upgrade to the new version and there's no failing back to 2012. That's precisely why you rehearse — so the irreversible step is the boring, well-practiced one, not the improvised one.
The migration looked smooth because the drama had already happened — in the dry runs, where it belongs. Eighty-four databases moved in under two and a half hours because every step had been walked before, on paper and in practice.
The outcome
All 84 databases moved from end-of-life SQL Server 2012 to a supported SQL Server 2019 Standard instance on new hardware in the client's datacenter, with the full cutover held to about 2 hours 25 minutes and no data lost. The business kept its licensing cost down by staying on the edition it actually needed, and came out on supported software with a documented, rehearsed procedure behind the move.
More case studies: Migrating 11 databases off end-of-life SQL Server 2008 · 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.