2026: Do You Still Need to Migrate After Windows Server 2022 Mainstream Support Ends?

The Microsoft lifecycle page lists October 13, 2026, as the end of Windows Server 2022 mainstream support and October 14, 2031, as the end of extended support.

Suitable to stay: the business still receives applicable security updates, its software vendors support the environment, and no required feature demands a newer release.

Not suitable to stay without a plan: a critical application is unsupported, a required capability is missing, or the organization cannot meet its security and recovery requirements on the existing installation.

Mainstream support ending does not mean Windows Server 2022 must be shut down or migrated immediately. Treat migration as a decision based on security controls, application compatibility, and operational need—not as an automatic response to a lifecycle milestone.

This guide is for IT administrators responsible for Windows Server 2022 production systems; teams maintaining IIS, .NET, or other Windows-dependent software; and small-business technical leads preparing a future server budget.

Last updated October 23, 2026. Lifecycle dates were checked against Microsoft’s Windows Server 2022 lifecycle page and Windows Server 2025 lifecycle page.

Separate mainstream support from extended support

Mainstream support and extended support are different lifecycle phases. The end of mainstream support is not the same event as the end of all Microsoft support. Microsoft lists these dates:

Dates are based on Microsoft’s Windows Server 2022 and Windows Server 2025 lifecycle pages. Check those pages again before making a procurement or migration decision because Microsoft’s published lifecycle information is authoritative.

The dates help answer when a product’s lifecycle phase ends. They do not establish that a specific server is secure, that a business application will run on a newer release, or that an organization’s own security requirements are met. They also do not prove that a migration will be low risk.

For a supported installation, extended support is the remaining official support phase for Windows Server 2022. That is why the end of mainstream support alone does not create an immediate migration deadline. Keep the system configured to receive applicable updates, and confirm its licensing, update source, and operational status rather than assuming that an in-support date guarantees updates are being installed.

Check whether Windows Server 2022 can remain in service

Windows Server 2022 can remain in use after mainstream support ends if the conditions around it are acceptable to the organization. The answer to “Can it still be used?” is therefore conditional: the lifecycle date permits continued planning within the extended support period, but the business must still manage patching, access, backups, and application-vendor support.

Use this checklist to test the current environment:

• [ ] Security updates: Confirm that updates are available to the installation and that the server is receiving and installing them. Review Windows Update or the organization’s update-management console, then investigate failed or repeatedly deferred updates.
• [ ] Remote administration: Limit administrative access to approved routes and accounts. Avoid leaving remote administration broadly reachable from the public internet; use the organization’s controlled access method and review firewall scope and authentication settings.
• [ ] Recovery: Confirm that business data, application configuration, and system recovery requirements are covered by backups stored independently of the server. A backup is not a recovery plan until the organization has tested that it can restore what the service needs.
• [ ] Application support: Check the software vendor’s current support matrix for the operating system, application version, database dependencies, drivers, and any required runtime.
• [ ] Ownership and monitoring: Identify who reviews update failures, security alerts, backup results, and vendor notices. If no team owns these checks, the lifecycle date is not the main operational risk.
• [ ] Change control: Record the current build, installed roles, integrations, scheduled tasks, and any software that depends on the server before changing the operating system.

To record the installed system, an administrator can open Server Manager → Local Server and review the operating-system details. In an elevated PowerShell session, this command collects basic version information:

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

To inspect recently installed updates, review Settings → Windows Update → Update history or use:

Get-HotFix | Sort-Object InstalledOn -Descending |
  Select-Object -First 10

These checks support an inventory; they do not prove that every required security update is installed. Compare the result with the organization’s update records and investigate gaps.

Check application and infrastructure compatibility

A successful operating-system installation does not guarantee that an application, driver, or integration is supported on that operating system. Before deciding on Windows Server 2025, list the components that make the current workload function and verify each against its vendor’s documentation.

For an IIS or .NET environment, include the application’s target runtime, hosting model, IIS modules, authentication method, certificates, scheduled jobs, and any external services it calls. For ERP or other packaged software, check the vendor’s supported Windows Server versions, database requirements, licensing prerequisites, and hardware or peripheral dependencies. If a vendor only documents support for the current environment, ask the vendor before treating an upgrade as safe.

Microsoft’s application compatibility guidance is useful for framing compatibility checks, but it cannot replace the software publisher’s own support matrix. For a feature-driven move, verify the precise prerequisites in the relevant Microsoft documentation. For example, the SMB feature descriptions document specific file-server capabilities; a desired feature should be checked against the documentation for the target release rather than assumed to be present or configured by default.

Keep these risks separate during review:

• Operating-system compatibility: Does the vendor support the application on the target Windows Server release?
• Dependency compatibility: Do runtimes, drivers, authentication services, and connected systems work together on that release?
• Operational compatibility: Can the team monitor, patch, back up, and restore the new environment using its existing tools and procedures?
• Business acceptance: Can users verify the workflows that matter, including scheduled tasks and integrations, before production cutover?

A brief isolated test can reveal issues that a general compatibility statement will not. Use a representative copy of the application and its configuration, document the test result, and avoid changing the production server simply to discover whether a dependency still works.

Decide whether Windows Server 2025 solves a real need

The question “Should Windows Server 2022 be upgraded to 2025 now?” has no universal yes-or-no answer. A move is worth evaluating when the target release provides a capability the business needs, the application vendor supports it, or a planned new deployment makes a clean build easier to manage. For an existing service that is stable, supported by its software vendors, and meeting security requirements, a migration driven only by the end of mainstream support may add work without solving a current problem.

Use these conditions to guide the decision:

• Stay on 2022 for now when the workload is stable, required updates are being applied, vendors continue to support the stack, and there is no immediate requirement for a newer feature.
• Test 2025 before committing when the application vendor’s support statement is unclear, a driver or integration is critical, or the team needs to confirm administrative procedures on the new release.
• Plan a move to 2025 when a documented business requirement depends on it, the software vendor requires it, or a scheduled refresh makes parallel validation practical.
• Delay production cutover when restore procedures are untested, key dependencies have not been checked, or no owner is available to validate the service after migration.

If 2025 is being considered for a particular capability, tie the decision to that capability’s official prerequisites and the application’s support matrix. Do not treat a feature list as proof that a business workload will benefit. Feature availability, configuration, and compatibility are separate questions.

Choose a path and validate it before changing production

A Windows Server 2022 migration can mean a direct upgrade, a move to a separately built server, or no migration yet. The right path depends on the application’s support, the quality of the recovery plan, and how much operational change the team can absorb. Microsoft’s installation, upgrade, and migration guidance can help administrators compare deployment approaches; confirm the applicable procedure for the specific release and workload.

Use this decision table:

For a controlled evaluation, work through these steps:

Inventory the production workload. In Server Manager, review installed roles and features. In PowerShell, capture a basic role inventory:

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

Also record IIS sites, application pools, certificates, scheduled tasks, service accounts, firewall rules, data locations, and external integrations. Store configuration records somewhere separate from the server.

Confirm vendor support. Collect the official support statements for the application, runtime, database, drivers, and integrations. Record the exact product versions and the target Windows Server release under consideration. If documentation does not answer the question, obtain confirmation from the vendor rather than inferring compatibility from a successful test alone.

Protect the current service. Confirm that the backup includes the data and configuration needed to restore the workload. For Windows Server Backup, the graphical route is Server Manager → Add roles and features to add the feature if needed, followed by Windows Server Backup to configure or run a backup. A command-line example is:

wbadmin start backup -backupTarget:<backup-volume> -include:C: -allCritical -quiet

Replace the placeholder with an appropriate backup target before running the command in an elevated session. Confirm that application data stored outside the included volumes is covered separately, and verify restoration in a non-production setting.

Build a representative test environment. Install the proposed release in an isolated environment and apply the intended roles, updates, runtime, and security configuration. The test should represent the production dependencies closely enough to exercise important workflows, without exposing production data or changing the live service.

Run acceptance tests. Have application owners test sign-in, key business transactions, scheduled jobs, reports, file access, integrations, and recovery procedures. Record failures and the vendor response. Do not approve a cutover while a critical dependency remains unverified.

Write the cutover and rollback plan. Define the change window, data synchronization approach, validation owner, and conditions that trigger rollback. Keep the existing server available until the new environment has passed the agreed checks. The rollback plan should state how the service returns to the previous system and how data written during the change will be handled.

Review after the change—or after the decision to stay. If the organization remains on 2022, document why the system is acceptable, who owns its controls, and when the lifecycle and vendor-support status will be checked again. If moving to 2025, review the same controls after cutover and confirm that backups, monitoring, and update processes work on the new installation.

Prepare a new environment without treating migration as urgent

For a planned new deployment or a justified migration, compare the operating-system choice with application support before selecting a server. XFP Cloud’s server configuration options list Windows Server 2019, 2022, and 2025, with English, Traditional Chinese, and Simplified Chinese language options; Windows systems are accessed through RDP. Confirm the current product details before ordering, and do not treat the availability of an operating-system image as proof that a specific application is compatible.

The practical question is whether a separate environment makes testing and cutover safer for the workload—not whether a lifecycle date makes immediate purchasing necessary. For a production service, an independent environment can provide a place to validate the application before changing the existing system, but the migration team still needs to plan data movement, recovery, and rollback. Review the applicable billing terms as part of procurement planning; no price or migration outcome should be assumed from the lifecycle dates.

If the current Windows Server 2022 environment continues to receive applicable updates, meets security and recovery requirements, and remains supported by its software vendors, staying on it is a defensible decision while extended support remains in effect through October 14, 2031. If a required application or feature points to Windows Server 2025, test that target against the vendor’s support matrix and business workflows before production cutover. For a new or parallel environment, XFP Cloud’s Windows Server options can be reviewed alongside the application’s compatibility requirements; the next step is validation, not a purchase deadline created by the end of mainstream support.