Azure Site Recovery Test Failover: Isolated Network Checklist
This initiation-focused checklist supports planning a disaster recovery drill to Azure using a Site Recovery test failover. It does not cover job monitoring, test-failover cleanup, or drill closure because those procedures are not supported by the supplied evidence package.
Purpose and Drill Scope
Documented guidance: Microsoft describes a Site Recovery test failover as a way to run a disaster recovery drill to Azure. The supplied guidance also describes a disaster recovery drill for an on-premises machine to Azure by using Azure Site Recovery.
Recommendation — scope this document as a pre-initiation and initiation checklist only. Before the drill, assign a named operator, escalation owner, and approval authority; record pass/fail criteria; and obtain the current Microsoft procedure for monitoring, cleanup, and closure. Those workflow details are outside the supplied evidence.
- Quick start
- [ ] Record operator, date, recovery plan, and approval status.
- [ ] Complete the VM prerequisite review.
- [ ] Create and select an isolated test-failover network.
- [ ] Record the expected subnet and IP-placement behavior.
- [ ] Navigate to Recovery Plans > recoveryplan_name > Test Failover.
- [ ] Select the target Azure network.
- [ ] Capture the initiation action and any environment-specific assumptions.
Pre-Drill VM and Network Checklist
- Documented guidance — VM prerequisite
- [ ] Before running a test failover, verify VM properties.
- [ ] For a Hyper-V VM or VMware VM, make sure the VM complies with Azure requirements.
- Evidence reference: attach or cite the current Microsoft Azure-requirements prerequisite material used by the team.
- Documented guidance — test network
- [ ] Create a network for test failover.
- [ ] Set up an isolated network for the test failover.
| Operational record — per-VM review fields | |||
|---|---|---|---|
| Check | Owner | Evidence | Status |
| — | — | — | — |
| VM name | Assigned operator | VM identifier | ☐ Pass ☐ Fail |
| Source platform | Assigned operator | Hyper-V / VMware declaration | ☐ Pass ☐ Fail |
| Compute settings reviewed | Assigned operator | Review reference | ☐ Pass ☐ Fail |
| Network settings reviewed | Assigned operator | Review reference | ☐ Pass ☐ Fail |
| Azure-requirements result | Reviewer | Attached prerequisite checklist | ☐ Pass ☐ Fail |
| Reviewer and date | Reviewer | Signed record | ☐ Complete |
Isolation Decision: Test Network or Production Recovery Network
Documented guidance: for test failover, choose a network isolated from the production recovery-site network. One Microsoft instruction specifies the production recovery-site network in the Compute and Network settings for each VM.
Warning — operational decision: Microsoft documentation includes a scenario named “Test failover to a production network in the recovery site.” Do not treat this as equivalent to the isolated-network recommendation. Treat it as an exceptional team decision.
Rollback: Environment-specific assumption: use the team's approved abort and cleanup procedure; no rollback procedure is supplied in the evidence package.
Validation: Environment-specific assumption: validate the selected network and approved controls against the team's drill plan before initiation.
- Operational decision record
- [ ] Default path selected: isolated test-failover network.
- [ ] If proposing a production recovery-site network, change approval is attached.
- [ ] Environment-specific risk assessment is attached.
- [ ] Connectivity controls, abort criteria, escalation owner, and cleanup plan are recorded.
- [ ] Go/no-go authority has approved the selection.
Subnet and IP Placement Checks
Documented guidance: Site Recovery attempts to create test VMs in a subnet with the same name and the same IP address provided in the VM's Compute and Network settings.
Documented guidance: if the Azure virtual network used for test failover has no subnet with the same name, the test VM is created in the first subnet alphabetically.
- Environment-specific verification — complete before application testing or enabling broader connectivity
- [ ] Record the intended destination subnet and address range.
- [ ] Confirm routing, security controls, DNS behavior, and capacity against the drill plan.
- [ ] After VM creation, confirm the test VM's actual subnet and IP address.
- [ ] Record pass/fail, evidence location, reviewer, and escalation owner.
Validation: Use the team's approved environment-specific validation process.
Initiate the Test Failover
- Documented portal initiation
- In Site Recovery in the Azure portal, select Recovery Plans.
- Select recoveryplan_name.
- Select Test Failover.
Rollback: Not covered by the supplied evidence. Use the current approved Microsoft procedure and the team's change record.
Validation: Before initiation, obtain recorded go/no-go approval and confirm the selected network decision.
- Documented target-network selection
- In Test Failover, select the target Azure network to which Azure VMs connect after failover.
- Operational initiation gate
- [ ] Named operator and escalation owner are recorded.
- [ ] Approval status is recorded as go/no-go.
- [ ] Selected target Azure network is recorded.
- [ ] Expected subnet-placement behavior is recorded.
- [ ] Initiation timestamp and portal evidence location are recorded.
- [ ] Monitoring, cleanup, and closure procedures have been obtained from the current approved documentation.
Evidence Checklist and Drill Record
| Source-linked drill record | |||
|---|---|---|---|
| Check | Owner | Evidence | Status |
| — | — | — | — |
| VM properties and Azure requirements reviewed | Operator / reviewer | Prerequisite review attachment | ☐ Pass ☐ Fail |
| Test-failover network created | Network owner | Network record | ☐ Pass ☐ Fail |
| Isolated network selected | Approval authority | Network decision record | ☐ Pass ☐ Fail |
| Same-name subnet and same-IP attempt recorded | Operator | VM Compute and Network settings record | ☐ Complete |
| Alphabetical-first-subnet fallback recorded if applicable | Operator | Target VNet subnet inventory | ☐ Complete |
| Recovery Plans > recoveryplan_name > Test Failover initiated | Operator | Portal evidence | ☐ Complete |
| Target Azure network selected | Operator | Portal evidence | ☐ Complete |
| Environment-specific assumption record | |
|---|---|
| Field | Entry |
| — | — |
| Assumption identifier | ____________________ |
| Assumption | ____________________ |
| Owner | ____________________ |
| Validation method | ____________________ |
| Abort criterion | ____________________ |
| Rollback / cleanup procedure reference | ____________________ |
| Approval | ____________________ |
Azure Site Recovery Test-Failover Drill Record
- Operator, date, recovery plan, and approval fields
- Per-VM prerequisite review fields
- Network-decision and approval fields
- Subnet-placement expectation and actual-placement fields
- Portal initiation evidence fields
- Environment-specific assumption, validation, abort, and cleanup-reference fields
FAQ
What subnet and IP placement should an operator expect during a test failover?
Site Recovery attempts to create test VMs in a subnet with the same name and the same IP address provided in the VM's Compute and Network settings.
What happens when the test-failover Azure virtual network has no subnet with the same name?
The test VM is created in the first subnet alphabetically.
Should the team verify the actual subnet and IP after VM creation?
Recommendation: yes. Record the actual subnet and IP before application testing or enabling broader connectivity. This is an environment-specific verification step; it is not a supplied Microsoft requirement.