Azure Site Recovery’s High Churn option can now support data-change rates of up to 500 MB/s per virtual machine, compared with its previous 100 MB/s ceiling. This is useful for high-throughput workloads such as heavily used databases, but 500 MB/s is a maximum rather than a standard result. The practical limit depends on the virtual machine’s memory, disk type and size, write pattern, operating system, region and Azure Site Recovery Mobility service version.
For most London businesses, the update does not require an immediate redesign. It does, however, create an opportunity to reassess workloads that previously exceeded Azure Site Recovery’s replication limits.
What has changed
Data churn is the rate at which information is written to a virtual machine’s disks while Site Recovery replicates it to another Azure region. Normal Churn supports up to 54 MB/s per VM. High Churn previously supported up to 100 MB/s, but qualifying configurations can now reach 500 MB/s.
You can review the technical requirements in Microsoft’s High Churn documentation.
| Configuration | Maximum churn per VM | Key requirements |
|---|---|---|
| Normal Churn | 54 MB/s | Default option using Standard cache storage |
| High Churn with less than 32 GB RAM | 54 MB/s | High Churn selected, but memory limits throughput |
| High Churn with 32 GB to under 256 GB RAM | 100 MB/s | At least 32 GB RAM recommended |
| High Churn with at least 256 GB RAM | Up to 500 MB/s | Supported regions, eligible disks and current Mobility service |
The 500 MB/s level applies only to Azure-to-Azure disaster recovery. Source disks must be managed Premium SSD v1, Premium SSD v2 or Ultra Disks. Both the source and target must be in supported regions, which include UK South and UK West. The VM also needs Mobility service version 9.66.7640.1 or later. Per-disk limits still apply, so a VM does not automatically achieve 500 MB/s simply because it has sufficient RAM.
Does your disaster recovery plan need to change?
Not necessarily. If replication is healthy and your recovery point objective is being met, there may be no reason to alter the configuration. The change matters most where a workload regularly exceeded the earlier limit or was left outside the recovery plan because replication could not keep pace.
Month-end finance processing, major retail campaigns and continuously updated logistics systems can all create temporary write spikes. Review actual performance data rather than relying on the theoretical maximum. Clear recovery targets should sit at the centre of effective business continuity services in London.
What to check before relying on the higher limit
Confirm the VM’s RAM, source-disk types, disk sizes, operating system and source and target regions. Windows is supported, while churn above 100 MB/s on Linux is limited to RHEL 9, SLES 15 and Ubuntu 24.04.
Check that the Mobility service is current and that the VM has sufficient network bandwidth and CPU capacity. Microsoft states that Site Recovery can produce peak CPU usage of up to 18%. High Churn also requires Premium Block Blob cache storage and can increase storage and network costs.
Newly protected, eligible VMs receive the higher High Churn limit automatically. An existing VM already configured for High Churn may only need a Mobility service upgrade and a restart where advised. However, changing a protected VM from Normal Churn to High Churn requires replication to be disabled and enabled again.
Run a test failover and confirm that the achieved recovery point objective matches the business requirement. Microsoft recommends test failovers to validate replication and disaster recovery without disrupting ongoing replication or the production environment.
Replication is not a replacement for backing up your business data, and ransomware resilience also needs a tested cyber incident response process.
Your wider plan should include Microsoft 365 support and email security services where cloud applications and email hold business-critical information. A managed IT support in London team can help map dependencies, test recovery and identify systems that remain outside the plan.
Talk it through before you rely on it
Higher limits expand what Azure Site Recovery can protect, but they do not remove the need for capacity planning and testing. Northern Star can review your workloads, recovery objectives and current replication health, then determine whether the new limits materially improve your recovery approach.
