MKsql server / services / upgrade support
This is for version changes that have already stopped being routine.
Usually that means the current version is old enough to be uncomfortable, the change window matters, compatibility uncertainty is growing, and nobody wants to discover the rollback story halfway through the upgrade. The point of the work is not to “modernize.” The point is to make the rollout safer, calmer, and more explicit before production has to pay for a vague plan.
Related
Use the SQL Server update guide when the first question is still servicing context, the SQL Server upgrade guide for broader upgrade logic, the SQL Server migration guide when the work is really drifting into side-by-side move territory, and the failed upgrade problem page when confidence has already been damaged.
Good fit
What you get
What the problem usually looks like
Most upgrade problems are not caused by setup media. They show up earlier, in the planning gap between “we need to change version” and “we know exactly how this estate behaves, what depends on it, how we will validate it, and when we stop and roll back.”
That is why the service sits between pure patching advice and full migration work. Sometimes the answer is a cleaner in-place path. Sometimes the better answer is to stop pretending this is just an upgrade and treat it as side-by-side or migration-adjacent work instead. The useful review is the one that names that boundary before the live window forces the issue.
The practical goal is simple: remove vague assumptions before the change becomes expensive, and leave the team with a rollout path they can actually explain.
What we review
Useful upgrade review looks at the estate around the version change. That means current servicing context, application and driver compatibility, job and integration behavior, maintenance and backup expectations after the change, and whether the business has agreed what good validation actually looks like.
Rehearsal and rollback matter just as much. If the team can describe the target version but not the fallback, the plan is still weak. If the validation stops at “the instance came up,” the business risk has simply been deferred to the first real workload spike after cutover.
Typical review areas
Deliverables
Teams usually need three things from this work: a clearer readiness call, a more believable rollback path, and a firmer answer on the shape of the project. If the review cannot tell whether the work is patching, upgrade, or migration, the change will keep drifting and the plan will keep lying about its own size.
The useful result is a plan that says what must be checked before the window, what must be proven during rehearsal, what must be validated after cutover, and what should trigger rollback instead of debate.
| Output | What it should answer | Why it matters |
|---|---|---|
| Readiness review | What is actually ready, what is missing, and what still needs proof before the window. | This prevents the upgrade from being driven by calendar pressure alone. |
| Rollback logic | What triggers rollback, how it works, and whether it is still believable under time pressure. | Without this, the team often discovers the real risk halfway through execution. |
| Scope boundary | Whether the work is still an upgrade or already a broader migration/change project. | This keeps the chosen method aligned with the real size of the problem. |
When this is not the right first step
When outside review makes sense
Outside review usually makes sense when the change matters enough that the team wants a second set of eyes on compatibility risk, rollout order, and rollback realism before the window opens. It also helps when the upgrade has already gone wrong once, or when several teams own different parts of the estate and nobody is holding the full change picture cleanly.
If the real need is version-change control rather than generic database advice, that is the point of this service. If the work has already grown into a broader platform move, then it may be better to treat it honestly as migration work instead.
Next step
If the version change matters enough that the team wants clearer readiness, calmer rollout, and believable rollback, use contact and describe the current version, the target, the main risk, and whether a prior attempt already went badly.
If you want the technical framing first, read the SQL Server update guide, the SQL Server upgrade guide, and the SQL Server migration guide.
If the wider estate still feels under-controlled before the version change even starts, the better first page may be SQL Server health audit.