What changed

Microsoft announced general availability on 19 August 2026 for the Azure-to-Azure scenario, covering both test failover and failover. Microsoft’s customise-networking page was updated the following morning and now lists the network interface among the resources a customer can supply for the failover VM, alongside internal load balancers, public IPs, secondary IPs and network security groups.

The operational risk is easy to miss because the service can continue to look healthy. The control becomes visible only when a capacity request fails, an unsupported runtime is removed, or an extension blocks an enforced ERP update. Waiting for that moment transfers a planned decision into an incident.

What the term means in plain language

Bring Your Own NIC allows an existing network interface, created ahead of time in the recovery region, to be attached to the recovered machine rather than having Site Recovery create a new interface during failover. Because the interface exists in advance, its IP address, subnet placement and network security group association are all fixed and reviewable before any incident.

This distinction matters because product status is not the same as business readiness. Availability, support and compatibility are separate questions. A service can be available but unsupported, supported but capacity-constrained, or technically updated while a customer-specific process has stopped working.

Why this matters to a South African organisation

South African teams often operate with tight specialist capacity, rand-sensitive budgets and business processes that cannot be paused while a replacement is sourced. Localisation, regional cloud capacity and long procurement lead times can narrow the recovery options. The practical response is to use the available test window before it becomes an emergency window.

The consequence belongs to the business process, not only the technology team. Finance month-end, customer transactions, data pipelines and ERP extensions all cross technical and operational ownership. A change should therefore be accepted only when the service owner and the business owner can see the same evidence.

The hidden exposure

Azure Site Recovery can now attach a pre-provisioned network interface in the target region for test failover and failover. The value depends entirely on the work being done in advance, and a recovery-plan drill quietly substitutes a network for any machine that was not pre-configured.

Normal operation is weak evidence. It proves only that yesterday’s combination of platform, configuration and workload completed. It does not prove that the next capacity allocation, lifecycle enforcement or major release will preserve the same result. An owner needs an inventory, a representative test and a dated decision.

Decision path

The decision is whether the recovery network becomes a designed artefact or stays an artefact of the outage. Microsoft’s prerequisite is explicit: create the networking resources in advance and provide them as an input so the service can honour them. Nothing is gained by enabling the capability without doing that work. The second and less obvious decision concerns how drills are judged. Microsoft’s page states that a test failover triggered from a recovery plan always asks for a virtual network, and that this network is used for machines that did not have test-failover settings pre-configured. A partially configured estate therefore produces a drill that completes successfully while several machines come up somewhere unintended, so the evidence a recovery test produces must record which network was used, not merely that the job succeeded.

Record the alternatives that were rejected and why. That prevents the next reviewer from reopening the entire question without context. Where the preferred path cannot be completed inside seven days, approve a time-bound exception with a responsible owner, expiry date and compensating control.

Technical test plan

Pre-create the target network interface, its subnet, the network security group and any reserved IP in the recovery region. Bind them per replicated item under Replicated Items, Network, Edit, selecting the pre-created resources for the test-failover and failover locations independently. Note Microsoft’s constraint that a target networking field is enabled only where the source VM had a corresponding input. The documented validations require the subscription and region of the network security group, public IP and internal load balancer to match the target VM; a Basic SKU load balancer does not support zones and is filtered from the list where the target VM is zonal. Where the target VM sits in an availability set, Microsoft warns that public IP and load balancer SKUs must be consistent across the set or failover might not succeed.

Use production-representative conditions without exposing production data unnecessarily. Capture the starting configuration, exact version, time of test and expected result. A pass requires evidence from the real workflow, not only a successful login or an unchanged dashboard.

Primary owner

Primary owner: Disaster-recovery lead with the network and security owners.

The named owner coordinates platform, application, commercial and business-process decisions. Contributors may perform the work, but accountability cannot be distributed across a meeting invite. The owner closes the test, exception and evidence record.

Action within seven days

Action within seven days: Select one protected VM, pre-create its target network interface, network security group and reserved IP in the recovery region, bind them for both test failover and failover, then run the test failover and confirm which network was actually used.

Start with the highest-consequence workload. Assign the people, date and pass criteria before the test begins. If the first test fails, record the failure as evidence and open remediation with a deadline rather than hiding it behind a general project status.

Evidence to retain

Evidence to retain: Target NIC resource ID, reserved IP, network security group association, the test-failover job ID, and the record showing which network the test used.

Store the evidence with the platform or change record. Include source exports and machine-readable results where possible. The next reviewer should be able to reproduce the conclusion without rebuilding it from email, chat or memory.

Frequently asked questions

Does this make the recovery plan automatic?

No. It removes one component that would otherwise be created during the incident. Microsoft’s prerequisite is that the networking resources are created in advance.

What happens to machines that were not pre-configured?

Microsoft states that a test failover triggered from a recovery plan always asks for a virtual network, and that network is used for machines without pre-configured test-failover settings. The drill still completes.

Which scenario does this cover?

Microsoft’s announcement specifies the Azure-to-Azure scenario, for test failover and failover.

Why is a networking field greyed out?

Microsoft states the target field is enabled only where the source VM had a corresponding input, and that filters apply so the failover VM can attach to the resource selected.

The Braintree view

Microsoft’s announcement supplies the platform fact. The customer control begins after that fact: identify the exposed process, name the owner, test the real dependency and retain a decision that can survive audit or staff turnover. Braintree can help structure the inventory, build the representative test and translate the result into a controlled implementation plan.

Use the seven-day action as the entry point. Do not wait for a renewal, support refusal or enforced update to reveal work that can be measured now.