Microsoft's October 2026 Site Recovery update adds protection support for Azure Arc-enabled Windows VMware virtual machines and on-premises physical servers. Site Recovery detects existing Arc services during protection enablement and maintains compatibility with those configurations. Microsoft's feature update.
For hybrid teams, this addresses a practical compatibility concern: protecting a workload should not mean abandoning the management model already used for its source machine. The next step is a bounded recovery pilot, with separate evidence for replication, application recovery, and ongoing management.
Keep the Announcement's Scope Intact
The update specifically names Arc-enabled Windows sources and preserving existing Arc-based governance, inventory, monitoring, and management during protection enablement. It should not be generalized into a new compatibility promise for every operating system or recovery topology. Announced scope.
I would start by identifying the exact workload and recording its source platform, Windows release, Arc resource identity, current extensions, and intended Azure recovery location.
Check the current Site Recovery support matrix for the complete source configuration, appliance, operating system, disk, and networking requirements. Arc enrollment alone should not be treated as the eligibility assessment. VMware and physical-server support matrix.
Preserve a Management Baseline
Before a pilot, my recommended record would capture the source machine's expected Arc connectivity and the management functions its owner actually relies on. Include the responsible team and the place where each observation can be checked.
After protection is enabled, compare those observations with the baseline. Investigate a changed extension state or missing monitoring signal rather than assuming a healthy replication status proves everything else is unchanged.
Keep the result specific. Successful protection of one representative machine establishes evidence for that configuration, not automatic approval to onboard an entire estate with different software and access conditions.
Design the Recovery Test Around the Application
My proposed drill would use an approved test environment and a written isolation plan. Name the networks, dependencies, identities, and operators involved before starting it.
Prevent the recovered test application from accidentally sending production notifications, processing real transactions, or competing with the primary workload. Confirm who can stop the exercise if an unexpected connection appears.
Then validate the business result. A booted VM is an intermediate observation; the application owner should confirm the required service behavior, data checks, and dependency access.
Capture which recovery point was selected and when the application became usable. Keep data currency and elapsed recovery time as separate observations instead of collapsing them into a single green status.
Review the Recovered Machine's Management Design
I would agree in advance how the recovered Azure VM will be identified, monitored, secured, and assigned to an owner. Validate that design rather than assuming source-side compatibility answers every target-side management question.
Check the approved identity and access model, monitoring destination, policy expectations, and operational handoff. Record discrepancies between the planned design and the recovered test environment.
Treat cleanup and return-to-normal arrangements as part of the exercise. Assign ownership for temporary resources and retained evidence; do not leave an unowned recovery copy running after the test.
Roll Out by Verified Configuration
For a broader rollout, I would group machines by meaningful differences: source platform, operating system, application dependencies, and existing management configuration.
Select a representative pilot from each group and retain its acceptance record. Define a pause condition for unexpected management changes, replication errors, or failed application checks.
Keep a separate plan for lifecycle issues discovered during the assessment. A disaster recovery compatibility update is not a substitute for maintaining a supported operating system and application stack.
Practical Cloud Engineer Takeaway
Confirm the exact Windows source and recovery configuration.
Record Arc management behavior before and after protection enablement.
Test application recovery in an explicitly isolated environment.
Review target-side identity and management as a separate design decision.
Expand protection only after representative configurations pass their checks.
Who Should Care?
Azure Arc administrators, VMware and Windows platform teams, and continuity engineers protecting hybrid workloads in Azure.
Bottom Line
The October update makes Arc management and Site Recovery protection a more compatible combination for the named Windows sources. Turn that support into operational confidence with evidence for both the protected source and the recovered application.
This article proposes a pilot. No replication, role assignment, failover, or server configuration was changed for this post.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments