In this blog post Azure Site Recovery for Azure Local Is GA What IT Teams Should Do Next we will explain what Microsoft’s October 2026 release means, where it can reduce recovery risk, and what to check before protecting production systems.
Many mid-market businesses believe they have disaster recovery covered because their servers are clustered or backed up. The uncomfortable truth appears during an outage: nobody knows which applications must start first, whether the cloud network is ready, or how long recovery will actually take.
Azure Site Recovery for Azure Local is designed to close part of that gap. It copies protected virtual machines from your local infrastructure into Azure and coordinates their recovery if your office, data centre or server environment becomes unavailable.
What Azure Site Recovery for Azure Local actually does
Azure Local is Microsoft’s platform for running virtual machines on hardware located in your office, data centre or branch while managing that environment through Azure. It suits organisations that need some systems to remain on-premises because of performance, data location, operational or application requirements.
CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.
Visit CPI ConsultingAzure Site Recovery, often shortened to ASR, continuously sends changes from selected virtual machines to Azure. If the local environment fails, those machines can be started in Azure using their most recently replicated data.
This is different from a backup. A backup gives you a historical copy of data, while Site Recovery is focused on getting complete systems running again quickly. Most organisations need both because corrupted or encrypted data can also be replicated to the recovery environment.
The service supports the full recovery cycle. IT teams can test recovery without interrupting production, fail systems over to Azure during an incident, return them to Azure Local when the original environment is stable, and then restart protection.
What changed with general availability
Microsoft made Azure Site Recovery for Azure Local generally available on 5 October 2026. General availability, or GA, means Microsoft now supports the capability for production use rather than treating it as a preview feature.
The biggest improvement is a simpler deployment process. From the Azure Local resource in the Azure portal, teams can use a single setup wizard to create or select the main recovery components, install the required Site Recovery agent across cluster nodes and apply a replication policy.
The GA release also supports Windows Defender Application Control in enforcement mode. This security control restricts which software can run on a server, helping prevent unauthorised or malicious applications. Teams no longer need to weaken that policy simply to install the Site Recovery agent.
Built-in proxy configuration is another practical improvement for organisations that tightly control outbound internet access. These changes remove setup friction, but they do not remove the need for recovery planning.
The wizard is not your disaster recovery plan
A successful deployment only proves that data is being copied. It does not prove employees can use an application after failover.
Your recovery environment may still require identity services, domain name resolution, secure network connections, firewall rules, application licences and access to third-party services. Starting a server without those dependencies can leave you with a healthy-looking virtual machine and an unusable business application.
If you are still deciding which hybrid workloads should be protected, our earlier guide to using Azure Arc and Site Recovery without re-platforming servers explains how recovery can be introduced without first rebuilding every application.
Five actions Australian IT teams should take next
1. Agree on acceptable downtime
Start with the business, not the Azure portal. Ask each system owner how long the organisation can operate without their application and how much recent data it could afford to lose.
These answers become your recovery time objective and recovery point objective. In plain English, they define how quickly a system must return and how far back its recovered data can be.
Not every server needs the same target. Protecting everything equally can increase cost without improving the recovery of your most important services.
2. Prioritise complete business services
Do not select virtual machines in isolation. Group them according to the service they provide and document the order in which they must start.
An ordering platform, for example, may depend on identity services, a database, integration software and an application server. Recovery plans can coordinate these groups, but your team must identify the dependencies first.
This is where many recovery projects fail. The infrastructure returns, but the application remains unavailable because a forgotten supporting service was not included.
3. Prepare the Azure landing zone
The replicated machines need somewhere secure and correctly sized to run. Confirm the target Azure region, network design, IP addressing, security controls, storage requirements and available computing capacity before enabling production protection.
Also estimate the ongoing replication and storage costs, plus the temporary compute costs created during testing or a real failover. A smaller recovery environment may be acceptable for lower-priority systems, but that decision should be documented rather than discovered during an outage.
4. Review security and administrative access
Disaster recovery permissions are powerful. An attacker who gains access may be able to change replication, interfere with recovery points or start sensitive workloads in another environment.
Use separate administrator roles, multifactor authentication and tightly controlled emergency accounts. Monitor changes to recovery policies, vaults and network configurations so suspicious activity is noticed quickly.
Australia’s Essential Eight, the government framework many organisations use to improve cybersecurity, has now evolved into ASD Essentials for enterprise IT. Existing Essential Eight controls and evidence remain useful, but organisations should begin mapping them to the new framework’s principles, actions and priority phases.
Site Recovery can support operational resilience, but it does not replace protected backups or satisfy a security framework by itself. Recovery evidence should include access reviews, monitoring records, test results and proof that clean data can be restored.
5. Run a realistic recovery test
Azure Site Recovery can create test machines in an isolated Azure network without interrupting production replication. Use that capability before executives assume the project is complete.
A useful test confirms more than whether a server starts. Ask business users to sign in, open the application, complete a representative transaction and verify connected services.
Record the actual recovery time, manual steps, unexpected costs and failed dependencies. Repeat the exercise after major application, network or identity changes, with formal drills at least every six months for critical services.
Our guide to building stronger Azure resilience covers the recovery plans, access controls and accountability needed to make these tests repeatable.
What this looks like in a mid-market business
Consider a 180-person distributor running its warehouse and finance applications on Azure Local. The cluster can handle an individual server failure, but a prolonged power or site outage would stop dispatch, invoicing and stock updates.
Rather than replicating every machine, the IT team protects identity, database, integration and application servers as one business service. It prepares a restricted Azure network, documents the startup order and runs a test with warehouse and finance users.
The first test finds that a third-party licensing service cannot be reached from Azure. Fixing that issue during a planned exercise takes hours; discovering it during a real outage could halt operations for days.
That is the real value of Site Recovery. It exposes gaps while the business is still running and gives the team a practical path to restore priority services.
Make GA the start of the work rather than the finish
Azure Site Recovery for Azure Local is now easier to deploy, suitable for production and better aligned with locked-down environments. For Australian mid-market organisations, it creates a realistic recovery option without requiring every application to be permanently moved into the public cloud.
The business outcome depends on what happens after setup: clear recovery targets, protected dependencies, secure access, predictable costs and regular testing.
CloudProInc brings more than 20 years of enterprise IT experience to this work. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we assess the Azure design, security exposure and operational recovery process rather than treating replication as a tick-box exercise.
If you are unsure whether your Azure Local environment could recover within the time your business expects, we are happy to review the current setup and identify the practical gaps — no strings attached.