Services / SQL Server upgrade support
SQL Server upgrade support from the first technical check through the production change and post-upgrade validation.
I help companies plan and carry out cumulative updates and major-version upgrades. You work directly with the consultant responsible for the SQL Server work.
Direct contact
You work with the consultant planning and carrying out the SQL Server change.
Flexible scope
Book a planning review, preparation work, production support, or the complete engagement.
Documented handover
You receive the checked plan, runbook, decisions, and post-upgrade checks.
I can check the upgrade plan, prepare and test the change, support the production work, and validate SQL Server afterwards. The engagement can cover one stage or the full upgrade.
For companies that need an experienced DBA to check the plan before approving the change.
I check the supported version path, application dependencies, test coverage, outage estimate, rollback plan, HA or DR, and validation responsibilities.
You receive the missing work and a written recommendation on whether the planned method and window are ready.
For upgrades where the plan exists but the technical preparation or rehearsal still needs work.
I help prepare the databases and instance, check server-level objects, improve the runbook, test the sequence, and measure restore or rollback timing.
You receive a runbook with owners, timings, stop conditions, and validation steps.
For companies that want senior SQL Server help during the production window.
I can carry out or support the agreed SQL Server work, monitor the change, manage the technical checkpoints, and validate the instance afterwards.
The exact implementation responsibilities, access, approvals, and post-change support are agreed before the window.
Bring in SQL Server expertise when the change reaches beyond running setup and restarting services.
The sequence, validation, and rollback decision need to fit inside a fixed outage window.
Drivers, jobs, logins, linked servers, reporting, or external systems also need to work after the change.
Always On, clustering, log shipping, replication, backups, and failover procedures add work before and after setup.
You need to compare patching, an in-place upgrade, a side-by-side move, or a larger migration before committing.
The scope follows the actual upgrade path. These are the areas that usually decide whether the change can finish inside the planned window.
I confirm the source and target builds, edition, operating system, supported path, setup media, disk space, service-account access, and pending restarts.
I check assessment output, deprecated features, behavior changes, drivers, vendor support, connection strings, and application test coverage.
I check database integrity, restore timing, TDE certificates, replication, SQL Agent jobs, logins, linked servers, endpoints, and server settings.
I check replicas, listeners, clustering, log shipping, backup handling, fallback access, approval ownership, and the deadline for stopping or rolling back.
I record timings, manual steps, failed steps, outage estimates, communication points, access boundaries, and the order of the production work.
I define SQL Server and application checks, error-log review, job re-enable order, Query Store comparison, compatibility-level timing, and first-business-cycle monitoring.
The plan, runbook, responsibilities, and recommendation are written down before production work begins.
01
The plan records the chosen method, prerequisites, dependencies, outage estimate, access, owners, and technical sequence.
02
You can see which compatibility tests, database checks, restore timings, rollback steps, or approvals still need attention.
03
The runbook sets the order, timings, communication points, stop conditions, rollback decision, and validation responsibilities.
04
I explain whether to proceed, delay, reduce the scope, or use another method, and what led to that recommendation.
The contact page collects the initial request. I use those details to confirm the technical scope and prepare the quote.
Scope and price depend on the version gap, instance count, application dependencies, HA or DR, test status, timing, and the implementation work you want me to handle.
Step 01
Add a short description of the planned upgrade, timing, and the help you need. The upgrade-support topic stays attached to the request.
Step 02
I read the request and ask for the version details, instance count, dependencies, or existing plan needed to scope the work. A short call is optional when it would help.
Step 03
The quote sets out the work, responsibilities, deliverables, price, and any access or scheduling requirements.
Step 04
Once approved, we schedule the planning, preparation, production support, and validation included in the quote.
I am Mihaly Kertesz, an independent database engineer with more than 20 years working with enterprise databases and infrastructure. I plan the work, join the technical discussions, and handle the SQL Server responsibilities agreed in scope.
You keep one technical contact from the first plan review through preparation, production, and validation.
I provide the service remotely through shared documentation, controlled access, and screen sharing. Access and implementation responsibilities are agreed before work starts.
Checklist
A practical checklist for version changes, test runs, rollback, validation, and post-change checks.
Open checklist
Guide
How to plan the upgrade path, compatibility level, dependencies, rollback, and validation.
Open guide
Guide
How to check builds, choose a CU or GDR path, prepare the window, and validate SQL Server after patching.
Open guide
Choose a health audit when backups, jobs, monitoring, configuration and access also need review.
See health audit
Choose performance review when blocking, deadlocks, slow queries or plan changes are the main problem.
See performance review
Choose recovery readiness when restore testing, backup-chain checks, failover behavior or runbooks are the main concern.
See recovery readiness
Choose monthly DBA support when SQL Server needs regular help with backups, jobs, monitoring, patching and planned changes.
See monthly DBA support
You can book planning only or include preparation, production implementation, and post-upgrade validation. I confirm the exact responsibilities and deliverables before work starts.
Yes. I can carry out or support the agreed SQL Server work during the production window. Access, approvals, application responsibilities, and rollback authority must be clear beforehand.
Yes. I compare both methods. The recommendation depends on version support, available downtime, rollback options and application dependencies.
Send the current and target versions, instance count, main applications, planned window and any plan or test-run notes you already have.
I work through shared plans, controlled access, and screen sharing. We agree access, responsibilities, communication, and the production-window setup before the work starts.
Scope depends on instance count, version gap, application dependencies, HA or DR, test status, timing and the amount of implementation support required.
I check the basic details, ask for anything needed to understand the change, and propose a scope covering planning, preparation, production support, or a combination of them.
Send the current version, target version, instance count, planned window and main concern. I will reply with the details still needed, whether upgrade support fits and the next step.
