How to Prepare Your Network for Cloud Migration

Moving to the cloud is one of the most significant infrastructure decisions a UK business can make — but the success of that migration depends almost entirely on something most organisations overlook until it’s too late: the network underneath it. Cloud platforms like Microsoft Azure, Amazon Web Services (AWS), and Google Cloud are only as fast, reliable, and secure as the network connection between your users and those platforms.

Too many businesses rush into cloud migration with a solid strategy for applications and data, but no plan whatsoever for the network that has to carry all of it. The result? Sluggish performance, dropped video calls, applications that time out during peak hours, and frustrated staff who wonder why the expensive new “cloud solution” is slower than the old on-premises server sitting under someone’s desk.

This guide walks you through every aspect of preparing your network for cloud migration — from assessing your current infrastructure and calculating real bandwidth requirements, to implementing SD-WAN, optimising DNS, and avoiding the pitfalls that catch out even experienced IT teams. Whether you’re a 20-person professional services firm or a multi-site enterprise, the principles are the same: get the network right first, and everything else follows.

Why Network Readiness Is the Foundation of Cloud Success

When your applications and data lived on-premises, network traffic stayed largely within your building. File access, database queries, email, and line-of-business applications all ran over your local area network (LAN) at gigabit speeds with sub-millisecond latency. Your internet connection was mainly used for web browsing, email delivery, and the occasional software update.

Cloud migration fundamentally changes that equation. Suddenly, every interaction with every application — opening a document, saving a spreadsheet, querying a database, loading a dashboard — travels across your internet connection to a data centre that could be in London, Dublin, Amsterdam, or Frankfurt. Your WAN (wide area network) becomes the backbone of your entire IT operation, not just an auxiliary connection for internet access.

This shift means that network issues which were previously minor inconveniences — a brief slowdown during lunch hour, occasional packet loss, a router that needs rebooting every few weeks — become business-critical failures that affect every user, every application, and every transaction.

The Real-World Impact of Poor Network Preparation

We’ve seen the consequences of inadequate network preparation play out dozens of times across UK businesses. Here are the patterns that repeat:

• Microsoft 365 performance degrades at peak hours — Teams calls drop, SharePoint is sluggish, Outlook takes 10 seconds to open emails. The root cause is bandwidth saturation on an inadequate internet connection that was never designed to carry the entire organisation’s workload.
• Cloud-hosted ERP or CRM feels painfully slow — Staff who were used to instant responses from an on-premises server now wait 3–5 seconds for every screen to load. The application works perfectly — the network can’t deliver it fast enough.
• VoIP and video conferencing become unreliable — Jitter and packet loss on an overloaded connection cause garbled audio, frozen video, and disconnected calls — exactly when professional communication matters most.
• Backup and replication windows are missed — Cloud backup jobs that were estimated to take 2 hours actually take 14, running into business hours and competing with user traffic.
• Remote and branch office users suffer disproportionately — If your network design routes branch traffic through headquarters before reaching the cloud, remote users experience double the latency and half the throughput.

Every one of these problems is preventable with proper network preparation. Let’s work through how to do it properly.

Step 1: Conduct a Thorough Network Assessment

Before you can prepare your network for the cloud, you need to understand exactly what you’re working with today. A proper network assessment isn’t a quick glance at your router’s admin page — it’s a systematic evaluation of every component that will carry cloud traffic.

What to Assess

Component	What to Measure	Why It Matters
Internet Connection(s)	Contracted speed, actual throughput, contention ratio, uptime history	Determines raw capacity available for cloud traffic
Firewall / Router	Throughput capacity, concurrent sessions, CPU/memory utilisation	Bottleneck if undersized for encrypted cloud traffic
LAN Switches	Port speeds, uplink capacity, VLAN configuration, QoS support	Internal bottlenecks can throttle cloud-bound traffic
Wi-Fi Infrastructure	Access point density, channel utilisation, client capacity, standards (Wi-Fi 5/6/6E)	Wireless users are often the most cloud-dependent
WAN Links (multi-site)	MPLS/VPN bandwidth, latency between sites, failover capabilities	Branch offices need direct or optimised cloud paths
DNS Infrastructure	Resolver configuration, internal zones, TTL settings, DNSSEC status	Misconfigured DNS is the silent killer of cloud performance
Current Traffic Patterns	Peak utilisation, traffic breakdown by application/protocol, burst patterns	Baseline data for capacity planning

Establishing a Baseline

You cannot plan capacity without baseline data. Run monitoring tools for a minimum of two full business weeks — ideally a month — to capture normal usage patterns, peak periods, and anomalies. Tools like PRTG Network Monitor, Zabbix, or even the built-in monitoring on your firewall can provide this data.

Pay particular attention to:

• Peak bandwidth utilisation — What percentage of your internet connection is used during the busiest periods? If you’re already above 70% during peaks, you need more capacity before adding cloud workloads.
• Latency to cloud endpoints — Run continuous ping and traceroute tests to the Azure, AWS, or Google Cloud regions you’ll be using. Latency above 30ms to a UK-based cloud region indicates a routing or connectivity issue worth investigating.
• Packet loss — Even 0.5% packet loss causes noticeable degradation in real-time applications. Anything above 0.1% needs addressing before cloud migration.
• Jitter — Variation in latency over time. Critical for voice and video. Jitter above 15ms will cause quality issues on Teams, Zoom, and VoIP calls.

Step 2: Calculate Your Real Bandwidth Requirements

One of the most common mistakes in cloud migration planning is underestimating bandwidth requirements. Businesses look at their current internet usage, add a bit of headroom, and assume it will be enough. It almost never is, because they forget that workloads moving to the cloud generate net new traffic on the internet connection that previously stayed on the LAN.

Bandwidth Consumption by Cloud Service

Here’s a realistic breakdown of bandwidth consumption for common cloud services, per user, during active use:

The Bandwidth Planning Formula

A practical approach for UK businesses is to calculate bandwidth in tiers:

• Tier 1 – Minimum viable: Sum the per-user requirements for your cloud services, multiply by the number of concurrent users (typically 60–80% of total staff), and add 30% headroom. This keeps you functional but leaves little room for growth or burst traffic.
• Tier 2 – Comfortable operation: The Tier 1 figure plus 50% headroom, plus dedicated capacity for backup and replication traffic. This is where most businesses should aim.
• Tier 3 – Future-proofed: Double the Tier 2 figure. This sounds excessive, but cloud usage grows consistently at 20–30% year-on-year as businesses adopt more cloud services and increase usage of existing ones.

Example: A 50-person professional services firm moving to Microsoft 365 with Teams, a cloud-hosted practice management system, and cloud backup might calculate: 50 users × 60% concurrency × (2.0 + 2.5 + 4.0 Mbps) = 255 Mbps at peak. Add 50% headroom for Tier 2: approximately 380 Mbps. Add dedicated backup capacity of 50 Mbps: approximately 430 Mbps total. A 500 Mbps dedicated internet connection would be the sensible choice, with a 1 Gbps upgrade path available.

Step 3: Upgrade Your Internet Connectivity

With bandwidth requirements calculated, you need to ensure your internet connectivity can deliver. For UK businesses, the connectivity landscape has improved dramatically in recent years, but choosing the right product matters enormously.

For any business migrating core workloads to the cloud, dedicated internet access (DIA) is the correct choice. The guaranteed, symmetric bandwidth and enterprise-grade SLA are essential when your internet connection is no longer just for web browsing but is the primary path to every application your business depends on.

The key distinction is contention. Business broadband shares capacity with other customers in your area. During peak hours (9:00–11:00 and 14:00–16:00 are typical), your actual throughput can drop to a fraction of the headline speed. A leased line delivers exactly the speed you pay for, 24 hours a day, 365 days a year.

Don’t Forget Upload Speed

This is a critical point that catches many UK businesses off guard. Most broadband connections are asymmetric — download speed is much higher than upload. A “900 Mbps” FTTP connection might only offer 100 Mbps upload. For cloud workloads, upload matters just as much as download: every file you save to SharePoint, every email you send, every database record you update, every backup you run — it all travels upstream. A leased line is symmetric by design, giving you equal capacity in both directions.

Resilience: The Case for Dual Connectivity

When your internet connection is your lifeline to the cloud, a single point of failure is unacceptable. Best practice for cloud-dependent businesses is to maintain two independent internet connections from different providers, ideally using different last-mile technologies (for example, a fibre leased line as primary and a 4G/5G mobile broadband connection as failover). Your firewall or SD-WAN appliance can automatically switch between them if the primary fails.

For UK businesses, the cost of a secondary 4G/5G failover connection is typically £30–£80/month — a trivial amount compared to the cost of a full outage when your only connection goes down and nobody can work.

Step 4: Implement Quality of Service (QoS)

Even with adequate bandwidth, not all traffic is created equal. A large file download and a live video call might both use the same internet connection, but their requirements are completely different. QoS policies ensure that time-sensitive traffic — voice, video, and interactive applications — gets priority over bulk transfers and background processes.

Traffic Prioritisation for Cloud Environments

A well-designed QoS policy for cloud migration typically follows this hierarchy:

QoS is typically configured on your firewall, SD-WAN appliance, or managed router. Modern next-generation firewalls from vendors like Fortinet, Palo Alto, and SonicWall all include application-aware QoS that can identify cloud traffic by application rather than just port number — essential since most cloud traffic runs over HTTPS (port 443).

Step 5: Consider SD-WAN for Cloud Optimisation

Software-Defined Wide Area Networking (SD-WAN) has become one of the most important technologies for businesses migrating to the cloud, and for good reason. Traditional network architectures were designed for a world where traffic flowed between offices and a central data centre. Cloud migration creates a fundamentally different traffic pattern that traditional networks handle poorly.

What SD-WAN Does for Cloud Migration

SD-WAN provides several capabilities that are specifically valuable during and after cloud migration:

• Intelligent traffic routing — SD-WAN automatically routes cloud traffic over the best available path based on real-time performance metrics (latency, jitter, packet loss). If your primary connection degrades, it shifts critical traffic to the secondary connection seamlessly.
• Direct cloud breakout — Instead of routing all branch office traffic through headquarters (backhauling), SD-WAN allows branch sites to access cloud services directly over their local internet connection. This reduces latency dramatically for branch users.
• Application-aware prioritisation — SD-WAN identifies applications at a deep level and applies QoS policies based on business priority, not just IP addresses or port numbers.
• Link aggregation — SD-WAN can bond multiple internet connections together, using the combined bandwidth of a leased line and a broadband connection simultaneously rather than keeping one as a cold standby.
• Centralised management — Network policies for all sites are managed from a single console, dramatically simplifying multi-site cloud migration.

SD-WAN Solutions for UK Businesses

Solution	Best For	Typical Cost (per site/month)	Key Strength
Fortinet SD-WAN	Businesses with Fortinet firewalls	£50–£150	Integrated security + SD-WAN in one appliance
Cisco Meraki SD-WAN	Multi-site with cloud management	£80–£200	Intuitive cloud dashboard, zero-touch deployment
VMware VeloCloud	Large enterprises, complex topologies	£100–£300	Deep cloud integration, extensive partner ecosystem
Cato Networks	Cloud-first businesses, SASE convergence	£120–£250	Full SASE platform with built-in security stack
Draytek (Budget SD-WAN)	Small offices, cost-sensitive deployments	£10–£30 (hardware-only, self-managed)	Low cost, basic SD-WAN features, popular in UK SME market

For multi-site UK businesses, SD-WAN is no longer a luxury — it’s a prerequisite for a successful cloud migration. The ability to route traffic intelligently, provide automatic failover, and give branch offices direct cloud access solves the majority of performance issues that plague traditional hub-and-spoke network designs.

Step 6: Prepare Your DNS for the Cloud

DNS is one of the most overlooked aspects of cloud migration, yet it plays a crucial role in routing users to the correct cloud endpoints, ensuring email deliverability, and maintaining access to internal and external resources during the transition.

Key DNS Changes for Cloud Migration

• Lower TTL values in advance — At least 48 hours before any DNS cutover, reduce the TTL on affected records to 300 seconds (5 minutes). This ensures that when you change records to point at cloud services, the old cached values expire quickly across all resolvers worldwide.
• Update MX records for email migration — Moving to Microsoft 365 or Google Workspace requires changing your MX records to point to the new mail platform. This is one of the most critical DNS changes — get it wrong and email stops flowing.
• Add SPF, DKIM, and DMARC records — Cloud email platforms require properly configured email authentication DNS records. Missing or incorrect SPF/DKIM/DMARC records will cause your emails to be rejected or flagged as spam by recipients.
• Configure split-horizon DNS — If you’re running a hybrid environment (some services on-premises, some in the cloud), you may need internal DNS to resolve certain domains differently from external DNS.
• Update CNAME and A records for migrated services — Any public-facing service moving to the cloud (websites, customer portals, APIs) needs its DNS records updated to point at the new cloud endpoints.
• Autodiscover and SRV records — Microsoft 365 relies on specific DNS records (autodiscover CNAME, SRV records for Skype for Business/Teams federation) that must be created for full functionality.

Step 7: Strengthen Your Network Security Posture

Cloud migration changes your security perimeter. In the traditional model, your firewall protected a clearly defined boundary between your internal network and the internet. With cloud services, that boundary dissolves: your data is everywhere, your users connect from everywhere, and your applications live in someone else’s data centre.

Network Security Measures for Cloud Readiness

• Next-generation firewall (NGFW) — Your firewall must be capable of deep packet inspection, application-level filtering, and SSL/TLS decryption. Many cloud applications use encrypted HTTPS traffic that a basic firewall cannot inspect. Ensure your firewall can handle the throughput of inspecting encrypted traffic without becoming a bottleneck.
• DNS filtering — Implement DNS-level security filtering to block access to known malicious domains, phishing sites, and command-and-control servers. This provides a layer of protection that works regardless of whether users are in the office or working remotely.
• Zero Trust Network Access (ZTNA) — The traditional VPN model — connect to the office network, then access everything — is being replaced by ZTNA, where users authenticate to specific applications rather than the network. This is particularly important for cloud-first environments where the concept of a “trusted internal network” becomes meaningless.
• Encrypted DNS (DoT/DoH) — Configure encrypted DNS resolution at the network level to prevent DNS snooping and manipulation. This is increasingly important as more traffic flows across the public internet to cloud services.
• Network segmentation — Separate cloud-bound traffic from internal LAN traffic using VLANs and firewall policies. This limits the blast radius of a security incident and allows you to apply different policies to different traffic types.
• Cloud access security broker (CASB) — For businesses using multiple SaaS applications, a CASB provides visibility and control over data flowing to and from cloud services, including shadow IT detection.

Step 8: Plan for the Transition Period

Most cloud migrations don’t happen overnight. You’ll likely run in a hybrid state for weeks or months, with some workloads on-premises and others in the cloud. This transition period places unique demands on your network because you’re simultaneously running two environments and synchronising data between them.

Hybrid Period Network Considerations

• Data synchronisation bandwidth — If you’re migrating data to the cloud in phases (which you should be), the synchronisation traffic runs alongside normal business traffic. Schedule large data transfers for off-peak hours and use QoS to protect interactive traffic.
• VPN or ExpressRoute for hybrid connectivity — If on-premises servers need to communicate with cloud-hosted services (for example, a hybrid Active Directory setup or a database that’s been partially migrated), you need a reliable, low-latency connection between your office and the cloud region. Site-to-site VPN works for smaller deployments; Azure ExpressRoute or AWS Direct Connect provides dedicated, private connectivity for larger or latency-sensitive workloads.
• Rollback connectivity — Plan for the possibility that a migration phase needs to be rolled back. Ensure your network can revert to the pre-migration configuration quickly, including DNS changes, firewall rules, and routing policies.
• User communication — Inform staff about expected changes and potential brief disruptions during migration windows. Nothing erodes confidence in a cloud project faster than unexplained outages that nobody warned anyone about.

Step 9: Test, Validate, and Optimise

Before going live with migrated cloud workloads, conduct thorough network testing to validate that everything performs as expected under realistic load conditions.

Pre-Migration Testing Checklist

Test	Tool / Method	Acceptable Result
Bandwidth throughput to cloud region	iPerf3, cloud provider speed tests	≥90% of contracted line speed
Latency to primary cloud endpoints	Continuous ping, traceroute, Azure/AWS latency tools	<20ms to UK cloud regions
Packet loss under load	Load generation + packet capture	<0.1% sustained
Jitter measurement	Continuous ping analysis, VoIP quality tools	<10ms for voice/video quality
Failover / resilience testing	Disconnect primary link, verify automatic failover	Failover within 30 seconds, no session drops
QoS validation	Saturate connection, verify priority traffic unaffected	Voice/video quality maintained at 100% utilisation
DNS resolution to cloud services	nslookup/dig to verify correct endpoints	All cloud service FQDNs resolve correctly
VPN/ExpressRoute connectivity	End-to-end application testing through tunnel	Full application functionality, acceptable latency

Pilot Phase

Before migrating the entire organisation, run a pilot with a small group of users (10–20 people across different departments and roles) for at least one full business week. This pilot group should use the cloud services under real working conditions while you monitor network performance intensively. Their feedback and the performance data you collect will reveal issues that lab testing cannot replicate.

Common issues discovered during pilot phases include:

• Firewall rules blocking specific cloud service endpoints
• SSL inspection breaking certificate pinning on certain cloud applications
• Wi-Fi capacity insufficient for the increased per-user bandwidth demands
• Proxy servers adding unacceptable latency to cloud traffic
• Split DNS not correctly resolving hybrid-environment resources

Step 10: Common Pitfalls and How to Avoid Them

After guiding hundreds of UK businesses through cloud migration, we’ve compiled the network-related pitfalls that consistently trip up even well-prepared organisations:

Pitfall	Why It Happens	How to Avoid It
Underestimating bandwidth needs	Planning based on current usage without accounting for workloads moving from LAN to WAN	Calculate net new traffic from migrated workloads and add 50% headroom
Ignoring upload speed	Asymmetric broadband has fast download but slow upload; cloud needs both directions equally	Use symmetric dedicated internet access (leased line)
No failover connectivity	Single internet connection seemed fine when it was just for browsing	Deploy secondary connection (4G/5G or second ISP) with automatic failover
Backhauling branch traffic	Traditional hub-and-spoke design routes all branch traffic through HQ	Implement SD-WAN with direct cloud breakout at branch sites
Firewall becomes a bottleneck	Old firewall can’t handle encrypted cloud traffic at line speed	Verify firewall throughput with SSL inspection enabled; upgrade if needed
DNS misconfiguration during cutover	DNS changes made without lowering TTLs in advance; incorrect MX records break email	Maintain a DNS change register; lower TTLs 48 hours before changes
Skipping the pilot phase	Pressure to “just go live” and sort out issues afterwards	Always pilot with 10–20 users for at least one week before full migration
Forgetting about Wi-Fi	LAN switches are fast but wireless infrastructure is outdated or underpowered	Audit Wi-Fi capacity and upgrade to Wi-Fi 6/6E if needed

Building a Network Migration Timeline

Network preparation shouldn’t happen at the last minute. Here’s a realistic timeline for UK businesses planning a cloud migration:

• 6 months before migration: Conduct the full network assessment. Identify gaps in bandwidth, resilience, and security. Order any new connectivity (leased line lead times in the UK can be 30–90 days depending on location and provider).
• 4 months before: Deploy new connectivity and network equipment. Install and configure SD-WAN if applicable. Implement QoS policies. Upgrade Wi-Fi infrastructure if required.
• 3 months before: Begin network monitoring with baseline measurements. Configure DNS changes in a staging environment. Set up VPN or ExpressRoute connectivity to cloud environments.
• 2 months before: Run load testing to validate bandwidth and latency under simulated cloud workloads. Test failover scenarios. Validate QoS under congestion.
• 1 month before: Begin pilot migration with a small user group. Monitor intensively. Resolve any network issues discovered.
• Migration week: Lower DNS TTLs. Execute DNS changes according to the change register. Monitor continuously. Have rollback plans ready for every phase.
• 1 month after: Review performance data. Optimise QoS policies based on actual traffic patterns. Raise DNS TTLs to normal values. Address any lingering performance issues.

The Cost of Getting It Right (and the Cost of Getting It Wrong)

Network preparation for cloud migration requires investment, but it’s a fraction of the cost of a failed migration or years of poor performance. Here’s a realistic cost perspective for a typical 50-person UK business:

Compare those figures to the cost of getting it wrong: lost productivity from slow cloud applications (£200–£500 per employee per month in reduced efficiency), the direct cost of rolling back a failed migration (£20,000–£80,000 in consulting, licensing, and staff time), and the reputational damage of IT projects that visibly fail.

Proper network preparation is not an optional extra — it is the foundation upon which every other aspect of your cloud migration depends. Cut corners here, and you’ll pay for it many times over in the months and years that follow.

Wrapping Up: Your Network Is the Cloud’s Front Door

Cloud migration is one of the most impactful technology investments a UK business can make, but its success is determined not by the cloud platform you choose, the applications you migrate, or the data you move — it’s determined by the network that connects it all together.

A well-prepared network delivers a cloud experience that genuinely transforms how your team works: applications are fast, video calls are crisp, files are instantly accessible, and the technology simply fades into the background. A poorly prepared network delivers the opposite: a frustrating, sluggish experience that makes staff long for the old server under the desk.

The ten steps in this guide — assessment, bandwidth planning, connectivity upgrades, QoS, SD-WAN, DNS preparation, security hardening, hybrid planning, testing, and avoiding common pitfalls — are the blueprint that consistently delivers successful outcomes for the UK businesses we work with. Follow them methodically, invest appropriately, and your cloud migration will be built on a foundation that performs from day one.