VpnWP

Upgrading Windows Server 2019 with SQL Server to 2022 or 2025

danroo
Upgrading Windows Server 2019 with SQL Server to 2022 or 2025

A Windows Server 2019 VM hosts an accounting application and SQL Server 2019. The goal is to move the operating system to Windows Server 2022 or 2025 without losing the installed application, databases, configuration, or access for its users.

Microsoft supports a direct in-place operating-system upgrade from Windows Server 2019 to either Windows Server 2022 or Windows Server 2025 on eligible nonclustered systems. That technical support does not guarantee that the accounting vendor supports the target OS, that every driver survives, or that the existing Windows license and CALs grant rights to the new version.

The upgrade decision has four separate gates: Microsoft upgrade path, application support, SQL support, and licensing.

Windows Server 2019 is supported, but already in extended support

Windows Server 2019 left mainstream support on January 9, 2024. Extended support continues through January 9, 2029, according to the current Microsoft lifecycle page. During extended support, security servicing continues, but remaining on 2019 is a time-limited plan rather than a permanent destination.

An upgrade does not need to be rushed without testing, but the 2029 deadline should be reflected in application and budget planning now.

The current direct upgrade paths

Microsoft’s current Windows Server upgrade-path guidance shows these installation-media paths for a nonclustered Windows Server 2019 system:

This corrects older guidance that required stepping through 2022 before reaching 2025. Beginning with Windows Server 2025, eligible nonclustered systems can upgrade across more versions.

Restrictions still apply. An in-place upgrade cannot change from one installation language to another or from 32-bit to 64-bit, and the edition path must be supported. Clustered systems, evaluation media, domain controllers, and special server roles require their own guidance.

Microsoft’s current in-place upgrade procedure also recommends a full backup of the operating system, applications, and data. For domain controllers, Microsoft prefers deploying a clean newer server, promoting it, and demoting the older controller instead of treating in-place upgrade as the default modernization method.

SQL Server 2019 can remain installed

The operating-system upgrade does not automatically upgrade the SQL Server engine. SQL Server 2019 can remain SQL Server 2019 while Windows moves to a newer release.

Microsoft’s current SQL Server and Windows compatibility table lists SQL Server 2019 as supported on both Windows Server 2022 and Windows Server 2025. Use a currently supported SQL Server 2019 cumulative update and verify the exact edition, components, drivers, and dependent tooling rather than relying only on the table’s “Yes.”

Inventory the instance before planning downtime:

SELECT
    @@VERSION AS FullVersion,
    SERVERPROPERTY('Edition') AS Edition,
    SERVERPROPERTY('ProductVersion') AS ProductVersion,
    SERVERPROPERTY('ProductLevel') AS ProductLevel;

Record instance names, service accounts, authentication mode, network protocols, ports, SQL Agent jobs, linked servers, Database Mail, certificates, backups, maintenance tasks, and application connection strings. An application can fail after the OS upgrade even when the database engine starts successfully.

Application support is the decisive gate

The accounting application vendor must support all three components together:

Ask the vendor for a written support matrix and upgrade procedure. Check license services, hardware-bound activation, ODBC or OLE DB drivers, .NET dependencies, scheduled tasks, report engines, printer components, antivirus exclusions, mapped paths, and any USB license device.

If the vendor supports Windows Server 2022 but has not certified 2025, choosing 2022 can be the lower-risk operational decision even though 2025 has the longer lifecycle. “Windows Setup permits it” and “the application vendor will support it” are different statements.

In-place upgrade versus a new VM

An in-place upgrade preserves applications, settings, roles, and data when successful. It also carries forward old drivers, abandoned software, and configuration debt.

A new VM provides a cleaner result and a simpler fallback: build the supported target OS, install the accounting application and SQL components, restore or migrate the database, validate clients, then cut over. It requires a supported application reinstall and a planned data migration.

Prefer a new VM when:

Use in-place upgrade when the vendor supports it, reinstalling is unusually difficult, dependencies are understood, and a tested recovery path exists.

Licensing does not follow the installer automatically

A supported upgrade path is not a free version entitlement. The organization needs valid rights for the target Windows Server release through an appropriate perpetual license, active Software Assurance, subscription, or other agreement terms.

Windows Server CALs are access rights, not product keys installed into the normal server activation screen. Users or devices accessing Windows Server 2022 generally need CALs valid for 2022 or a later version; moving to Windows Server 2025 likewise requires access rights that cover 2025. Remote Desktop Services has separate RDS CAL requirements and technical license-server configuration.

Do not infer CAL ownership from the server. Reconcile purchase records, licensing portals, agreements, user/device counts, external access, and Software Assurance with the reseller or Microsoft licensing representative. Microsoft Learn confirms that CALs are access rights and do not require a download or product key, but the customer’s agreement remains the authority for use rights.

If SQL Server remains at version 2019, the OS upgrade does not turn it into SQL Server 2022 or 2025 and does not grant a newer SQL license. Confirm whether SQL is licensed per core or Server + CAL, which users or devices access it, and whether application multiplexing changes the licensing count. Technical CPU visibility is not proof of license ownership.

Build a recoverable baseline

Before the maintenance window, capture the operating-system and application state:

Get-ComputerInfo |
    Select-Object WindowsProductName, WindowsVersion, OsBuildNumber,
                  OsArchitecture

Get-WindowsFeature |
    Where-Object Installed |
    Select-Object Name, DisplayName

Get-Service |
    Where-Object StartType -eq 'Automatic' |
    Select-Object Name, Status, StartType

Export the application configuration through its supported mechanism. Record free disk space, attached volumes, drive letters, static addresses, firewall rules, certificates, scheduled tasks, service identities, and installed software.

For SQL Server:

  1. Run DBCC CHECKDB for each application database and resolve corruption before the OS change.
  2. Take full database backups and verify that the backup jobs completed.
  3. Restore the backups to a separate SQL instance and run application-level checks.
  4. Back up encryption keys, certificates, service master key dependencies, and vendor-specific configuration where applicable.
  5. Script SQL Agent jobs, logins, linked servers, and other server-level objects not contained in a user-database backup.

A hypervisor snapshot can help with a short maintenance rollback when created in an application-consistent state, but it is not the only backup. Keep independent database and system backups outside the VM’s datastore. Do not leave a snapshot growing through normal production use.

Rehearse the upgrade on an isolated clone

Clone the VM into an isolated network so it cannot contact production clients, license services, domain resources, mail systems, or scheduled integration endpoints unexpectedly. Prevent duplicate hostnames and IP addresses from appearing on the production network.

In the rehearsal:

  1. Apply current supported updates to Windows Server 2019, SQL Server 2019, drivers, and the application as required by their vendors.
  2. Remove unsupported software only with a documented reason and rollback.
  3. Mount genuine installation media that matches the target language and edition.
  4. Run Windows Setup compatibility checks and retain the reports.
  5. Choose to keep files, settings, and applications only when Setup offers the supported path.
  6. Complete the upgrade and all required restarts.
  7. Test the full accounting workflow from representative client machines.

Measure duration and record every manual step. A successful boot and login are not sufficient acceptance criteria.

Post-upgrade validation

After the production upgrade, verify in a fixed order:

Keep the old environment or rollback state isolated until business owners accept the result and a fresh post-upgrade backup has been tested.

Choose the target based on support, not novelty

Windows Server 2025 offers the longer runway and now supports a direct upgrade from 2019. Windows Server 2022 may still be the correct target when the accounting vendor, drivers, or operational tooling have a better-tested support matrix there.

The applications and SQL databases can remain in place during a supported in-place upgrade, but “remain installed” is not the same as “remain functional.” A rehearsed clone, verified SQL restores, written vendor compatibility, correct target-version licensing, and application-level acceptance testing turn the upgrade from a hopeful installer run into a controlled migration.

Related Guides

Exit mobile version