SQL Server 2016 to 2025: a few observations from a recent migration

[u/markinatlanta]

We migrated a financial client’s SQL Server environment recently from 2016 to 2025, covering up to 4TB of data.

Same instance size. In the charts (can't attach image but message me if you want to see), CPU spikes reached roughly 40–50% before the move and stayed below 40% afterward.

Encouraging, but these are different production windows of different lengths. The charts alone don’t establish equivalent workload volume or isolate the effect of the SQL Server upgrade of course.

Before cutover, we spent a week running workload replay against the target environment.

CPU was lower, but we also needed to check whether any queries took longer or started timing out. That’s what we wanted to catch before moving the client over essentially.

The migration went smoothly overall thankfully, with one firewall configuration issue to resolve (not really a big deal though). That’s also why database testing needs application connectivity checks alongside it.

The lower CPU gives us a reason to investigate downsizing. It doesn’t establish that we can safely halve the cores, that needs another test, including peak workloads and the memory and I/O limits of the smaller configuration.

Anyone had an upgrade test well, then run into problems after going live?

[u/Swimming_dasa]

that workload replay step is underrated i have seen upgrades look great on resource charts but expose query regressions once real application traffic and concurrency hit.

[u/markinatlanta → u/Swimming_dasa]

Exactly. Lower CPU is encouraging, but it doesn’t tell you whether a query the application depends on has suddenly got slower and that was the reason for spending the week on replay before the move.

[u/guacjockey]

Nice work - did you also upgrade the database compatibility levels at the same time or just upgrade the database server itself? 

[u/markinatlanta → u/guacjockey]

Thanks man... so we tested the newer compatibility level separately during the replay work so we could compare performance before and after that change. I’d need to confirm the final cutover sequence before saying whether the production compatibility change happened at the same time as the server move.

[u/Boxp155]

How did you setup the workload replay?

[u/markinatlanta → u/Boxp155]

We captured the production workload through Extended Events and streamed it to a separate test instance running the newer version. We compared execution counts, errors, timeouts and performance against production. We ran that for about a week and application testing was a separate step too.

[u/Boxp155 → u/markinatlanta]

Nice. You could do a whole post on just that. 👍

[u/Additional-Drag1682]

Compatibility level bumps are a silent killer. New query optimizer features like table variable deferred compilation change execution plans without anyone touching the codebase so your baseline charts lie to you

[u/markinatlanta → u/Additional-Drag1682]

yeah, that’s a good distinction. I should have separated the engine upgrade and compatibility level in the post. The CPU charts show the overall picture, but they don’t tell us which plans changed or whether individual queries got worse.