You need the upgrade done safely
You need help reviewing the plan, preparing the change, performing the upgrade, and checking SQL Server afterwards.
Services / SQL Server upgrade support
SQL Serverupgrade support
I review and perform SQL Server upgrades across CUs, service packs, major versions and HA setups.
Use this when the upgrade needs planning, compatibility checks, a test run, rollback checks, validation or hands-on help during the change.
What to send
Send the version you are on, where you want to go, which SQL Servers are involved, known risks and timing.
What I check
I check the upgrade path, application risk, HA or DR impact, rollback option, test run and post-upgrade checks.
What you get
You get what must be fixed first, what can wait, and whether to proceed, delay or change the upgrade method.
Fit
When you should book SQL Server upgrade support
Book this when the upgrade is more than clicking setup and hoping the application still behaves afterwards.
It fits CU updates, service packs, major version upgrades, HA upgrades and situations where the right upgrade path is still unclear.
The current version is out of support
The SQL Server version is end of life, missing required updates, blocked by vendor support or no longer acceptable for security reasons.
You are not confident performing the upgrade
The upgrade touches applications, drivers, jobs, logins, linked servers, HA, reporting or other parts nobody wants to break in production.
You are not sure which option is best
The right path may be a CU, service pack, major version upgrade, side-by-side move, HA upgrade or a wider migration project.
Review
What I review in SQL Server upgrade support
I check what has to work before, during and after the upgrade: SQL Server itself, applications, jobs, logins, HA or DR, rollback and validation.
Version
Current and target version path
Current build, target build, edition, operating system, supported upgrade route, support status, and whether the target is still the right one.
Apps
Compatibility and application behavior
Database compatibility levels, breaking changes, deprecated features, drivers, vendor support, client libraries, and application test coverage.
Method
Upgrade method choice
Whether the work should be in-place, side-by-side, backup and restore, log shipping-assisted, a phased migration or a narrower patching job.
Data
Database readiness
Database inventory, size, restore timing, DBCC CHECKDB coverage, encryption, replication, compatibility level strategy, and downtime pressure.
Instance
Jobs, logins, linked servers, and settings
SQL Agent jobs, operators, credentials, proxies, logins, permissions, linked servers, configuration values, endpoints, and instance-level objects.
HA
HA and DR behavior
Always On, clustering, log shipping, failover behavior, replicas, listener setup, backup chain handling, and recovery timing.
Fallback
Rollback and fallback path
What rollback really means, who can approve it, how long it takes, which data is at risk, and when the team must stop going forward.
Check
Post-upgrade validation
Application smoke tests, SQL Agent checks, monitoring, performance baseline, error logs, compatibility-level changes, and business sign-off.
Technical checks
SQL Server upgrade readiness checks
The exact list depends on version gap, method and dependencies. These are the usual checks I want answered before the planned window.
Supported path and prerequisites
- Current SQL Server build, target build, edition, operating system, hardware and support status.
- Pending restart, installer blockers, service accounts, disk space, setup media, permissions and planned-window limits.
- Whether the version change should be an upgrade, a patch, a side-by-side move or a broader migration.
Compatibility and application risk
- Upgrade assessment output, deprecated features, breaking changes, trace flags, database compatibility levels and scoped settings.
- Driver versions, vendor support statements, connection strings, linked servers, SSIS, SSRS, SSAS and application test coverage.
- Which behavior changes can be tested before the window and which ones need staged validation.
Database and instance readiness
- Database inventory, size, restore duration, CHECKDB status, TDE certificates, collation concerns and file layout.
- SQL Agent jobs, operators, alerts, logins, users, credentials, proxies, endpoints and server-level permissions.
- Configuration values, tempdb, max memory, MAXDOP, cost threshold and settings that should not change accidentally.
Test run and timing
- Test-run notes, elapsed time, manual steps, automation gaps, outage estimate and restore timing.
- Application validation steps, monitoring checks, job checks and handoff points between teams.
- What must be fixed before the real window and what can safely wait until after.
Rollback and fallback
- Backup chain, restore point, fallback server, DNS or connection changes, data-change risk and decision deadline.
- Who approves rollback, who executes it, who validates the fallback and how long the business can wait.
- Whether the rollback path has actually been tested enough to use if the upgrade has to stop.
Go-live and aftercare
- Cutover order, communication points, monitoring window, error-log checks, Query Store baseline and performance comparison.
- Compatibility-level timing, post-upgrade cleanup, statistics work, job re-enable order and known watch items.
- A short list of checks for the first business cycle after the change.
Output
What you get with SQL Server upgrade support
You get a readiness view tied to evidence, a fix order before the window, and a clearer decision on whether to proceed.
Readiness gaps
What still needs proof before the upgrade: compatibility, dependencies, test run, rollback, validation, approvals or handoff gaps.
Evidence behind the decision
Important findings point back to version support, assessment output, test-run notes, restore timing, dependency checks or validation gaps.
What to fix before the window
Immediate fixes, scheduled prep, follow-up checks and watch items are separated so the team knows what must happen before approval.
Go, delay or change method
The output gives a practical recommendation on whether to proceed, delay, narrow the change or treat it as a migration instead.
Process
How SQL Server upgrade support works
The first message only needs the current version, target version, timing and what you want help with.
Scope depends on instance count, application dependency, HA or DR setup, test-run status and how close the window is.
Step
1. Send the upgrade context
Send the current version, target version, rough timing, instance list, applications involved, known concerns and any plan or checklist already written.
Step
2. I review the plan and evidence
I check the upgrade path, compatibility risk, dependencies, test-run quality, rollback path, validation, HA or DR context and post-change checks.
Step
3. We decide what still needs proof
The discussion separates installer steps from real production risk: applications, jobs, logins, rollback timing, validation and business sign-off.
Step
4. You get the fix order
You get the readiness gaps, evidence, what to fix before the window, and whether the safer move is go, delay, narrow or change method.
Proof and reading
Useful background before you send the upgrade plan
Related
SQL Server upgrade checklist
A practical checklist for version changes, test runs, rollback, validation, and post-change checks.
Open checklist
Related
SQL Server upgrade guide
How to plan the upgrade path, compatibility level, dependencies, rollback, and validation.
Open guide
Related
Upgrade checklist
A practical checklist for version changes, test runs, rollback, and post-change checks.
Open checklist
Fit check
Not the right service when the problem is different
A broad SQL Server environment review
Use the health audit when the upgrade is only one concern among backups, jobs, monitoring, access and general operational risk.
See health audit
A current performance problem
Use performance review when blocking, deadlocks, slow queries or plan changes are already the main issue.
See performance review
A pure restore or DR proof question
Use recovery readiness when the main question is backup chain quality, restore timing, failover behavior or runbooks.
See recovery readiness
A larger platform move
Use the consulting parent page when the work has become cloud migration, redesign, consolidation or a multi-system programme.
See SQL Server consulting
Before you send it
Send the rough plan, not a perfect project pack. Current version, target version, timing and main concern are enough to start.
If you have an assessment report, checklist, test-run notes, restore timing, vendor notes or rollback plan, include them.
The first useful decision is whether this is ready for upgrade support, needs a broader health audit or has already become migration work.
Request SQL Server upgrade support
I will look at the plan and tell you the sane next step. Sometimes that is upgrade support. Sometimes the safer move is delay, narrow the change or re-scope it.
FAQ
What is included in SQL Server upgrade support?
+
The review covers the current and target versions, supported upgrade path, compatibility risk, applications, drivers, jobs, logins, linked servers, HA or DR context, test-run quality, rollback path, validation and post-change checks.
Is this an upgrade implementation service?
+
It can support implementation work, but the first job is upgrade readiness. I check whether the plan is safe enough, what still needs proof, and whether the method should change before the window.
Do you support in-place upgrades and side-by-side moves?
+
Yes. The review can compare in-place upgrade, side-by-side migration, backup and restore, phased cutover or delay when the environment is not ready enough.
What should we send first?
+
Send the current SQL Server version, target version, edition, operating system, instance count, key applications, planned window, known concerns and any existing plan, checklist or test-run notes.
Can this be done remotely?
+
Yes. Remote review is the default when the team can share the plan, version details, assessment output, inventory, screenshots, scripts or read-only access where needed.
How is upgrade support priced?
+
Scope depends on instance count, version gap, application dependency, HA or DR setup, evidence quality, test-run status and how close the planned window is.
What happens after the review?
+
You get readiness gaps, evidence, a fix order and a recommendation to proceed, delay, narrow the change or treat the work as a larger migration.