SQL Server Upgrade: In-Place or New Server?

I have a client right now debating how to handle SQL Server upgrades across all of their dev and test environments.

And it’s a good conversation, because the same logic people use for dev and test is often what sneaks into production later.

There are two paths. Both can work. Both can fail, but in very different ways.

Option 1: In-Place Upgrade

An in-place upgrade modifies the existing SQL Server instance where it sits.

Why some people choose it

• It’s “fast”.

• No application changes.

• No database backup / restore

• No DNS, aliases, or firewall conversations.

• Lower short-term cost.

For dev and test, that simplicity is tempting.

The risk profile

Once SQL Server upgrades its system databases, you don’t roll back with a checkbox.

If something goes wrong late in the process, your options narrow quickly:

• restore system databases

• restore user databases

• or rebuild and recover

Downtime tends to be “whatever it takes,” not “whatever you planned.”

The safety net you must have

An in-place upgrade should never rely on SQL backups alone.

You need two rollback paths:

Platform-level rollback

• VM snapshot or full image backup taken immediately before the upgrade

• Snapshot verified

• Snapshot removed after validation (don’t leave them lingering)

SQL-level rollback

• Full backups of all user databases

• Backups of master, msdb, and model

• Certificates and encryption keys if applicable

Add a captured baseline and a written stop/go decision, or you’re flying blind.

When in-place makes sense

• Dev and test systems

• Simple, single-instance servers

• Environments where rebuild is acceptable

• Tight timelines with known risk tolerance

Option 2: New Server + Migration

• This means building a new server and moving data and workloads over.

Why teams choose this

• Rollback is simple: point applications back.

• You can test without pressure.

• You can fix long-standing issues instead of inheriting them.

• OS, SQL, and configuration changes are cleaner.

This approach favors control over speed.

The tradeoffs

• You take on more coordination:

• logins and permissions

• SQL Agent jobs

• linked servers and credentials

• application connection routing

• Missed “things” or rarely used features.

And data movement takes time - there’s no way around physics, but there are ways to mitigate this for short cutover windows.

Failures tend to be quieter and easier to reverse.

How to decide

If speed and simplicity matter most, in-place is attractive.
If rollback certainty and testing matter more, migration wins.

That’s why dev and test often lean towards in-place. Production should pause before copying that decision.

The first 24 hours matter

No matter which path you take:

• watch agent jobs

• watch error logs

• confirm backups are running

• validate real business workflows

• compare performance to your baseline

Most upgrade failures don’t happen during setup.
They happen after users return.

The Bottom Line

If you don’t have a tested rollback plan, you don’t have an upgrade strategy.

Dev and test decisions shape production thinking, whether you intend them to or not.

Choose based on risk, not convenience.

SQL Tidbit:

For new server migrations, log shipping is a great way to move databases, especially if you are moving Terabytes of data.

Don’t let SQL Server make you miss your kid’s piano recital!
First month free for new clients

Pocket DBA®

Link Party:

Upgrade SQL Server to the latest version – Advice from the mothership 

OpenAI in talks for new funding round at $750B valuation | LinkedIn – and the bubble continues to grow.

Please share this with anyone that is about to “in-place” a production server!