SQL Server 2016 In-Place Upgrade to SQL Server 2022 or 2025
SQL Server 2016 reached the end of extended support on 14 July 2026 per Microsoft's product lifecycle, so every 2016 instance still running on-premises is unpatched unless you are paying Microsoft for Extended Security Updates. This engagement upgrades those instances where they stand — in place on the existing host, or side by side on the same host when a fast fallback matters more than a short window — to SQL Server 2022 or SQL Server 2025. IT Partner runs the pre-upgrade assessment against Microsoft's supported paths (2016 must be at Service Pack 3; SQL Server 2025 requires Windows Server 2019 or later, so a host still on Windows Server 2016 lands on 2022 unless the operating system moves first), brings the instance to SP3, takes and restore-tests the backups, writes the rollback plan, performs the upgrade and the current cumulative update, checks SQL Agent jobs, linked servers, SSIS packages and SSRS, and hands over a compatibility-level plan built on Query Store so the optimizer change happens on your schedule, not Setup's. $1,450 per server plus a $950 base fee, an estimate confirmed in a written quote, for about 2 weeks per upgrade wave. Built for mid-size and enterprise estates keeping SQL Server on-premises for latency, licensing or regulatory reasons; failover cluster instances, Always On availability groups and estates of ten or more instances are quoted per estate.
What this engagement is
SQL Server 2016 left extended support on 14 July 2026 per Microsoft's product lifecycle. From that date Microsoft ships no security updates for it unless you buy Extended Security Updates — and, under Microsoft's current ESU terms, SQL Server 2016's ESUs are a paid subscription even on an Azure virtual machine, unlike the free treatment 2014 received there. That leaves three honest ways out: pay Microsoft for ESUs while you decide (a metered charge on your Azure subscription through Azure Arc, or a volume-licensing purchase for disconnected servers — available for up to three years, so for SQL Server 2016 through July 2029 per Microsoft's end-of-support overview), move the databases to Azure, or upgrade the engine where it stands. Our five SQL Server migration services cover the second path. This page is the third — for the plants, warehouses, trading floors, clinics and government estates that keep SQL Server on-premises because the application needs sub-millisecond latency to something in the building, because the licences are already owned under Software Assurance, or because a regulator or data-residency rule says the data stays. The first decision is the target version, and it is decided by the host as much as by preference. Both SQL Server 2022 and SQL Server 2025 accept an upgrade from SQL Server 2016 at Service Pack 3 or later — that is Microsoft's supported-upgrade table, and an instance still on SP2 goes to SP3 first. The operating-system floors differ: SQL Server 2022 installs on Windows Server 2016 or later; SQL Server 2025 requires Windows Server 2019 or later, per Microsoft's hardware and software requirements. The most common 2016 estate — SQL Server 2016 on Windows Server 2016 — can therefore go in place to SQL Server 2022 today, while reaching 2025 on that host means upgrading Windows first or installing 2025 side by side on a newer host, and Microsoft itself recommends a new installation rather than an in-place upgrade whenever the operating system is changing too. Windows Server 2016 leaves extended support on 12 January 2027 per Microsoft's product lifecycle, so the operating-system question is close behind; the Windows Server 2016 End of Support Assessment is the place to settle it, and the Windows Server 2016 to 2025 Upgrade Service is the engagement that moves the host. Between the two SQL targets: 2022 is in support until January 2033 per Microsoft's product lifecycle and keeps you on familiar ground; 2025, generally available since November 2025, has the longest runway (extended support to 2036 per Microsoft's end-of-support overview), compatibility level 170, and a higher Standard-edition ceiling (the lesser of 4 sockets or 32 cores, and 256 GB of buffer-pool memory per instance) — but it also discontinues Master Data Services and Data Quality Services, which rules it out for an instance that still depends on either. What 'in place' means, stated plainly: SQL Server Setup replaces the 2016 binaries and upgrades the system databases on the same host, and the previous instance no longer exists afterwards. There is no uninstall-to-go-back, and a database that has been opened by the new engine cannot be attached to or restored on SQL Server 2016 again. Rollback is therefore the restore-tested backup set — and the hypervisor snapshot, where the host is virtual — taken at the write freeze, restored onto the 2016 build. The advantage is that logins, Agent jobs, instance settings, file paths and connection strings all carry over untouched. Where a fast fallback matters more than a short window, we install the target version as a new named instance beside the 2016 instance on the same host, move the databases across by backup and restore, switch the connection strings or a SQL alias, and leave the old instance stopped for the agreed fallback period before removing it. We recommend one or the other per host in the assessment, and the runbook is written for the method you approve. The assessment is where upgrades are won. It runs Microsoft's upgrade-assessment tooling — the Data Migration Assistant, or its successor inside SQL Server Management Studio where Microsoft has moved it — and our own checks for the things Setup will not warn you about: linked servers still defined on the deprecated SQL Server Native Client provider, which move to the Microsoft OLE DB Driver for SQL Server; SSIS packages, which the upgrade moves to the new instance without converting their format, so the SSIS Package Upgrade Wizard is a separate, deliberate step; Reporting Services, which since 2017 is a standalone product that Setup cannot upgrade from SSRS 2016 — we install the current SSRS release and migrate the report server database and encryption key, or, if the reports are heading to Power BI anyway, hand that to the SSRS to Power BI Migration; Analysis Services instances, full-text catalogs, CLR assemblies, CDC and replication, maintenance plans, and the client drivers on the application servers. After the upgrade we work through Microsoft's completion list — new full backups, DBCC CHECKDB WITH DATA_PURITY, DBCC UPDATEUSAGE, updated statistics, repopulated full-text catalogs — and then the discipline that keeps Monday quiet: every database stays at its original compatibility level (130), Query Store captures a baseline through a real business cycle, the level is raised to 160 or 170 on your schedule, and any plan regression the newer optimizer introduces is forced back to its last known good plan from Query Store. That is Microsoft's documented workflow for exactly this transition, and it is why 'the upgrade broke our month-end reports' is not something you should have to say. Who this is for: organizations with one to ten SQL Server 2016 instances staying on-premises, mid-size to enterprise, priced per server and delivered in two-week waves. Who it is not for: if you have not yet chosen between ESUs, Azure and an on-premises upgrade, the SQL Server 2016 End of Support Options Assessment makes that call first; if the instances are moving to Azure, start with the SQL Server to Azure Migration Assessment and the Azure VM migration; if it is one small database and the target is an Azure VM, the fixed-price database copy is the simpler product; if you need time before any of this, the Managed ESU and Legacy Server Lifecycle Service runs the Extended Security Update stopgap and the SQL Server 2016 ESU Enrollment through Azure Arc switches it on; and failover cluster instances, availability groups and estates of ten or more instances are scoped and quoted per estate rather than squeezed into a per-server price.
Success criteria
What you receive
How the work unfolds
Kickoff call to confirm the instances, hosts and application owners in scope. IT Partner inventories each instance and host, runs Microsoft's upgrade-assessment tooling and our own checks, confirms licensing and the operating-system floor, and delivers the assessment with the recommended target and method per host for your approval.
Bring any instance below SP3 to Service Pack 3 in an agreed window. Take and restore-test the full backup set, export encryption keys, and confirm snapshot rights. Write the upgrade runbook and rollback plan with abort criteria, and rehearse the upgrade on a non-production copy where you have one.
Pre-flight checks (pending reboots, disk, services), write freeze, final backups and snapshot, go/no-go gate, then SQL Server Setup upgrade or the side-by-side install and database move, the current cumulative update, service and connectivity verification, and the application owners' smoke test before the window closes. Abort criteria are in force throughout.
Microsoft's post-upgrade completion list, then the component pass: Agent jobs, maintenance plans, linked servers and providers, SSIS catalog and packages, Analysis Services, full-text, and the Reporting Services migration where it is in scope. Issues found within scope are fixed here.
Query Store confirmed capturing on every database at compatibility level 130, the baseline window agreed, the raise-and-review runbook and forced-plan procedure walked through with your administrators, the as-upgraded document and closeout report delivered, our access removed, and delivery approved. Where your baseline window fits inside the engagement, the raise is executed before this point.
Prerequisites
Who does what
IT Partner
- Run the kickoff, inventory the instances and hosts, run the assessment tooling and our own checks, and deliver the assessment with a recommended target and method per host.
- Bring instances to Service Pack 3 where needed, take and restore-test the backup set, export encryption keys, and write the upgrade runbook and rollback plan with abort criteria.
- Perform the upgrade — in place or side by side on the same host — apply the current cumulative update, and verify services, connectivity and the application owners' smoke test before closing the window.
- Execute Microsoft's post-upgrade completion tasks and the component pass (Agent, maintenance plans, linked servers, SSIS, SSAS, full-text, SSRS migration where in scope), fixing configuration issues within scope.
- Configure Query Store, agree the baseline window, execute the compatibility-level raise where the window fits inside the engagement, and hand over the runbook and forced-plan procedure.
- Call a rollback if the abort criteria are met during the window, and restore the 2016 build from the proven backup set or snapshot.
- Deliver the as-upgraded document, validation evidence and closeout report, and remove our access at closeout.
Your team
- Provide a dedicated technical point of contact and the access listed in the prerequisites.
- Confirm the licensing route for the target version and buy any licence, Software Assurance or pay-as-you-go entitlement needed; Microsoft's licence, Extended Security Update and Azure charges are yours.
- Approve the target version and method per host, the maintenance windows and the written abort criteria before the upgrade window.
- Make application owners available for the smoke test in the window and after the compatibility-level raise, and own any application-side change a vendor requires.
- Provide backup storage and, where the host is virtual, the snapshot capability and its retention.
- Own the operating-system upgrade, hardware refresh or new-host build where the assessment shows one is needed to reach the target you want.
- Review the deliverables and approve delivery, or report defects, within the schedule.
What's not included
Limitations & technical notes
Frequently asked questions
Can we upgrade SQL Server 2016 directly to SQL Server 2025?
Yes, on two conditions Microsoft sets. The instance must be at SQL Server 2016 Service Pack 3 or later — SP3 is the minimum source level in Microsoft's supported-upgrade table for both 2022 and 2025 — and the host must run Windows Server 2019 or later, which is SQL Server 2025's operating-system floor. An instance on SP2 goes to SP3 first (we do that in the engagement); a host on Windows Server 2016 cannot take SQL Server 2025 in place, so it either lands on SQL Server 2022 or the operating system is upgraded first, which is separate work.
Should we choose SQL Server 2022 or SQL Server 2025?
Start from the host. If it runs Windows Server 2016, 2022 is the in-place option today. If it runs 2019 or later, 2025 is usually the better landing — generally available since November 2025, compatibility level 170, a higher Standard-edition ceiling (32 cores and 256 GB of buffer-pool memory per instance) and the longest support runway, with extended support to 2036 per Microsoft's end-of-support overview — unless the instance depends on Master Data Services or Data Quality Services, which 2025 discontinues, or an application vendor only certifies 2022. SQL Server 2022 remains in support until January 2033 per Microsoft's product lifecycle, so it is not a short-term choice either. The assessment records the recommendation per host with the reasons.
What is the difference between an in-place and a side-by-side upgrade, and which do you recommend?
In place, SQL Server Setup replaces the 2016 binaries on the same host and upgrades the instance: logins, Agent jobs, settings, paths and connection strings all carry over, the window is one evening, and the previous instance is gone afterwards — rollback means restoring the pre-upgrade backups or snapshot. Side by side on the same host, we install the target as a new named instance next to 2016, move the databases by backup and restore, switch connection strings or a SQL alias, and keep the old instance stopped for a fallback period. That buys a minutes-long fallback at the cost of a second instance name and a longer window. We recommend one per host in the assessment: in place for well-inventoried instances with a rehearsed restore, side by side where an application cannot afford even the restore time if something surprises us. Microsoft's own guidance recommends a new installation whenever the operating system or hardware is changing too.
How much downtime will we have?
For an in-place upgrade, the instance is offline from the write freeze through Setup, the cumulative update and the completion tasks — typically a single evening for one instance, and the runbook states the time budget for yours. The compatibility-level raise later is a metadata change per database, not an outage. Zero-downtime upgrades exist for Always On availability groups through Microsoft's rolling-upgrade procedure, and those estates are quoted separately.
How much does it cost?
$1,450 per server plus a $950 base fee — an estimate for standalone hosts with one instance each, confirmed as a written quote before work begins; you pay after you approve delivery. Three servers, for example, come to $5,300. Hosts with several named instances are confirmed in the quote, and failover cluster instances, availability groups and estates of ten or more instances are quoted per estate. SQL Server licences, Extended Security Updates and Azure charges are Microsoft's and billed to you by Microsoft, never through this fee.
How long does it take?
About 2 weeks per upgrade wave: assessment and approvals in the first two days, Service Pack 3, backups, restore test and the runbook by day five, the upgrade window on days six and seven, completion tasks and the component pass on days eight and nine, and handover on day ten. Several servers in one wave share the schedule and take their windows on different evenings. The compatibility-level raise follows your business cycle — inside the engagement when the baseline window fits, from the runbook as a short scheduled follow-up when it does not.
What happens to our SQL Agent jobs, linked servers and SSIS packages?
They survive an in-place upgrade, and we verify each one rather than assume it. Agent jobs, schedules, proxies and credentials carry over; maintenance plans are re-saved on the new runtime. Linked servers keep their definitions, but any still using the deprecated SQL Server Native Client provider are moved to the Microsoft OLE DB Driver for SQL Server, and third-party providers (Oracle, DB2, Access, ODBC) are checked for a 64-bit version installed on the host. SSIS packages in the catalog or msdb are moved to the upgraded instance in their existing format — the upgrade does not convert them — so running the SSIS Package Upgrade Wizard is a separate step we take on your decision, and packages that use custom components need versions built for the new runtime.
We run Reporting Services on the 2016 server. What happens to it?
SSRS 2016 was the last version installed by SQL Server Setup; from 2017 onward Reporting Services is a standalone product, and Setup cannot upgrade an SSRS 2016 instance in place. Where SSRS is in scope, we install the current standalone SSRS release, back up and restore the report server database and encryption key into it, verify reports, data sources and subscriptions, and retire the old instance. If your reports are heading to Power BI anyway, the SSRS to Power BI Migration is the better use of the money. Reporting Services in SharePoint-integrated mode was discontinued after 2016 and needs a redesign, which we quote separately.
What is a database compatibility level, and why don't you just set it to the newest one?
The compatibility level tells the engine which version's query-optimizer behaviour to use for a database: 130 is SQL Server 2016, 160 is 2022, 170 is 2025. Upgrading the engine does not change it, and that is deliberate. Raising it on upgrade night exposes every query to a new optimizer at once, and the ones that regress show up in month-end, not in your smoke test. Microsoft's documented workflow — and ours — is to leave each database at 130, let Query Store capture a baseline through a real business cycle, raise the level on your schedule, then use Query Store to find any plan that got worse and force its last known good plan while the root cause is fixed. You get the new engine's security and features immediately and the optimizer change under control.
What if something breaks during the upgrade — how do we roll back?
From the backup set and snapshot we proved before the window, against abort criteria you approved in writing. An in-place upgrade cannot be uninstalled back to 2016, and a database opened by the new engine cannot be restored on 2016, so the rollback is a restore of the pre-upgrade full backups (or a revert of the hypervisor snapshot) onto the 2016 build. The runbook states how long that takes, the go/no-go gate sits before the irreversible step, and if the criteria trip we call it rather than push through. Where an application cannot afford even the restore time, we recommend the side-by-side method, whose fallback is switching the connection string back.
Do we need new SQL Server licences to upgrade?
You need a licence that covers the target version: Software Assurance or subscription licences carry version rights, otherwise it is a new licence purchase, or SQL Server pay-as-you-go billing through Azure Arc. That is a commercial decision between you and Microsoft, and the assessment confirms which route you are on before any Setup runs. Buying licences, Software Assurance and true-ups are the Microsoft Volume Licensing service, and our SQL Server licensing calculator compares the routes.
Our SQL Server 2016 instances are on a failover cluster or in an availability group. Does this apply?
Not at the per-server price. Failover cluster instances and Always On availability groups are upgraded node by node and replica by replica under Microsoft's rolling-upgrade procedures, which change the runbook, the window and the risk model. We scope and quote those per estate after the assessment, including the case where you use the upgrade to redesign high availability.
Should we just buy Extended Security Updates instead?
ESUs buy time, not a future. Microsoft's current terms make SQL Server 2016 ESUs a paid subscription — through Azure Arc as a metered charge on your Azure subscription, or as a volume-licensing purchase for disconnected servers — and, unlike 2014, not free even on an Azure VM; they run for up to three years after end of support — for SQL Server 2016, through July 2029 per Microsoft's end-of-support overview — and cover security fixes only. If the upgrades cannot be scheduled before you need to be patched, the SQL Server 2016 ESU Enrollment through Azure Arc switches the subscription on and the Managed ESU and Legacy Server Lifecycle Service runs the stopgap, and the upgrade waves follow. If you have not decided which path fits, the SQL Server 2016 End of Support Options Assessment settles it; if the instances are leaving on-premises anyway, the SQL Server to Azure Migration Assessment is the better first step.
Our hosts are Windows Server 2016. Do we have to upgrade Windows too?
Not to reach SQL Server 2022, which installs on Windows Server 2016 or later. You do to reach SQL Server 2025, which requires Windows Server 2019 or later — and Windows Server 2016 itself leaves extended support on 12 January 2027 per Microsoft's product lifecycle, so the operating-system question is months, not years, behind the SQL one. Microsoft recommends a new installation rather than an in-place SQL upgrade when the operating system is changing as well, which is why we sequence the two: settle the Windows Server 2016 question with its own assessment, move the host with the Windows Server 2016 to 2025 Upgrade Service where that is the answer, then land SQL Server on the host that will still be supported.
Who owns this service at IT Partner?
Mike Mackey is the service owner. IT Partner has been a Microsoft partner since 2006 and delivers this alongside its SQL Server to Azure assessment and migration services, so the on-premises upgrade is scoped by the same people who would tell you if Azure were the better answer.