Why colleges and trusts end up here
Education IaaS estates tend to share a shape. There are a handful of servers that could not easily move to software as a service: a management information system or its reporting database, finance and HR applications, a print server, RADIUS for wireless authentication, file shares that never quite finished moving to SharePoint, and perhaps a curriculum application with an awkward licence server. For a trust, add the fact that these serve many schools, each with its own connection and its own idea of what counts as urgent.
The first move to Azure is often a single virtual network holding everything, with a VPN back to the main office. That is fine for a pilot. It becomes difficult as soon as you need to separate workloads, inspect traffic between them, give a supplier access to one system without the rest, or recover in another region. Hub-and-spoke solves the first three and gives you a clear structure to reproduce for the fourth.
This guide is about virtual machines. If a workload has a supported platform or SaaS route, that is usually a better long-term answer than making a VM resilient, and it is worth checking before you design recovery around it.
The hub, the spokes and what goes where
The hub is a virtual network holding shared services: the gateway back to your sites, a firewall to inspect and control traffic, Azure Bastion for administrative access without public IP addresses on VMs, shared DNS resolution and, if you keep them in Azure, domain controllers. The spokes are separate virtual networks peered to the hub, each holding a workload or a group of related workloads.
Peering is not transitive. A spoke peered to the hub cannot reach another spoke through the hub unless you route traffic there. The usual pattern is a route table on each spoke subnet that sends traffic to the firewall's private IP address, with firewall rules deciding what may talk to what. That gives you one place to see and control traffic between, say, the MIS spoke and anything web-facing. Spokes reach your sites through the hub's gateway by allowing gateway transit on the hub side of each peering and using the remote gateway on the spoke side.
How you divide spokes is a judgement call. Common divisions in education are by sensitivity, keeping systems that hold pupil or student data apart from those that do not; by supplier, so a third party can manage its system without seeing the rest; and by environment, keeping test away from production. Avoid one spoke per VM: the overhead is not worth it.
Azure Virtual WAN is a Microsoft-managed alternative to building the hub yourself and can suit trusts with many sites connecting by VPN. It changes how routing and the hub are managed, so compare the two against your site count and your team's skills rather than assuming either is the default.
- Hub: VPN or ExpressRoute gateway, firewall, Bastion, DNS resolution, and domain controllers if you prefer them there.
- Business systems spoke: finance, HR and related servers.
- Learner data spoke: MIS databases, reporting and integrations.
- Supplier spokes: one per supplier that needs administrative access to its own system.
- Non-production spoke: test and training copies, kept away from live data.
Address space and site connectivity
Plan IP addressing before you build anything. Peered networks cannot overlap, spokes that need to talk to each other through the firewall must not overlap, and none of them should overlap with the ranges used at your sites. In practice, give every network a unique range. Trusts that have grown by bringing in schools often find several sites using the same default private ranges, and that has to be resolved, or at least translated, before those sites can route to Azure.
Allocate a block for the primary region and a separate block of the same size for the secondary region, even if you build nothing there yet. Record the allocation in one place and make one person responsible for it.
For connectivity, a site-to-site VPN from the main site or data centre to the hub's VPN gateway is the usual starting point. Trusts with many schools should decide whether each school connects to the hub directly or reaches it through an existing wide area network or SD-WAN; the second is often simpler to run. ExpressRoute gives private connectivity with more predictable performance and suits larger colleges and trusts with significant traffic to Azure, but it takes longer to arrange through a provider. Either way, plan for the secondary hub to accept the same site connections, configured and tested in advance, because building tunnels during an incident is slow and error-prone.
Choosing a secondary region
Azure groups many regions into pairs, and for UK organisations the established pair has been UK South and UK West. Pairing affects some platform behaviour, such as where geo-redundant storage replicates to and how Microsoft sequences planned maintenance. Microsoft has also introduced regions without a pair and has changed how it describes pairing and availability zones, so confirm the current pairing, and what it means for the services you use, against current Microsoft documentation.
For VM recovery with Azure Site Recovery you choose the target region; you are not restricted to the pair. The paired UK region is still often the natural choice for education because it keeps data in the UK, which matters for your data protection position and for any commitments you have made about where pupil, student and staff data is held.
Do not assume the secondary region offers everything the primary does. Regions differ in VM sizes, services, availability zones and capacity. Check that the sizes you use are available in the target region, and check any platform dependencies, such as database services, storage options or firewall SKUs, before writing recovery into a plan.
Availability zones are a separate decision. They protect against the failure of a data centre within a region, not the loss of a region. Where your region offers them, spreading critical VMs across zones reduces how often you would need to invoke recovery, but it does not replace a second region.
Replicating workloads with Azure Site Recovery
Azure Site Recovery replicates Azure VMs continuously to a target region and keeps recovery points you can fail over to. You enable it per VM, choosing the target resource group, virtual network and replication policy. VMs that must recover together go into a recovery plan, which controls the order they start in and can run scripts or pause for manual steps between groups.
Order matters. A typical plan for an education estate first confirms domain controllers in the secondary region are reachable, then starts database servers, then application servers, then anything users connect to. Put a manual step after the database group so someone checks the databases have come up consistently before applications connect to them.
Decide the target network design before you enable replication. One option uses the same address ranges in the secondary region, so VMs keep their IP addresses on failover and nothing that references an address breaks. The cost is that the secondary network cannot be connected to the primary or to your sites at the same time, so it sits disconnected until you fail over. The other option uses different ranges, which allows a live, connected secondary hub and makes testing easier, at the cost of updating DNS and any hard-coded addresses at failover. The second is usually the better fit, provided applications are reached by name rather than address. Check that before choosing.
Site Recovery is not backup. It replicates corruption and ransomware as faithfully as good data, within the recovery points you keep. Keep Azure Backup running alongside it, with cross-region restore configured on the vault if you want to restore backups in the secondary region, and protect the vault with soft delete and immutability settings that match your risk.
- Agree recovery time and recovery point objectives per system with its owner, not per server.
- Group VMs into recovery plans by application and order them by dependency.
- Choose target VM sizes deliberately; a smaller size may be acceptable for a short recovery period.
- Exclude disks that hold only temporary or rebuildable data from replication.
Identity, DNS and the services recovery depends on
Most recovery tests fail on dependencies rather than on the VMs themselves. Work through them explicitly and write the answers into the runbook.
Build the secondary hub with infrastructure as code, using Bicep or Terraform, from the same templates as the primary. Whether you deploy it fully in advance or keep it ready to deploy is a cost and recovery time decision. Gateways and firewalls take time to provision, so a hub that exists only as a template lengthens your recovery and adds steps to the worst day of the year.
- Run at least one domain controller permanently in the secondary region rather than replicating domain controllers with Site Recovery, so it stays current through normal directory replication.
- Make sure the secondary region can resolve internal names without the primary, and link any Azure Private DNS zones to the secondary networks in advance.
- Apply the same firewall policy to the secondary hub through code, so rules do not drift between regions.
- Check that licence servers tolerate a change of host or address, and that certificates cover any names that change.
- Know where your Microsoft Entra synchronisation runs and how it recovers; Entra ID is a global service, but your sync server or agent is not.
- Confirm how suppliers and remote staff reach systems after failover, including any allow lists on their side.
Testing within the academic calendar
Site Recovery supports test failover into an isolated virtual network without interrupting replication. Use it. A recovery plan that has never been tested is a hypothesis.
Fit testing to the year. Avoid exam periods, enrolment, census returns, results days and the start of term, when MIS and finance systems are busiest and change freezes usually apply. Holidays are the natural window, but they are also when every other infrastructure project lands, so book recovery testing as a fixed event in the IT calendar rather than squeezing it in around other work.
Test with the people who use the systems. A test that brings up VMs but where nobody logs in to the MIS proves only that VMs start. Ask a data manager and a finance officer to carry out a few real tasks in the isolated environment, read-only where possible, and record what worked and what did not.
Update the runbook straight after each test, then run a smaller test the following holiday to prove the fixes. Agree with governors or trustees how often a full failover and failback test should happen, and report the results to them.
Writing the runbook
The runbook is the document someone will follow under pressure, possibly at night and possibly without the person who designed the system. Write it for that reader. Keep it outside the systems it describes, so it is available when they are not, and keep a copy somewhere the deputy can reach without a working network login.
Each recovery plan in Site Recovery should map to a section of the runbook, in the same order, with the manual checks spelled out rather than implied. Where a step depends on a supplier, record how to reach them out of hours and what they need from you.
Review the runbook after every test, every significant change to the estate and every change of key staff. A runbook that names someone who left last year is a warning sign about the rest of it.
- State who can invoke recovery and how that decision is recorded.
- List the systems in recovery order, with the owner and the check that proves each one is working.
- Include the DNS, firewall and connectivity changes needed at failover, with the exact records and rules.
- Describe how staff, schools, parents and learners are told, and who sends each message.
- Set out the failback steps and the checks before and after, not only the failover.
Ownership and governance
Use management groups, Azure Policy and separate subscriptions to keep the hub, spokes and recovery resources governed consistently. Policies that restrict deployments to your chosen UK regions, require owner and system tags, and enforce diagnostic settings help avoid surprises. Send replication health alerts to a shared mailbox or ticket queue rather than to one person.
Define what invoking recovery means in practice: who can decide, how staff and schools are told, and how you fail back once the primary region is healthy. Failback is the step most often left unplanned, and it is when data written during the failover period is most at risk. Ownership should be written as roles.
- The executive team, usually through the relevant board or trust committee, owns risk appetite and approves recovery targets.
- System owners for MIS, finance and HR agree the targets for their systems and take part in tests.
- The IT lead owns the design, the runbook and the test schedule, and decides when to invoke recovery during an incident.
- The platform team or Azure partner maintains the templates, replication health and alerting.