The capacity analysis you must do before July 2026 — not after
The deadline is real. SQL Server 2016 end of support arrived in July 2026. Every organization still running SQL Server 2016 in production is now operating on extended security updates or carrying unpatched security risk.
The migration is happening. The question isn't whether to move, it's how.
And buried in that question is an opportunity that will not come back for another five to seven years.
The rarest moment in SQL Server management
Database infrastructure decisions are made infrequently. Once a SQL Server environment is deployed and working the underlying capacity decisions how many cores, how much RAM, which hardware platform tend to stay fixed for years.
Migration is the exception. It's the moment when every architectural decision gets reconsidered. When the team asks: what do we actually need in the target environment?
In most organizations, that question gets answered one of two ways.
The first is lift-and-shift. Take the current configuration and reproduce it on new hardware or a new platform. Fast, safe, predictable. And it perpetuates every overprovisioning decision that was made at original deployment now locked in for another five to seven years.
The second is right-sizing before migration. Analyze actual workload demand against the current environment, model the minimum target configuration that meets that demand with appropriate headroom, and deploy to that specification.
The second approach requires more work upfront. It typically delivers 30–50 % lower five-year cost than lift-and-shift. And the window to do it is now, before the target environment is specified and budgeted.
What right-sizing a migration target requires
The common mistake in migration right-sizing is using recent average utilization as the sizing basis. A server averaging 28% CPU sounds like it needs much less capacity than its current core count. But three weeks of monitoring data may not capture the quarterly-end reporting peak, the annual renewal processing spike, or the irregular batch jobs that run under specific business conditions.
Correct migration right-sizing requires a sufficient observation window, ideally 60 – 90 days, capturing multiple business cycles. Peak demand analysis that identifies the highest sustained workload the environment will encounter under normal operating conditions. Parallelism-aware modeling that accounts for how SQL Server's query execution engine uses cores under peak load. Hardware platform comparison using validated benchmarks, so the target platform's actual performance characteristics inform the sizing.
SQL Governor automates this entire process. The output is a specific, justified recommendation: here is the target core count, here is the RAM requirement, here is the storage specification, and here is the workload evidence that supports each number.
The continuity question
There's a concern I hear regularly. Right-sizing before migration sounds riskier than just replicating the current environment. What if the analysis is wrong?
It's a fair question. Here's the answer.
The risk in lift-and-shift is silent and ongoing. You carry unnecessary cost indefinitely, with no mechanism for detecting it. The risk in right-sizing is manageable and auditable. The recommendation is based on documented workload data, and if the analysis is wrong, the mistake is visible and correctable.
More practically, in over 200 migration right-sizing engagements, zero have resulted in performance degradation on the target environment. The methodology accounts for uncertainty. It doesn't recommend running at 95% capacity. It recommends running at 60–70% with documented headroom for growth.
Act now
The SQL Server 2016 migration window is open. Organizations migrating in the next six months are in the window where right-sizing before migration is still straightforward, the source environment is active, the workload data is current, and the target environment is not yet specified.
Organizations that have already migrated without right-sizing analysis can still benefit but the exercise becomes a standalone capacity optimization project rather than a migration efficiency gain.
If you're still in the window the analysis takes 30 days of observation time. The ROI is typically measurable in the first year. And the decision, once locked into your target environment, stays with you for the next platform lifecycle.
Make it a good one.
Timo Lindström
CEO, SQL Governor