What Cloud Migration Actually Means
Cloud migration is the process of moving your digital assets — applications, data, workloads, and IT infrastructure — from on-premise data centres or co-location facilities to a public or private cloud environment. The term sounds straightforward, but in practice it encompasses a broad spectrum of activities: from simply copying a virtual machine to AWS (a "lift-and-shift") all the way to completely redesigning an application as a cloud-native, microservices-based system.
In 2026, the business case for cloud is stronger than ever. Organisations that have completed migrations report an average 20 to 30 percent reduction in total IT infrastructure costs, alongside significant gains in deployment speed, scalability, and disaster recovery capability. However, poorly planned migrations routinely overshoot budgets and timelines — and the horror stories are real. This guide gives you the framework to be in the success category, not the cautionary tale.
The 6 R's of Cloud Migration
Gartner's 6 R's framework (popularised by AWS) gives migration teams a consistent vocabulary for categorising how each workload will be moved. Every application in your portfolio should be tagged with one of these strategies before planning begins.
| Strategy | Also Known As | Description | Effort | Risk | Best Use Case |
|---|---|---|---|---|---|
| Rehost | Lift-and-Shift | Move the workload as-is to a cloud VM with no code changes. | Low | Low | Legacy apps, fast migration deadlines, data centre exit |
| Replatform | Lift-Tinker-Shift | Move with minor optimisations — e.g., move MySQL to RDS without changing the application. | Medium | Low–Medium | Apps that can benefit from managed services with minimal rework |
| Repurchase | Drop and Shop | Replace an existing on-premise system with a SaaS equivalent (e.g., move self-hosted CRM to Salesforce). | Medium | Medium | Commodity systems — CRM, ERP, email, HR platforms |
| Refactor | Re-architect | Redesign the application to be cloud-native — microservices, serverless, containers. Highest value, highest cost. | Very High | Medium | Core business applications requiring significant scalability or agility |
| Retire | Decommission | Identify applications no longer needed and switch them off. Immediate cost saving. | Very Low | Very Low | Redundant, unused, or replaced systems |
| Retain | Revisit | Keep on-premise for now — latency requirements, compliance, hardware dependencies, or cost reasons. | None | None | Mainframes, real-time control systems, recently upgraded hardware |
In our experience migrating dozens of mid-market businesses, a typical portfolio breaks down roughly as: 40% Rehost, 25% Replatform, 15% Repurchase, 10% Refactor, 7% Retire, and 3% Retain. Your mileage will vary significantly based on how modern your existing stack is.
Pre-Migration Assessment: What to Migrate and What to Keep
The pre-migration assessment is the most critical phase and the one most frequently rushed. Organisations that skip thorough assessment almost always encounter unexpected costs, dependencies they hadn't mapped, and compliance gaps mid-migration.
Application Portfolio Discovery
Start by cataloguing every application, database, and service running in your environment. Tools like AWS Migration Evaluator, Azure Migrate, or third-party platforms like Cloudamize can automatically discover your inventory by deploying lightweight agents or analysing VMware vCenter data. For each application, capture: the technology stack, version, dependencies, current resource consumption (CPU, RAM, storage, network), the business owner, SLA requirements, data classification (sensitive/regulated), and whether it is actively used.
Dependency Mapping
Dependency mapping reveals which applications talk to which, and prevents the common mistake of migrating Application A without realising it calls a service on Application B that hasn't been migrated yet. Use network flow analysis tools (AWS Application Discovery Service, Zerto, or even simple netstat output) to map all TCP/UDP connections between systems. Visualise these as a dependency graph — you'll typically find a few highly connected "hub" services that need to be migrated first.
What to Keep On-Premise
Not everything should move to the cloud. Consider keeping on-premise: mainframe workloads where cloud equivalents don't exist, systems with very low latency requirements (sub-millisecond) that cloud networking cannot meet, hardware-dependent applications (GPU clusters, specialised industrial controllers), systems with contractual or regulatory requirements restricting their location, and applications that were recently refreshed on new hardware where the capex hasn't been amortised.
Migration Phases: From Discovery to Operate
A structured cloud migration follows six phases. Each phase has clear entry criteria, deliverables, and exit criteria. Don't rush from one phase to the next — the gates exist for good reason.
Phase 1: Discovery
Deploy discovery agents, collect 30 to 60 days of performance data, interview application owners, and build the application portfolio inventory. Output: a spreadsheet or CMDB entry for every application with the data points listed above.
Phase 2: Assess
Assign a migration strategy (one of the 6 R's) to each application. Identify compliance and security requirements. Produce a business case with TCO analysis comparing current on-premise costs against projected cloud spend. This is also when you select your cloud provider(s).
Phase 3: Plan
Design the target cloud architecture. Set up the landing zone (VPCs, IAM, logging, security baseline). Define the migration wave plan — which applications move in which order, typically starting with the least complex and most isolated. Define rollback procedures for each wave. Establish a change management and communication plan.
Phase 4: Migrate
Execute the migration waves. For each application: replicate data to the cloud, validate, run parallel operations, execute cutover, validate again, then decommission the source. Use migration tools appropriate to your strategy (AWS SMS, Database Migration Service, Azure Database Migration Service).
Phase 5: Optimise
Post-migration is when the real cloud benefits are realised. Right-size instances based on actual utilisation data. Implement auto-scaling. Move to Reserved Instances or Savings Plans. Enable storage lifecycle policies. Implement tagging for cost allocation. This phase typically reduces cloud costs by 20 to 35 percent from the initial post-migration spend.
Phase 6: Operate
Establish cloud operating model: monitoring, alerting, security patching, cost governance, backup and DR testing. Train the team on cloud-native operations. Implement FinOps practices — monthly cost reviews, anomaly detection, budget alerts.
Common Migration Risks and How to Mitigate Them
Risk 1: Unplanned Downtime
Mitigation: Use database replication to sync data continuously before cutover. Keep the source system running until validation is complete. Use DNS TTL reduction (drop to 60 seconds 48 hours before cutover) to enable fast failback. Always have a tested rollback procedure.
Risk 2: Data Loss
Mitigation: Take a full backup immediately before cutover. Use change data capture (CDC) tools to replicate ongoing transactions during migration. Validate data checksums after migration. Never decommission source systems until you've run the cloud environment under production load for at least 48 hours.
Risk 3: Cost Overrun
Mitigation: Size cloud resources based on actual utilisation data (90th percentile CPU and RAM), not server nameplate specs. Set up billing alerts from day one. Budget for data transfer costs — moving data out of the cloud is expensive and often overlooked. Expect optimisation work to take 60 to 90 days post-migration.
Risk 4: Security and Compliance Gaps
Mitigation: Establish a security landing zone before any workloads move. Map every data classification requirement to a cloud security control. Engage your compliance team (GDPR, PCI, ISO 27001) early. Use infrastructure-as-code to ensure security configurations are consistent and auditable.
Cloud Provider Selection: AWS vs Azure vs GCP
For most businesses, AWS is the pragmatic first choice: it has the broadest service catalogue, the most mature migration tooling, the largest partner ecosystem, and the most community knowledge. Azure is the right choice if you are deeply invested in Microsoft technologies — Active Directory, Office 365, SQL Server,.NET — as the integrations are significantly tighter. GCP is compelling for analytics and AI/ML workloads, where BigQuery and Vertex AI have genuine advantages over equivalents on other platforms.
For UK-based businesses, all three providers have data centres in the UK (AWS London, Azure UK South/West, GCP London). All three offer data residency commitments compatible with UK GDPR. Azure has the edge for UK public sector due to its IL2/IL3 accreditation pathways.
Migration Tools
AWS Migration Hub provides a central dashboard to track migration progress across all AWS migration tools. It integrates with AWS Server Migration Service (for VM replication), AWS Database Migration Service (for database cutover), and AWS Application Migration Service (the successor to CloudEndure).
Azure Migrate is an all-in-one hub for discovery, assessment, and migration on Azure. It includes server assessment, dependency analysis, Azure SQL migration, and web app migration. Particularly strong for Hyper-V and VMware environments.
Google Cloud Migrate for Compute Engine handles VM migration to GCP. For databases, Google Cloud Database Migration Service supports MySQL, PostgreSQL, and SQL Server migrations with minimal downtime.
Cost to Migrate: Realistic Budget Ranges
| Organisation Size | Workloads | Strategy | Professional Services Budget | Timeline |
|---|---|---|---|---|
| Small (5–20 staff) | 2–5 apps | Mostly Rehost | £5,000–£25,000 | 4–8 weeks |
| Mid-Market (50–250 staff) | 10–30 apps | Rehost + Replatform | £50,000–£200,000 | 3–6 months |
| Enterprise (500+ staff) | 50+ apps | Mixed — all 6 R's | £250,000–£2M+ | 12–24 months |
Testing Strategy
A thorough testing strategy is non-negotiable before any production cutover. Your test plan should include: smoke tests (does the application start and respond?), functional regression tests (does it do what it did before?), performance and load tests (does it handle peak load in the cloud environment?), security tests (are network controls, IAM, and encryption correct?), and DR tests (can you actually fail back if something goes wrong?).
Run the cloud environment in parallel with the on-premise environment for at least one full business cycle before cutting over. For most businesses, this means two to four weeks of parallel running. This catches the subtle bugs that smoke tests miss — the scheduled job that only runs on month-end, the report that pulls from a system you forgot to migrate.
Cloud Migration ROI: What to Expect
Research from Accenture, McKinsey, and cloud providers consistently shows that well-executed cloud migrations deliver ROI in three to five years, with operational savings of 20 to 40 percent versus equivalent on-premise infrastructure. Additional value comes from reduced time-to-market (deploying new features in hours rather than weeks), improved reliability (cloud providers offer 99.9 to 99.99% SLAs on managed services), and disaster recovery that actually works.
Ready to Plan Your Cloud Migration?
SpiderHunts Technologies has migrated dozens of UK businesses to AWS, Azure, and GCP. We handle everything from pre-migration assessment through to post-migration optimisation. Get a free migration readiness assessment today.
Get a Free Migration Assessment