Why Migrate to the Cloud?
Cloud computing has moved from an emerging technology to the default infrastructure model for organisations of all sizes. According to industry research, 94% of enterprises now use at least one cloud service, and that figure continues to rise year on year. The business case for cloud migration rests on four core pillars: scalability, cost efficiency, resilience, and global reach.
Scalability allows organisations to increase or decrease their computing resources on demand, paying only for what they use rather than maintaining idle capacity. Cost efficiency comes from eliminating capital expenditure on physical hardware and shifting to an operational expenditure model, with typical savings of 20 to 30 percent compared to on-premises infrastructure. Resilience is built into cloud platforms through geographically distributed data centres, automated failover, and managed backup services. Global reach enables UK organisations to deploy services closer to their users anywhere in the world, reducing latency and improving performance.
The UK government recognised these benefits early. The Cloud First policy, introduced in 2013, requires public-sector organisations to evaluate cloud solutions before considering any other option when procuring new or existing services. This policy has driven a significant shift in how government digital services are designed, built, and operated, and it has created a ripple effect throughout the private sector supply chain.
The 7 Rs of Cloud Migration
Not every workload should be migrated the same way. The 7 Rs framework provides a structured approach to deciding how each application or service should be handled during migration. Understanding these strategies allows you to match the right approach to each workload based on its complexity, business value, and technical constraints.
The 7 Rs Migration Strategies
| Strategy | Description | Effort Level | Cost | When to Choose |
|---|---|---|---|---|
| Rehost | Lift and shift — move applications to the cloud with minimal or no changes to the architecture | Low | Low | Quick wins; applications that need to move fast with minimal risk |
| Replatform | Lift and optimise — make minor tweaks to take advantage of cloud capabilities without redesigning | Low to Medium | Low to Medium | Applications that benefit from managed services such as databases or caching layers |
| Refactor / Re-architect | Redesign the application for cloud-native architecture using microservices, containers, or serverless | High | High | Applications with long-term strategic value that need scalability and agility |
| Repurchase | Move to a different product, typically a SaaS solution — for example, migrating a legacy CRM to Salesforce | Medium | Medium | When a commercial SaaS product better serves the business need than a custom application |
| Retain | Keep the application on-premises — it is not ready to move or there is no business case for migration | None | None | Legacy systems with deep dependencies, compliance restrictions, or low migration ROI |
| Retire | Decommission the application — it is no longer needed or its functionality has been absorbed elsewhere | Low | Savings | Redundant applications, unused environments, or services replaced by other migrations |
| Relocate | Move to a different cloud provider or region — often driven by compliance, cost, or performance requirements | Medium | Medium | When changing provider for better pricing, compliance with data residency, or regional performance |
Source: AWS Migration Strategies — The 7 Rs (adapted for general cloud migration planning)
Start with Rehost for Quick Wins
Many organisations begin their cloud migration journey with a rehost (lift and shift) strategy for non-critical workloads. This approach delivers fast results with minimal risk, builds confidence and cloud skills within the team, and creates momentum for more complex migrations later. Once your team is comfortable operating in the cloud, you can progressively refactor high-value applications to take full advantage of cloud-native capabilities.
Cloud Provider Comparison
The three major hyperscale cloud providers — Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) — each offer comprehensive services with data centres in the United Kingdom. Your choice of provider will depend on your existing technology stack, workload requirements, pricing sensitivity, and the specific certifications or compliance frameworks you need.
AWS vs Azure vs GCP for UK Organisations
| Aspect | AWS | Azure | GCP |
|---|---|---|---|
| Market Share | Largest global market share at approximately 31% | Second largest at approximately 25%, growing rapidly | Third largest at approximately 11%, strong growth trajectory |
| Core Strengths | Broadest service catalogue; mature ecosystem; extensive partner network | Deep enterprise integration with Microsoft 365 and Active Directory ecosystem | Leading data analytics and machine learning; competitive sustained-use pricing |
| UK Data Centres | 3 UK regions (London, with additional availability zones) | 3 UK regions (UK South, UK West, and additional zones) | 2 UK regions (London, with additional zones expanding) |
| Pricing Model | Pay-as-you-go with reserved instances and savings plans for committed use | Pay-as-you-go with reserved instances and hybrid benefit for existing Microsoft licences | Pay-as-you-go with sustained-use discounts applied automatically; committed-use discounts available |
| Certifications | ISO 27001, SOC 2, Cyber Essentials Plus, G-Cloud listed, NHS DSPT | ISO 27001, SOC 2, Cyber Essentials Plus, G-Cloud listed, NHS DSPT | ISO 27001, SOC 2, Cyber Essentials Plus, G-Cloud listed |
Source: Synergy Research Group, Gartner, and provider documentation (2025-2026)
Multi-Cloud vs Single-Cloud Strategy
A multi-cloud strategy — using two or more providers — can reduce vendor lock-in and allow you to use the best service from each platform. However, it also increases operational complexity, requires broader skill sets, and can make cost management more difficult. For most UK mid-market organisations, starting with a single primary provider and designing for portability (using containers, Kubernetes, and infrastructure as code) is a pragmatic approach that keeps options open without the overhead of managing multiple cloud environments from day one.
Migration Planning and TCO Analysis
A successful cloud migration begins with thorough planning. Rushing into migration without understanding your current environment, costs, and dependencies is the single most common cause of project failure. The planning phase should produce a clear picture of what you have, what it costs, what moves first, and what happens if something goes wrong.
Migration Planning Steps
| Planning Step | What to Do | Tools and Methods |
|---|---|---|
| Application Inventory and Dependency Mapping | Catalogue every application, database, and service in your estate; map dependencies between systems | AWS Application Discovery Service, Azure Migrate, manual architecture diagrams, CMDB exports |
| TCO Comparison | Compare the total cost of ownership for on-premises versus cloud over 3 to 5 years including hardware, licences, staffing, and facilities | AWS Pricing Calculator, Azure TCO Calculator, GCP Pricing Calculator, spreadsheet modelling |
| Workload Prioritisation | Score each workload on a complexity versus business value matrix to determine migration order | 2x2 prioritisation matrix; start with low-complexity, high-value workloads for early wins |
| Network Assessment | Evaluate current bandwidth, latency, and connectivity options between on-premises and cloud | Network performance testing; evaluate AWS Direct Connect, Azure ExpressRoute, or GCP Interconnect |
| Security and Compliance Review | Identify regulatory requirements, data classification, and security controls needed in the cloud | GDPR impact assessment, Cyber Essentials checklist, ISO 27001 gap analysis, NCSC Cloud Security Principles |
| Migration Timeline and Phasing | Create a phased migration plan with clear milestones, dependencies, and resource allocation | Gantt charts, migration waves (typically 3 to 6 waves over 6 to 18 months), sprint-based delivery |
| Rollback Plan | Define rollback procedures for every migration wave so you can revert if critical issues arise | Documented runbooks, automated scripts, data synchronisation between on-premises and cloud during transition |
Source: Cloud Adoption Framework — AWS, Azure, and GCP best practices
Watch for Hidden Costs
Cloud TCO calculations often underestimate three significant cost areas. Data egress charges — the cost of transferring data out of the cloud — can add up quickly for data-intensive workloads. Support tier costs — enterprise-level support from AWS, Azure, or GCP typically costs 3 to 10 percent of your monthly spend. Training and upskilling — your team will need cloud-specific skills, and the cost of training, certifications, and potential new hires should be factored into your business case from the outset.
UK Data Sovereignty and GDPR Compliance
For UK organisations, data sovereignty and regulatory compliance are non-negotiable aspects of any cloud migration. The UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018 impose strict requirements on how personal data is stored, processed, and transferred. Understanding these obligations before you migrate — not after — is essential to avoiding regulatory penalties and maintaining customer trust.
UK Compliance Considerations for Cloud Migration
| Consideration | Requirement | Practical Cloud Action |
|---|---|---|
| Data Residency | Understand where your data is physically stored; UK data centres preferred for sensitive data; check adequacy decisions for international transfers | Configure cloud resources to use UK regions (eu-west-2 for AWS, UK South for Azure, europe-west2 for GCP); restrict region availability in policies |
| GDPR Article 28 — Processor Obligations | Data processors must provide sufficient guarantees for technical and organisational measures; formal data processing agreements are required | Review and sign the cloud provider Data Processing Addendum (DPA); verify sub-processor lists; ensure contractual obligations flow down to all parties |
| Data Transfer Mechanisms | Transfers outside the UK require appropriate safeguards; UK-EU adequacy decision currently in place; standard contractual clauses (SCCs) for other jurisdictions | Use UK and EU regions where possible; implement SCCs for non-adequate countries; monitor the ICO for changes to adequacy decisions |
| Encryption Requirements | Personal data must be protected using appropriate technical measures; encryption at rest and in transit is an expected baseline | Enable encryption at rest for all storage services; enforce TLS 1.2 or higher for data in transit; consider customer-managed encryption keys for sensitive workloads |
| Right to Erasure in Cloud | Data subjects can request deletion of their personal data; organisations must be able to locate and delete data across all cloud services | Implement data cataloguing and tagging; document deletion procedures for each cloud service; verify that backups and snapshots are included in erasure processes |
| Data Breach Notification | Breaches involving personal data must be reported to the ICO within 72 hours; affected individuals must be notified if there is a high risk to their rights | Configure cloud-native alerting (AWS GuardDuty, Azure Sentinel, GCP Security Command Centre); establish an incident response runbook with ICO notification templates |
| Data Protection Impact Assessment | A DPIA is required when processing is likely to result in a high risk to individuals; cloud migration typically triggers this requirement | Conduct a DPIA before migration begins; document the data flows, risks, and mitigations; review with your Data Protection Officer; update as the cloud environment evolves |
Source: ICO Guidance on Cloud Computing, UK GDPR, Data Protection Act 2018
The UK Adequacy Decision
Following Brexit, the European Commission granted the UK an adequacy decision in June 2021, allowing personal data to flow freely between the EU and the UK without additional safeguards. This decision is subject to review and could be revoked if the UK diverges significantly from EU data protection standards. UK organisations should monitor this closely, as a loss of adequacy would require implementing standard contractual clauses or other transfer mechanisms for any EU data processed in UK cloud environments.
Common Migration Pitfalls
Even well-planned migrations encounter problems. Learning from the mistakes of others is one of the most cost-effective steps you can take. The following pitfalls are drawn from real-world migration projects and represent the issues that most frequently cause delays, cost overruns, or outright failure.
Migration Pitfalls and How to Avoid Them
| Pitfall | What Goes Wrong | How to Avoid It |
|---|---|---|
| Underestimating Bandwidth Needs | Migrating terabytes of data over a standard internet connection takes far longer than expected, causing timeline slippage | Assess data volumes early; use dedicated connections (Direct Connect, ExpressRoute) or physical transfer devices (AWS Snowball) for large datasets |
| Ignoring Application Dependencies | Moving one application without understanding its dependencies on databases, APIs, or other services causes cascading failures | Complete thorough dependency mapping before migration; use discovery tools to identify all connections between systems |
| Skipping the Pilot Phase | Migrating production workloads without testing in the cloud environment leads to unexpected performance issues and configuration errors | Run a pilot migration with a non-critical workload first; validate performance, security, and operational procedures before scaling |
| Not Training Staff | Operations teams unfamiliar with cloud tooling make configuration mistakes, miss alerts, and struggle with incident response | Invest in cloud training and certifications before go-live; pair experienced cloud engineers with on-premises staff during the transition |
| Forgetting Egress Costs | Data transfer out of cloud providers is charged per gigabyte; applications with heavy outbound traffic generate unexpected bills | Model egress costs in your TCO analysis; use CDNs and caching to reduce outbound traffic; consider reserved data transfer pricing |
| Weak Identity Management | Poorly configured IAM policies, shared credentials, and excessive permissions create security vulnerabilities | Implement the principle of least privilege from day one; use SSO and MFA for all accounts; audit IAM policies regularly |
| No Rollback Plan | When migration issues arise, teams cannot revert to the previous state, leading to extended outages and data loss | Document rollback procedures for every migration wave; maintain data synchronisation between environments during the transition period |
| Treating Cloud Like On-Premises | Replicating on-premises architecture in the cloud without leveraging cloud-native features results in higher costs and lower performance | Adopt cloud-native patterns where appropriate; use managed services instead of self-managed infrastructure; design for elasticity and automation |
Source: Compiled from AWS, Azure, and GCP migration best practices and post-migration reviews
The Pilot Migration Is Essential
Never skip the pilot. A pilot migration — moving a single, non-critical workload to the cloud — validates your migration process, tooling, network configuration, and security controls in a low-risk environment. It uncovers issues that cannot be found in planning documents alone, such as latency between cloud and on-premises systems, unexpected application behaviour, and gaps in monitoring. The lessons learned from your pilot will save significant time and cost across all subsequent migration waves.
Master Cloud Computing
Cloud migration is just the beginning. Our accredited Cloud Computing course covers architecture design, security, cost optimisation, and multi-cloud strategy — giving you the skills to build, manage, and scale cloud infrastructure with confidence.
Explore Our Cloud Computing Course