SQL Server 2012 to SQL Server 2022
Patch the source to SQL Server 2012 SP4 or later. Microsoft lists that source as a direct in-place upgrade to SQL Server 2022. You do not need SQL Server 2016 or 2019 as an intermediate release.

A supported SQL Server upgrade path depends on the source version and service pack, target version, edition route, architecture, and Windows Server compatibility. Enter the current and target setup below to see whether the move is direct, needs an intermediate upgrade, or is better handled as a side-by-side migration, together with the required patching steps.
Check an upgrade pathUpgrade inputs
Enter the current instance and the intended target. The current and target Windows versions determine whether this can remain an in-place change or needs a new server.
direct
Engine route
SQL Server 2016 → SQL Server 2022
Source requirement met: SQL Server 2016 SP3 or later. Microsoft's setup matrix does not name a CU as an additional upgrade prerequisite.
Edition route
Standard → Standard
Keep Standard edition through the version upgrade.
Upgrade method
One in-place upgrade
Each setup run appears in the ordered plan below.
Target CU branch
CU26 for 2022 (16.0.4265.3 - July 2026)
After the final setup run, apply CU26 for 2022 (16.0.4265.3 - July 2026). This is the current CU-branch target in Microsoft's update summary.
Security-only alternative
Use this only when you are deliberately keeping the target on its GDR-only servicing branch.
Current host
Windows Server 2019
The selected source release meets the Windows compatibility baseline.
Target host
Windows Server 2019
The target SQL Server version is supported on this Windows Server release.
This is the minimum source-version check for an in-place Database Engine upgrade. A listed version is only the first gate. The source edition, target edition, 64-bit architecture, installed features, and Windows Server release must also be supported.
| Source version | Target: SQL Server 2019 | Target: SQL Server 2022 | Target: SQL Server 2025 |
|---|---|---|---|
| SQL Server 2012 | Direct from SP4 | Direct from SP4 | No direct path. Use 2022 as an in-place step or migrate. |
| SQL Server 2014 | Direct from SP2 | Direct from SP3 | Direct from SP3 |
| SQL Server 2016 | Direct from RTM | Direct from SP3 | Direct from SP3 |
| SQL Server 2017 | Direct | Direct | Direct |
| SQL Server 2019 | Already on target | Direct | Direct |
| SQL Server 2022 | Earlier target | Already on target | Direct |
These are the version questions that most often cause confusion. The shortest supported setup route and the cleanest operational route are not always the same.
Patch the source to SQL Server 2012 SP4 or later. Microsoft lists that source as a direct in-place upgrade to SQL Server 2022. You do not need SQL Server 2016 or 2019 as an intermediate release.
There is no direct in-place path. A same-host chain can use SQL Server 2022 as the intermediate version when one Windows Server release supports SQL Server 2012 SP4, 2022, and 2025. Windows Server 2019 currently provides that overlap.
If the host also needs replacement, build SQL Server 2025 on the new server and migrate the databases and instance objects directly.
SQL Server 2014 must be on SP3 or later. SQL Server 2016 must also be on SP3 or later. Both can then upgrade directly to SQL Server 2022 when the remaining setup checks pass.
SQL Server 2014 SP3 and SQL Server 2016 SP3 are direct sources for SQL Server 2025. An intermediate SQL Server release is not required by the version matrix.
Both releases are direct sources for SQL Server 2025. Check the target edition carefully because Web edition is not available in SQL Server 2025.
Use a side-by-side migration rather than this in-place checker. Microsoft allows a backup taken on SQL Server 2008 or later to be restored to SQL Server 2022 or 2025 when the database compatibility level is 100 or higher. Logins, jobs, credentials, linked servers, certificates, and other instance objects still need separate handling.
A supported version path does not force you to use it. Pick the method that fits the host change, outage, fallback, and topology.
| Method | Use it when | Main tradeoff |
|---|---|---|
| In-place upgrade | The current server stays in use and every version, edition, architecture, feature, and Windows check passes. | Setup overwrites the old instance. A backup taken after upgrade cannot be restored to an older SQL Server version, so fallback needs a separately tested old environment or recovery method. |
| Side-by-side migration | The operating system or hardware changes, the source is 32-bit, the edition must be downgraded, or a separate rollback target is valuable. | You must migrate and validate instance-level objects as well as the user databases. |
| Rolling upgrade | Availability Groups, failover cluster instances, log shipping, mirroring, or replication require a controlled instance order. | The topology has its own supported sequence and version-mixing limits. |
A new installation keeps the current environment available while you build and validate the target. This is useful when the move also changes hardware or Windows Server. Read the Database Engine upgrade-method guide before choosing the production approach.
The target SQL Server version must run on the target operating system. For a same-host multi-hop upgrade, the installed Windows Server release must support the source, every intermediate SQL Server version, and the final target.
For example, Windows Server 2019 supports SQL Server 2012 SP4, SQL Server 2022, and SQL Server 2025. That makes it a possible common host for the SQL Server 2012 to 2022 to 2025 chain. Windows Server 2022 does not support SQL Server 2012, 2014, or 2016, so those sources cannot begin that same-host chain there.
If Windows Server also changes, the checker recommends a new target and a side-by-side migration. That keeps the SQL Server version decision separate from a Windows in-place upgrade sequence. Check Microsoft's current Windows and SQL Server compatibility table before scheduling setup.
A major-version upgrade can change some edition combinations as part of the same setup run. Other supported changes use a separate Edition Upgrade action after the engine reaches the target version. The checker lists that order instead of treating every edition change as one operation.
Edition downgrade is different. Microsoft requires SQL Server to be uninstalled and installed again with the lower-edition media. For an Enterprise to Standard move, build a separate Standard instance, check for Enterprise-only features and capacity limits, migrate, test, and cut over. The edition change documentation describes the supported setup process.
SQL Server 2025 removes Web edition and splits the previous Developer target into Enterprise Developer and Standard Developer. The checker uses those separate target editions because Microsoft lists different 2025 paths for them. A Web source can move to Standard or Enterprise during a supported major-version upgrade, but it cannot remain Web on the 2025 target.
Moving the Database Engine and raising a database's compatibility level are two changes, and they do not have to happen in the same window. A user database at compatibility level 100 or higher normally keeps that level after an in-place upgrade, restore, or attach to a newer supported SQL Server release. A database at level 90 is raised to level 100 because current targets do not support level 90.
Keeping the old compatibility level can reduce the number of query-processor changes introduced during the engine outage. It does not prove that the application is compatible with the new engine. Run Microsoft's current assessment in the SQL Server Management Studio migration component, test the workload, enable Query Store where appropriate, and raise compatibility level as a separate measured change.
Microsoft's compatibility certification guidance and compatibility level and Query Store guidance explain that separation.
The matrix tells you whether setup has a supported route. It does not test the databases, applications, or rollback plan.
| Check | What to confirm |
|---|---|
| Exact source build | Run the version query on the SQL Server updates page. Confirm ProductVersion, ProductLevel, ProductUpdateLevel, edition, and architecture. |
| Setup prerequisites | Clear pending restarts, confirm the Windows Installer service is available, verify free space, and use an account with the required setup rights. For SQL Server 2025, also verify SQL Server Agent uses Windows Authentication and its service account is a sysadmin. |
| Database consistency | Run DBCC CHECKDB on every database and resolve corruption before the change window. Verify that recent full, differential, and log backups can be restored. |
| Assessment | Run the SSMS migration assessment. Review breaking changes, discontinued features, target-edition limits, drivers, vendor support, replication, SSIS, and SSRS. |
| Features and components | Do not add features during an existing-instance upgrade. Plan component work separately; SQL Server 2025 does not support upgrades of DQS, MDS, or Reporting Services. |
| Protection and fallback | Take verified backups, test restore, preserve encryption keys and certificates, record the stop point, and prove the fallback inside the outage limit. |
| Instance objects | Inventory logins, jobs, credentials, linked servers, server triggers, endpoints, operators, alerts, proxy accounts, and server configuration. |
| Final servicing | After the last setup run, apply the tested current CU or stay on the chosen GDR branch. Recheck for a pending restart and validate the final build. |
Use the SQL Server upgrade planning guide for the full assessment and rollback workflow, and the upgrade checklist during review and execution.
The version and edition rules come from Microsoft's supported upgrade pages for SQL Server 2019, SQL Server 2022, and SQL Server 2025. Windows results use Microsoft's current operating-system compatibility table. Target CU and GDR cards use the same Microsoft-derived update data as the site's build checker.
The tool covers the Database Engine on Windows from SQL Server 2012 through SQL Server 2025. It does not certify application code, drivers, vendor products, SSIS, SSRS, Analysis Services, replication topology, licensing, or a production rollback plan. SQL Server 2025 component upgrades for DQS, MDS, and Reporting Services are outside the checker and are not supported by Microsoft. Microsoft can revise support tables, so open the linked source pages again before production work.
Yes. Microsoft lists SQL Server 2012 SP4 or later as a direct in-place source for SQL Server 2022, subject to the edition, 64-bit architecture, operating system, and other setup requirements.
No. SQL Server 2012 is not a direct in-place source for SQL Server 2025. A same-host route can use SQL Server 2022 as an intermediate release when one supported Windows Server version can host the complete chain. A new SQL Server 2025 instance and direct database migration is often the cleaner route when the operating system also needs to change.
Yes, after the source is on SQL Server 2016 SP3 or later. Microsoft lists SP3 as the minimum source level for direct upgrades to both SQL Server 2022 and SQL Server 2025.
No. Use a direct setup path whenever Microsoft lists the source version for the target. Intermediate engine setup is needed only when the selected in-place route is not direct, such as SQL Server 2012 to SQL Server 2025 through SQL Server 2022. A side-by-side database migration can remove the need for intermediate engine upgrades.
No. SQL Server Setup does not provide an in-place Enterprise to Standard downgrade. Microsoft documents downgrade as an uninstall and reinstall operation. For a major-version move, a separate Standard instance and tested database migration is normally the clearer plan.
A user database at compatibility level 100 or higher normally retains that level after an engine upgrade, restore, or attach. A database at compatibility level 90 is raised to the lowest supported level, which is 100 on current targets. Test the workload before raising compatibility level to the target version.
Use in-place only when the version, service pack, edition, architecture, operating system, outage, and fallback limits all fit. Use side-by-side when the host or operating system changes, the edition must be downgraded, the source is 32-bit, or a clean rollback path matters more than keeping the instance in place.
No. A SQL Server backup cannot be restored by an earlier Database Engine version. Keep the old environment available or use a separately tested rollback method instead of treating a backup from the upgraded instance as a downgrade path.