Design the destination application, network and return path before enabling replication. Transferring changed disk blocks is only one part of recovery. Users also need identity, DNS, access routes, capacity and a known authoritative copy of their data.
This guide uses the modernised Azure Site Recovery workflow to recover VMware guests as Azure VMs. It is not Azure VMware Solution, a VMware-to-VMware replication guide or the older classical Site Recovery architecture. Procedures are unpublished, source-researched lab instructions; no replication or failover was executed for this article.
1. Establish a supported recovery unit
Choose a small synthetic application consisting of one Windows application VM and one SQL VM. Record the exact guest builds, disk sizes and layouts, boot configuration, encryption, network adapters and application dependencies. Check each against the current VMware-to-Azure support matrix: https://learn.microsoft.com/en-us/azure/site-recovery/vmware-physical-azure-support-matrix. A supported ESXi release does not make every attached device, disk arrangement or guest configuration supported.
Treat a support mismatch as a design blocker. Do not omit a required disk to make replication succeed. Identify separate procedures for domain services, clustered databases, external file stores and licence services. This example does not establish support for every SQL availability architecture.
Define target RPO and RTO, the acceptable data loss and recovery time. Also define which transactions establish service acceptance. Write numbered synthetic records at known UTC times so that recovery can be compared with an external record of committed work.
2. Prepare the destination and appliance
Prerequisites are an approved Azure subscription, Recovery Services vault, registered modernised replication appliance, supported Mobility Service deployment approach and permissions suitable for the selected operations. Follow Microsoft's appliance preparation link in its modernised setup tutorial: https://learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-set-up-replication-tutorial-modernized; appliance installation itself is a separate prerequisite to this guide.
Prepare three network paths: source-to-replication services, operator-to-recovery environment, and recovered application-to-dependencies. Record permitted endpoints, DNS resolution, routing, proxies and firewall ownership. Verify these with the supported appliance checks instead of opening unrestricted internet access as a troubleshooting shortcut.
Build a target worksheet:
| Setting | Decision and evidence |
|---|---|
| Region and subscription | Approved location, required permissions and VM-family quota |
| Compute | Target VM size based on workload, not only matching vCPU count |
| Storage | Managed-disk capacity and performance suitable for the application |
| Recovery VNet | Subnets, routes, security rules, DNS and operator access |
| Test VNet | Separately verified isolation and lab dependencies |
| Access | Approved private administration path and recovery credentials |
| Cost | Replication storage, test compute, transfers and retention assumptions |
Cost and capacity figures must come from the actual design. No prices or recovery-time promises are assumed here.
3. Enable protection deliberately
In the vault, select Site Recovery and the VMware Enable Replication (Modernized) workflow. Select the registered vCenter, the exact lab machines, the appliance and approved guest deployment credentials. Review target subscription, resource group and region before continuing.
Choose the recovery network and a different test network. Review cache storage and managed-disk types, then choose or create a replication policy. Inspect recovery-point retention and application-consistency frequency explicitly; do not assume the default policy creates application-consistent points. Review the complete mapping before enabling replication. These settings and their order are documented in the modernised replication tutorial: https://learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-set-up-replication-tutorial-modernized.
Record the resulting job and protected-item identities. Wait for initial replication and inspect health, recovery points and lag using the service's normal monitoring. An enabled job without a usable recovery point has not met the recovery requirement.
For the synthetic workload, record how replication behaves during a representative write period. If lag grows, investigate appliance health, source churn, transport and target limits. A larger retention window does not fix an inability to keep up with writes.
4. Make the test environment safe and useful
Use an isolated test VNet that preserves the dependencies necessary for the application. Where matching production addresses are needed, prevent routing or peering that would let duplicates reach the original systems. Examine effective routes, security rules, VPN connectivity and outbound dependencies; isolation is a demonstrated property, not a name.
Provide a controlled administration path. Do not expose RDP to the public internet to simplify a drill. Disable or redirect synthetic copies of mail delivery, payment integrations, scheduled imports and other external effects before allowing application traffic.
Microsoft's drill tutorial: https://learn.microsoft.com/en-us/azure/site-recovery/tutorial-dr-drill-azure covers test-network preparation and VM properties. Domain-dependent applications require an explicit isolated AD/DNS plan. Missing identity dependencies must be reported as an incomplete drill, not worked around by connecting duplicate machines to production.
5. Run and measure a test failover
For a single lab VM, open its replicated item and choose Test failover. For a multi-VM recovery plan, use the plan's test operation. Select the intended recovery-point type and isolated network, then record the submitted job and selected point timestamps. Test failover is designed to preserve ongoing replication. Recovery-point options differ in processing time and consistency. Test-failover procedure: https://learn.microsoft.com/en-us/azure/site-recovery/site-recovery-test-failover-to-azure
Use an application dependency sequence: identity/DNS, database, application, then test clients. VM startup order alone is insufficient. Insert explicit readiness checks such as successful database access before starting the application test. The exact checks are application-specific engineering choices.
Record these milestones:
- Service interruption or simulated failure injected, then detection and recovery decision recorded separately.
- Drill declared, then operator access established as a separate timestamp.
- Test failover submitted and Azure VM available.
- Required dependencies ready.
- First correct end-to-end application transaction completed.
- Newest recovered synthetic commit identified and compared with the source manifest.
Report declaration-to-transaction acceptance as recovery execution duration. Full outage runs from service interruption to application acceptance and includes detection, investigation, decision/authorisation, access and traffic restoration as well as recovery execution. Compare that full interval with RTO. A prearranged isolated drill that does not exercise detection and decisions cannot prove full incident RTO; label those intervals unmeasured, not zero. Recovery objective definition: https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html Measure the data gap using committed application records, and state the uncertainty introduced by their sampling interval. The portal's replication lag is useful evidence but is not the complete application RPO measurement.
Preserve logs and results, then use Cleanup test failover and enter the drill notes. Verify the test resources are cleaned up and normal replication remains healthy. Never use disable replication as routine test cleanup. Drill completion guidance: https://learn.microsoft.com/en-us/azure/site-recovery/tutorial-dr-drill-azure
6. Diagnose the boundary that failed
| Failure | Investigation |
|---|---|
| No suitable recovery point | Replication health, policy, application-consistency processing and elapsed initial sync |
| Azure VM starts but is unreachable | Addressing, effective routes, security rules, guest firewall and administration path |
| Login works but application fails | DNS, domain access, service identity, database endpoint and external dependencies |
| Database works but data target fails | Selected point, application commit evidence and multi-VM consistency assumptions |
| Test meets timing but real recovery remains unclear | Detection, authorisation, traffic cutover and staff access excluded from the drill |
A drill exercises a controlled scenario. Record which disaster conditions it did not reproduce, including loss of the original site or unavailable administrators.
7. Engineer the real cutover and return path separately
Actual failover is a change of authority over production data. Its reviewed runbook must establish source fencing, traffic/DNS cutover, recovery-point selection, validation, commit authority and a supported response to failure. Site Recovery's attempt to shut down the source can fail while failover proceeds; therefore it cannot be the only split-brain control.
Commit finalises the selected point and removes other available recovery points. Returning later requires reprotection towards the on-premises environment, a supported planned failover back and renewed protection to Azure. Appliance access to the relevant datastore matters. Microsoft distinguishes cancellation of planned Azure-to-on-premises failover from on-premises-to-Azure failover. Modernised failover and failback reference: https://learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-tutorial-failover-failback-modernized
This draft deliberately stops short of executable production cutover or cancellation instructions. A qualified recovery specialist must validate those against the exact protected-item state and rehearse them in an isolated lab. “Turn the original VM back on” is not a safe return plan after the cloud copy has accepted writes.
Acceptance and limits
Accept the lab design when supported configurations are documented, replication remains healthy, application results and measured recovery targets pass, cleanup succeeds and the return-path prerequisites are recorded. Retain separate evidence for operational access, security and cost approval.
Replication does not replace an independent backup and retention strategy. An application-consistent point also does not automatically establish cross-VM consistency for every application design.
Related topics: application-consistent backup, VMware networking and recovery access security.
Learning notes
- Cloud recovery changes compute and networking assumptions as well as location.
- A successful drill needs the whole application dependency chain.
- Failback must preserve the writes made at the recovery site.
Sources and review status
See the source ledger for dates, version scope and limits, the author self-check, and the series index. Independent review and lab validation remain pending.