Supportability Query: In-Place OS Upgrade of a Modernized ASR Replication Appliance from Windows Server 2016 to 2019

Question

Supportability Query: In-Place OS Upgrade of a Modernized ASR Replication Appliance from Windows Server 2016 to 2019

Ronak Naresh Joshi 20

Dear Azure Site Recovery Team,

We require an authoritative supportability statement regarding the operating system of an existing Azure Site Recovery replication appliance.

Environment

On-premises VMware environment
Azure Site Recovery modernized architecture
Modernized ASR replication appliance, not a classic configuration server
Appliance operating system: Windows Server 2016 Standard
Appliance memory: 32 GB
Proposed change: In-place OS upgrade from Windows Server 2016 to Windows Server 2019
The appliance is actively protecting VMware workloads, including Windows Server 2008 R2 SP1 machines
Replication is currently operational

Documentation reviewed

The current replication appliance support matrix lists Windows Server 2022 as the appliance operating system. It also states that existing Windows Server 2019 appliances continue receiving software updates, but that upgrading the OS of an existing Server 2019 appliance to Server 2022 is unsupported.

However, the modernized appliance component-upgrade documentation still contains specific instructions for replication appliances running Windows Server 2016.

This creates uncertainty regarding the support status of existing Server 2016 modernized appliances and whether an OS upgrade is permitted.

Questions

Is an in-place operating system upgrade from Windows Server 2016 to Windows Server 2019 supported and tested for an existing modernized ASR replication appliance?
Does the Server 2016 reference in the appliance component-upgrade documentation mean that existing Server 2016 appliances remain supported for ASR software updates only, without supporting an operating-system upgrade?
If the in-place upgrade is supported:

Are there minimum ASR appliance component versions or other prerequisites?
- Will the appliance registration, identity, vCenter configuration, credentials, and protected-machine associations be retained?
- Will existing recovery points remain available?
- Will protected machines require re-registration or resynchronisation?
- What replication interruption or RPO impact should be expected?
1. Will the currently protected Windows Server 2008 R2 SP1 machines continue replicating normally after the appliance operating-system upgrade?
2. If an in-place upgrade is unsupported, is the supported migration path to:
  - Deploy a new modernized replication appliance using the current Windows Server 2022 appliance image;
    - Register it in the same Recovery Services vault; and
      - Use the documented Switch appliance function to move the existing protected machines?

When using a Switch appliance, can Microsoft confirm whether:

Existing recovery points and replication configuration are retained;
The machines perform a delta resynchronisation or a complete initial replication;
Replication remains recoverable during the switch;
- Windows Server 2008 R2 SP1-protected machines can be switched without disabling and re-enabling protection; and
- The workloads can be moved back to the original appliance if the switch is unsuccessful?

We do not want to perform an unsupported operating-system change on an active disaster-recovery appliance. A clear yes/no supportability statement and the recommended transition procedure would be appreciated.

0 comments

2 answers

Your answer

Answer 1

Hi @Ronak Naresh Joshi Thank you for posting your query on Microsoft Q&A platform.

1. In-place OS upgrade (2016 → 2019) of a modernized ASR replication appliance: not supported. The replication appliance support matrix lists Windows Server 2022 as the appliance operating system and explicitly calls out that upgrading the OS on an existing Windows Server 2019 appliance to Windows Server 2022 isn't supported. No in-place OS upgrade of the appliance is documented or tested, so this should not be performed on an appliance that is actively protecting workloads.

https://learn.microsoft.com/en-us/azure/site-recovery/replication-appliance-support-matrix

2. The Windows Server 2016 reference is component-update guidance only. The note in the component-upgrade article ("install .NET Framework 4.7.2 if you're using Windows Server 2016 for your replication appliance") is a prerequisite for manually updating ASR components on an existing appliance. It confirms existing Server 2016 appliances can continue receiving ASR component updates; it does not make an OS upgrade supported. https://learn.microsoft.com/en-us/azure/site-recovery/upgrade-mobility-service-modernized

3. Because the in-place upgrade isn't supported, there are no published prerequisites, registration/credential-retention guarantees, or expected RPO impact for that path.

4. Recommended transition path — yes, your proposed approach is correct:

Deploy a new modernized replication appliance on Windows Server 2022 (8 vCPU, 16 GB RAM, 80 GB OS disk + 620 GB data disk).
Register it to the same Recovery Services vault.
Use Site Recovery infrastructure → ASR replication appliance → Switch appliance to move the protected machines. https://learn.microsoft.com/en-us/azure/site-recovery/switch-replication-appliance-modernized

5. Switch appliance — documented conditions:

For a planned switch, all components of the current appliance must be healthy/warning (credentials are auto-selected); the target appliance must also be healthy/warning.
Only machines replicating on-premises → Azure can be selected.
Not supported if a protected machine has moved to a different vCenter server.
The switch acts on existing replicated items, so protection does not need to be disabled and re-enabled — including for the Windows Server 2008 R2 SP1 machines.

Thanks,

Suchitra.

Answer 2

Allan Solomon Mejia 7,585

Hi @Ronak Naresh Joshi

Thanks for raising this question.

Based on the current Microsoft guidance, an in-place operating system upgrade is supported for Azure virtual machines, provided the source and target Windows Server versions are supported by the in-place upgrade matrix and the VM meets the documented prerequisites. However, whether the VM is a member of a Virtual Machine Scale Set (VMSS) using Flexible orchestration is an important consideration.

If the VM has effectively been modernized and is now managed as an individual VM within a Flexible orchestration scale set, the OS upgrade itself is performed on the VM rather than on the scale set. Before proceeding, I would recommend:

Taking a full backup or creating a restore point/snapshot.
Verifying that the VM uses a supported marketplace image and Windows Server upgrade path.
Confirming that any VM extensions, monitoring agents, and security software are compatible with the target OS version.
Validating that your application supports the target operating system.

For production workloads, it's also worth considering whether a side-by-side deployment (building a new VM with the target OS and migrating the workload) would provide lower risk and an easier rollback strategy.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Ronak Naresh Joshi 20 Reputation points

2026-08-04T02:06:23.2633333+00:00

Hi @Allan Solomon Mejia thank you for your response. To clarify, this is not an Azure VM or VMSS scenario. It is an on-premises VMware VM running the Azure Site Recovery modernized replication appliance. The question is specifically whether Microsoft supports an in-place OS upgrade of the appliance itself from Windows Server 2016 to 2019 while preserving its ASR registration and existing replications. Could you please confirm this against the ASR replication appliance support matrix, or advise whether deploying a new Windows Server 2022 appliance and using the Switch appliance is the only supported path? If possible, could this be reviewed by an Azure Site Recovery product specialist?
Allan Solomon Mejia 7,585 Reputation points

2026-08-04T02:19:34.8866667+00:00
Hi @Ronak Naresh Joshi ,

Thank you for the clarification. That changes the scenario significantly.

Based on your description, you're referring to the Azure Site Recovery (ASR) Modernized replication appliance for VMware-to-Azure, not an Azure VM or VMSS.

From the current Microsoft documentation, I haven't found support for performing an in-place OS upgrade of the replication appliance while preserving its existing ASR registration and replication configuration. Although Windows Server 2022 is a supported operating system for protected machines and the modernized appliance, the documentation doesn't state that upgrading the appliance itself in place (for example, from Windows Server 2016 to 2022) is a supported lifecycle operation.

Because the replication appliance is a core infrastructure component, the documented and lower-risk approach is generally to:

Deploy a new replication appliance on the target supported Windows Server version.

Register the new appliance with the same Recovery Services vault.

Use the Switch Appliance workflow to migrate replication from the existing appliance to the new one.

This approach is the one Microsoft documents for appliance replacement and scale-out, and it avoids risking replication metadata or appliance registration.

Since your question is specifically about retaining appliance registration and existing replications after an in-place OS upgrade, I don't see official documentation confirming that this scenario is supported. I'd recommend waiting for confirmation from the Azure Site Recovery engineering team or Microsoft Support before attempting it in production.

Thanks for raising the distinction. It's a valuable clarification for anyone working with the ASR Modernized experience.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.
Ronak Naresh Joshi 20 Reputation points

2026-08-04T22:32:17.8666667+00:00

Thank you so much, @Allan Solomon Mejia It's very useful info. Thanks for your help.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.