SD-WAN & Azure ExpressRoute Delivers 99.99% Uptime for Multi-Site Manufacturer

A UK precision manufacturing group operating five factories across England and Wales was running a fragmented, unreliable network that was costing them £2.1 million per year in lost production. Each factory had been connected to head office and the internet via a different ISP, using different networking equipment, with no redundancy, no centralised management, and no consistent security policies. When any single link went down — which happened on average twice per month per site — the factory's ERP system, quality control database, and production scheduling tools all went offline, halting the production line until connectivity was restored.

The firm's previous IT provider had proposed a traditional MPLS network — a private WAN connecting all sites with guaranteed bandwidth and SLA. The quote was £186,000 per year for a 3-year contract, with a 12-week deployment timeline and the requirement that all sites use the same ISP. The manufacturing group's operations director rejected this proposal: it was too expensive, too slow to deploy, and too inflexible for a business that was actively evaluating a sixth factory acquisition and needed the ability to onboard new sites in days, not months.

They came to us with a clear set of requirements: connect all five factories to head office and Azure with sub-30ms latency, achieve 99.99% uptime (no more than 52 minutes of downtime per year per site), enable rapid onboarding of new sites, reduce annual network costs by at least 40% versus the MPLS quote, and maintain the ability to run production systems even during a primary link failure. They also needed Quality of Service (QoS) to prioritise production traffic over general internet traffic, and they needed centralised visibility of the entire network from a single dashboard.

We designed a hybrid network architecture combining SD-WAN (Software-Defined Wide Area Network) for site-to-site connectivity with Azure ExpressRoute for dedicated, private connectivity to Azure. The architecture addressed every requirement while reducing annual network costs by 58% compared to the MPLS quote. The design had three layers: the underlay (physical internet connections), the SD-WAN overlay (encrypted tunnels between sites), and the Azure connectivity layer (ExpressRoute for production traffic, internet for general traffic).

At the underlay layer, each site retained its existing internet connection but we added a second connection from a different ISP for redundancy. This dual-ISP approach meant that a single ISP outage would not take a site offline — the SD-WAN would automatically failover to the secondary connection within 3 seconds, fast enough that TCP sessions (including ERP database connections) would not drop. We selected ISPs with diverse physical routing — meaning the two connections at each site entered the building from different exchanges and used different street-level infrastructure — to eliminate the risk of a single physical cable cut affecting both connections.

The SD-WAN overlay was built on VMware VeloCloud edge appliances at each site, managed from a centralised orchestrator. The SD-WAN created encrypted IPSec tunnels between all sites over both internet connections, continuously monitoring latency, jitter, and packet loss on each path. When the SD-WAN detected degradation on the primary path, it dynamically steered traffic to the best-performing alternative — not just failing over when a link went down, but proactively avoiding paths that were experiencing congestion or latency spikes. This dynamic path selection was critical for the production environment, where even brief latency spikes could cause the ERP system to time out and disrupt production scheduling.

For Azure connectivity, we provisioned an ExpressRoute circuit through a UK ExpressRoute provider, with peering at two London data centres for redundancy. ExpressRoute provided a private, dedicated connection to Azure that did not traverse the public internet — meaning it was not subject to internet congestion, DDoS attacks, or ISP routing issues. The firm's production ERP, quality control database, and file shares were all hosted in Azure, and ExpressRoute gave them consistent, low-latency access with a contractual SLA of 99.95% on the ExpressRoute circuit itself. Combined with the SD-WAN's 99.99% site-level uptime, the end-to-end SLA for production systems exceeded the firm's 99.99% requirement.

The firm's network carried three classes of traffic with very different requirements. Production traffic — ERP database queries, quality control data, production scheduling, and SCADA telemetry — required sub-30ms latency, near-zero jitter, and guaranteed bandwidth. Business traffic — email, file shares, Teams calls, and web browsing — required reasonable performance but could tolerate occasional congestion. And recreational traffic — streaming video, social media, and personal browsing — needed to be allowed but strictly deprioritised, especially during production hours.

We implemented a three-tier QoS model across the SD-WAN. Production traffic was tagged with DSCP EF (Expedited Forwarding) at the source — the ERP application servers, SCADA gateways, and quality control systems all tagged their own traffic — and the SD-WAN guaranteed a minimum bandwidth allocation of 60% of each link's capacity for EF-tagged traffic. During congestion, EF traffic was never dropped or delayed; instead, the SD-WAN queued lower-priority traffic or steered it to the secondary link. Business traffic was tagged with DSCP AF41 (Assured Forwarding) and given a 30% minimum bandwidth guarantee, while recreational traffic was tagged with DSCP DF (Default Forwarding) and given whatever bandwidth remained.

The QoS model was enforced at every hop — the SD-WAN edge, the Azure ExpressRoute gateway, and the Azure virtual network — ensuring that priority markings were respected end-to-end. We also implemented application-aware routing: the SD-WAN identified traffic by application (not just port number) and could make routing decisions based on the application. For example, Teams video calls were automatically routed over the path with the lowest jitter, while large file transfers were routed over the path with the highest available bandwidth, even if that path had slightly higher latency. This application-aware routing was configured via the central orchestrator and applied consistently across all sites.

The result was that even when a site's primary internet connection was saturated by a large file download or a streaming video, production traffic continued to flow with sub-30ms latency because the QoS model guaranteed its bandwidth. Before the SD-WAN deployment, a saturated link would cause ERP timeouts and production delays; after deployment, production traffic was completely insulated from bandwidth contention.

The previous network had no segmentation — every device at every site could reach every other device, meaning a compromise at one factory could spread to all five. The firm's operations director was particularly concerned about this after a ransomware attack at a competitor's factory had spread from a compromised workstation to the SCADA network, halting production for two weeks. We designed a zero-trust network segmentation model that isolated each factory's OT (Operational Technology) network from its IT network, and isolated each factory from the others.

At each site, we created two VLANs: an IT VLAN for office computers, printers, and VoIP phones, and an OT VLAN for production systems, SCADA gateways, PLCs, and quality control equipment. The SD-WAN edge enforced strict firewall rules between the VLANs: the IT VLAN could access the internet and Azure, but could not initiate connections to the OT VLAN. The OT VLAN could access only the specific Azure services it needed (the ERP database and quality control system) on specific ports, and could not access the internet at all. This segmentation meant that even if a workstation in the IT VLAN was compromised, the attacker could not reach the production systems.

Inter-site traffic was similarly segmented. Each factory's OT VLAN could communicate only with the Azure-hosted production systems, not with other factories' OT VLANs. This was enforced by the SD-WAN orchestrator's centralised firewall policy, which was applied to every edge appliance and could not be overridden locally. If a factory needed to share data with another factory (for example, transferring quality control reports), it did so through the Azure-hosted file shares, not through direct inter-site connectivity. This hub-and-spoke model, with Azure as the hub, gave us complete visibility and control over inter-site traffic.

We also deployed Azure Firewall in the hub virtual network, inspecting all traffic between sites and Azure with full Layer 7 application-level filtering. Azure Firewall's threat intelligence integration blocked known malicious IP addresses and domains automatically, and we configured custom rules to block non-production traffic from the OT VLANs. All firewall traffic was logged to Azure Log Analytics, giving the firm's IT team a centralised view of all network traffic across all sites — something that had been impossible with the previous fragmented network.

Deploying new network infrastructure across five active factories without disrupting production required meticulous planning. We designed a phased rollout where each factory was migrated independently, with a rollback plan at every stage. The deployment sequence was: head office first (as the SD-WAN orchestrator hub), then the smallest factory (as a pilot), then the remaining factories in order of production criticality, with the most complex factory (which ran 24/7 production) last.

At each site, the deployment followed the same process. First, we installed the new SD-WAN edge and secondary ISP connection alongside the existing network, without touching the production network. We configured the SD-WAN edge and verified that it could reach head office and Azure via the new connections. Then, during a scheduled maintenance window (Saturday night for most sites, a planned production stop for the 24/7 factory), we migrated traffic from the old network to the SD-WAN by changing the default gateway on the core switch. The migration took less than 30 minutes per site, and we had a rollback procedure (reverting the default gateway) that could be executed in under 5 minutes if any issue was detected.

The 24/7 factory required special handling. We could not schedule a production stop, so we designed a hitless migration. We configured the SD-WAN edge with the same VLAN IDs and IP subnets as the existing network, then used a technique called ARP poisoning (gratuitous ARP) to seamlessly transfer traffic from the old gateway to the new SD-WAN edge without any session drops. The migration was transparent to production systems — the ERP database connections, SCADA telemetry, and quality control data streams all continued without interruption. The entire migration took 12 minutes, and no production system was aware that the network had changed.

Post-deployment, we ran a 2-week parallel period at each site where the old network remained in place as a backup. During this period, we monitored the SD-WAN's performance, verified that all production traffic was flowing correctly, and confirmed that failover between the two ISP connections worked as designed. We simulated a primary link failure at each site by physically disconnecting the primary ISP cable during a low-production period and verified that traffic failed over to the secondary connection within 3 seconds with no session drops. Only after this verification was the old network decommissioned.

The new network was fully operational across all five factories within 8 weeks — compared to the 12-week timeline quoted for MPLS. Annual network costs were £78,000, a 58% reduction from the £186,000 MPLS quote and a 41% reduction from the firm's previous fragmented network spend of £132,000. The cost savings came from replacing expensive site-to-site leased lines with commodity internet connections, leveraging the SD-WAN's intelligent routing to achieve MPLS-equivalent performance over cheaper connectivity, and consolidating network management onto a single platform.

Uptime exceeded the 99.99% target. In the 12 months following deployment, the firm experienced a total of 23 minutes of network-related downtime across all five sites — well within the 52-minute annual budget. Three ISP outages occurred during the year, and in every case, the SD-WAN failed over to the secondary connection within 3 seconds with no production impact. The firm's operations director, who had been sceptical that commodity internet connections could deliver production-grade reliability, became the architecture's biggest advocate.

Production latency to the Azure-hosted ERP system averaged 8ms from all sites — well under the 30ms target — and the QoS model ensured that production traffic was never affected by bandwidth contention. The firm's IT team, who previously spent significant time troubleshooting network issues across five different ISP portals and three different equipment vendors, now had a single dashboard showing the health of the entire network. When a sixth factory was acquired 4 months after deployment, it was connected to the network in 3 days — a process that would have taken weeks under the old model.