The upgrade window is getting close
The date is being discussed or scheduled, but the plan still needs a senior SQL Server review before the window.
Consulting / SQL Server upgrade
SQL Server upgradeconsultant
I review SQL Server upgrade plans before the production window, especially when compatibility, test run, rollback, validation, or dependencies still need a second technical read.
Use this when the target version is known, but the route to get there still needs checking before production sees it.
Fit
When SQL Server upgrade consulting fits
Rollback is not clear enough
The plan names a fallback path, but the timing, trigger, owner, and data movement still need checking.
Validation is too thin
The server may come back online, but jobs, reports, application paths, integrations, and handback still need sharper checks.
The project changed shape
What started as a version change now includes migration, topology, vendor, infrastructure, or dependency questions.
Technical questions
The upgrade questions I would check first
- What SQL Server version and build are you on now?
- What version, edition, and compatibility level are planned?
- Which applications, drivers, jobs, linked servers, reports, or vendors depend on it?
- Has the upgrade been testd on a realistic copy?
- What is the rollback path if validation fails?
Business questions
The decisions behind the upgrade
- Why is the upgrade happening now?
- Is the maintenance window already scheduled?
- What downtime is acceptable?
- Who can authorize go, hold, or rollback?
- Which workflows must pass before handback?
Review scope
What I check in a SQL Server upgrade review
Version
Version and support path
Current build, target version, edition, support status, patch level, direct upgrade path, and side-by-side options.
BuildTargetSupport
Compatibility
Compatibility and dependencies
Compatibility level, deprecated behavior, drivers, vendor constraints, linked servers, jobs, reports, and application paths.
AppsDriversVendors
Test run
Test run quality
Test-run scope, data realism, timing notes, manual fixes, skipped checks, and gaps between test run and production.
TimingCopyNotes
Rollback
Rollback planning
Rollback trigger, owner, method, timing, backup or restore path, data divergence, and communication path.
TriggerOwnerMethod
Validation
Validation and handback
Post-change checks, SQL Agent jobs, application workflows, reports, integrations, owner availability, and handback criteria.
JobsAppsHandback
HA / DR
HA, DR, and jobs
Availability Groups, failover clusters, log shipping, backup chain, SQL Agent jobs, alerts, and recovery context around the change.
HADRAgent
Output
What usually comes out of the review
What to check before the window
The compatibility, dependency, backup, job, and validation checks that should happen before production is touched.
What needs a test run
Upgrade steps, rollback, application validation, SQL Agent behavior, HA or DR behavior, and handback timing.
What needs an owner
Go or hold decisions, rollback trigger, application validation, vendor checks, communication, and post-change follow-up.
What can wait
Cleanup, nice-to-have documentation, and noncritical tuning that should not distract from the production change.
Choosing the right start
Upgrade consulting or another service
| Situation | Better start | Reason |
|---|---|---|
| Compatibility, rollback, test run, or validation are the main concern | Upgrade consulting | The plan needs review around the production window, not just installer steps. |
| The job is already a narrow upgrade-support scope | Upgrade support | Start there when the version path, test run, rollback, and validation review are already clearly scoped. |
| The first issue is current SQL Server health | Health audit | Start with backups, jobs, alerts, configuration, and current maintenance before planning the change. |
| The main issue is restore or DR planning | Recovery readiness | Start with backup chain, restore sequence, RPO/RTO, and failover behavior. |
| The upgrade caused performance symptoms | Performance review | Start with waits, blocking, plans, Query Store, workload timing, and recent change history. |
First step
How the work starts
Start with the upgrade situation. I will tell you whether this should be upgrade consulting, upgrade support, or another SQL Server service.
First message
Current version, target, urgency, window status.
After fit check
Build, target, test run, rollback, validation.
Output
Findings, recommendations, next steps.
Step
1. Send the upgrade situation
+
Step
1. Send the upgrade situation
The first message only needs current version, target version, urgency, and whether a production window is already planned.
Step
2. I decide whether upgrade consulting fits
+
Step
2. I decide whether upgrade consulting fits
If the work is better handled as upgrade support, health audit, recovery readiness, or monthly DBA support, I will say that plainly.
Step
3. We agree what to check
+
Step
3. We agree what to check
Current build, target version, compatibility level, test run notes, rollback plan, validation list, app or vendor constraints, HA/DR context, SQL Agent jobs, and access details come after the fit check.
Step
4. I review the SQL Server details
+
Step
4. I review the SQL Server details
The review stays tied to upgrade risk: compatibility, dependencies, test run, rollback, validation, jobs, HA or DR, and handback.
Step
5. You get usable findings
+
Step
5. You get usable findings
You get findings, recommended next steps, what I would check before the window, and what can wait.
Not the right fit
When this is not the right fit
- You only need a routine CU or GDR installed.
- You need 24/7 monitoring or permanent staffing.
- The main problem is active performance pain.
- The current environment is too unclear for upgrade planning.
- Nobody can arrange access or provide SQL Server details after first contact.
Better fit
When this review is useful
- A version change is planned or being debated.
- Compatibility, rollback, test run, validation, or downtime still need review.
- The project may have grown into a migration or broader platform change.
- The company wants a senior SQL Server read before approving the production window.
Related pages
Related SQL Server pages
Upgrade support
Upgrade support
For version changes where compatibility, test run, rollback, and validation need a second technical check.
See upgrade support
Main service
SQL Server consulting
The main page for performance, recovery, upgrades, current setup reviews, and ongoing DBA help.
See consulting
Upgrade guide
SQL Server upgrade guide
For support posture, compatibility, test run, rollback, validation, and post-change checks.
Read upgrade guide
Version tracker
SQL Server updates tracker
For current SQL Server build tables, CUs, GDRs, support dates, and version history.
Check SQL updates
Recovery
Recovery readiness
For backup chains, restore testing, RPO/RTO, recovery notes, and failover behavior.
See recovery review
Performance
Performance review
For slow periods, blocking, waits, deadlocks, query plans, tempdb pressure, and workload timing.
See performance review
Contact
Need a SQL Server upgrade plan reviewed?
Send a short note with the current version, target version, timing, and the part of the plan that still feels weak. I will tell you whether upgrade consulting is the right start.
A short description is enough for the first message.
FAQ
What does a SQL Server upgrade consultant check?
+
I check current build, target version, compatibility level, dependencies, test run notes, rollback plan, validation steps, jobs, HA or DR context, and handback.
Is this the same as upgrade support?
+
Upgrade support is the narrower service when the scope is already clear. Upgrade consulting is better when the plan, scope, timing, or next step still needs a broader technical read.
Can this be done remotely?
+
Yes. Most SQL Server upgrade review work can be done remotely when someone can arrange access, screen-share, or provide the right SQL Server details after the first fit check.
Can you help decide whether to upgrade or delay?
+
Yes. If compatibility, rollback, test run, validation, or owner gaps are too weak, the recommendation may be to delay, narrow the scope, or do more preparation first.
What should I send first?
+
Send the current version, target version, urgency, whether a window is planned, and the part of the plan that still feels weak.
Can this lead to monthly DBA support?
+
Yes. If the upgrade review shows the SQL Server needs regular checks or planned-change help, monthly DBA support may be the better fit.