Disaster recovery plans that live only in a binder fail the only test that matters: the day you need them. Azure Site Recovery (ASR) is one of the few ways mid-size and enterprise Microsoft estates can replace a second datacenter contract with something you can actually fail over and measure. This post is how we implement ASR for Hyper-V and VMware estates, how we write recovery plans that are more than portal clicks, and what annual tests have taught us about RTO honesty.
When ASR is the right shape
ASR fits when:
- You can accept Azure as the recovery site (region chosen for compliance and latency)
- Workloads are virtualized on Hyper-V or VMware with supported replication paths
- You want staged recovery plans (AD first, then app tiers) rather than "power on the sandbox and hope"
- Finance is tired of paying for cold iron that never gets a real test
ASR is a weaker fit when the recovery requirement is hard air-gap with no cloud, or when applications need sub-minute RPO with architectures ASR does not support without redesign. Know which you have.
Replication is not a DR plan
Turning on replication for every VM is shopping, not architecture. We classify:
- Tier 0: identity and core network services — recover first, always
- Tier 1: line-of-business that makes money or safety
- Tier 2: important but delayed
- Out of scope: rebuild from pipeline or accept longer downtime
RPO targets drive replication frequency and storage cost. RTO targets drive recovery plan order, automation, and how much manual validation you allow mid-failover.
Hyper-V estates we already manage with SCVMM map cleanly when hosts and VMs are in a healthy state; garbage in inventory becomes garbage in recovery. Fix host agent health before you promise RTO numbers to the board.
Recovery plans as something you can rehearse
A recovery plan is ordered groups of VMs plus scripts plus manual actions. We treat it like code:
- Named plans per application stack, not one mega-plan for the company
- Scripts for DNS updates, load balancer pool membership, and smoke tests checked into source control where the client allows
- Manual steps with named owners and time boxes (not "someone will fix AD")
- Preconditions: Azure networking (VNets, peering, VPN/ER) already built — do not invent network during the disaster
The first test always finds a missing dependency: a license server, a jump box, a firewall rule that only existed in the primary site. That is the point of the test.
The annual test (and the quarterly mini-test)
We insist on:
- Documentation dry run — walk the plan without failing over
- Isolated test failover — validate boots and app checks without breaking production
- Planned failover rehearsal on a non-critical app stack at least annually
- Measured RTO — wall clock from declare to "business accepts service," not from "VMs show running"
Publish the number. If the slide said four hours and the test took eleven, the slide changes, not the stopwatch.
Cost versus a second datacenter
ASR plus Azure compute during a disaster is not free. It is usually cheaper than a warm secondary datacenter with duplicated hardware that fails its own test because nobody practiced. Model:
- Steady-state replication and storage cost
- Drill cost (compute hours during tests)
- Declared disaster cost (full compute for RTO window)
- People cost for running tests
Compare to colo, duplicated SAN, and the last time you truly failed over. CFOs understand that comparison when you bring both columns.
Failure modes we design for
- Identity first. If AD is wrong in Azure, everything else is theater.
- IP addressing. Re-IP vs stretch; applications with hardcoded IPs will punish you.
- Process servers and bandwidth. Initial replication saturation of WAN links — schedule it.
- Application owners absent. A plan that requires three SMEs who are on the same plane as the outage is not a plan.
Networking that must exist before the disaster
ASR does not invent ExpressRoute or a working VPN under fire. We require, in the primary project:
- Target VNets, subnets, and NSGs designed for recovered tiers
- Hybrid connectivity tested with non-ASR pilot VMs first
- DNS strategy: Azure DNS, conditional forwarders, or TTL tricks documented
- Jump host and monitoring in the recovery region so you are not blind after failover
We have watched teams replicate for months into a network design that could not route to the identity tier. Replication green; recovery impossible.
Hyper-V versus VMware paths
Both are supported with different moving parts (process servers, configuration servers, mobility agents depending on scenario). The operational truth is identical: clean inventory, consistent tools inside the guest (VSS, disks), and owners who know what "app up" means. ASR will cheerfully fail over a VM whose application stack needs three other VMs and a license dongle.
Governance
Who can declare a disaster? Who can run a failover in the portal? Separate break-glass from daily operators. Log every test. Regulated clients will ask for evidence; even unregulated clients should act as if they will.
Sample recovery order (illustrative)
- Domain controllers and DNS in Azure
- Jump hosts and monitoring
- Core file or profile storage if desktops depend on it
- Application databases
- Application servers
- VDI or RDS session hosts
- External publishing (gateways) last so you do not expose half-up apps
Your order will differ. The discipline is writing it, testing it, and updating it when applications change — not copying a blog post into production.
Bandwidth and initial replication
Initial replication can saturate WAN links for weeks on large estates. Schedule it, throttle it, and tell network operations before they open a severity ticket on "unknown Azure traffic." Delta replication after initial sync is usually manageable; the first copy is the project.
If you're facing this
If your DR strategy is a contract and a hope, ASR with rehearsed recovery plans is a concrete alternative for many Hyper-V and VMware estates. We design replication scope, Azure networking, and test cadences — bring your tier list and your last actual test results, even if the results are "we have never tested."