Cloud migration strategy: a practical guide for growing companies
Planning a cloud migration? This guide covers the 6 migration strategies, a step-by-step roadmap, hidden costs, and when lift-and-shift makes sense.
Cloud migration is the process of moving applications, data, and infrastructure from on-premise servers to a cloud platform — AWS, Azure, or Google Cloud being the most common. For mid-sized companies, it delivers measurable reductions in maintenance overhead, better scalability, and access to modern services. But only when the strategy is sound. Done poorly, it costs more than what you left behind. Here is what actually works.
Why companies migrate to the cloud.
Most organisations considering cloud migration are driven by a combination of five factors. Not all carry equal weight — the balance depends on your specific situation.
- On-demand scalability. Expand or reduce capacity without hardware purchases. Peak loads cost only what you use.
- Reduced maintenance burden. No physical servers, no data centre costs, less internal IT administration. The provider manages the layer below; you manage what runs on top.
- Location independence. Cloud applications are accessible wherever there is an internet connection — relevant for hybrid teams and multi-site organisations.
- Built-in continuity. Redundancy and disaster recovery come standard with major cloud platforms, not as expensive add-ons.
- Access to modern services. AI, machine learning, advanced analytics — they are already in the cloud platform. You activate them when you are ready, without building new infrastructure.
McKinsey (2023) found that organisations that migrated to the cloud saved an average of 20–30% on total IT infrastructure costs — provided they also rationalised their workloads. That saving is not automatic. It is the result of deliberate choices, not just moving servers.
The 6 migration strategies.
AWS defined the '6 Rs' and they have become industry standard. Every application requires its own decision — there is no universal approach that fits every system.
| Strategy | What it means | When it fits |
|---|---|---|
| Rehost (lift-and-shift) | Copy the application to cloud with no changes | Migrate quickly, optimise later |
| Replatform | Minor adjustments for cloud compatibility, no code rewrite | Managed databases, optimised runtime |
| Repurchase | Switch to a SaaS product | Legacy CRM → Salesforce, on-prem HR → Workday |
| Refactor / Re-architect | Rebuild the application for cloud-native architecture | Strategic system with a long service life |
| Retire | Decommission the application | System has no active users |
| Retain | Keep on-premise for now | Compliance requirements, recent investment, too complex for this cycle |
For most mid-sized organisations, the distribution looks roughly like this: 40% rehost, 30% replatform or repurchase, 20% retain, 10% retire or refactor. The last category — refactor — is expensive and time-consuming. Planning for it is worthwhile, but it should be a deliberate choice, not a default for every application.
Step-by-step migration roadmap.
A cloud migration is not a single event — it is a structured programme. Five phases:
- Discovery and inventory. Map which applications you have, what they do, what they cost, and what dependencies exist between them. Tools like AWS Migration Evaluator or Azure Migrate provide a starting point. The goal: no surprises mid-migration. Every undocumented dependency discovered later costs time and money.
- Prioritisation and portfolio decisions. Apply the 6 Rs to each application. Group them into migration waves: wave 1 consists of low-risk, high-gain candidates. Never start with your most complex core system — that is the surest path to delays and cost overruns.
- Foundation and landing zone. Set up your cloud environment before moving a single application. Network segmentation, identity and access management (IAM), logging, monitoring, cost management. This is the most underestimated part of any migration — and the most critical. A poorly structured landing zone means months of cleanup later.
- Pilot and wave 1. Migrate 2–3 non-critical applications. Validate your approach, learn from execution, and document what works. Update your playbook based on real experience before scheduling the rest.
- Full rollout and optimisation. Move the remainder in successive waves. After each wave: review costs, measure performance, clean up unused resources. Cloud optimisation is a continuous process, not a finish line.
Costs and pitfalls.
Cloud is cheaper. In theory. Three factors make migrations more expensive than planned in practice.
Hidden costs that blow budgets:
- Egress fees. Moving data out of the cloud costs money. For high data volumes — large database syncs or media files — this adds up quickly and rarely appears in initial budgets.
- Unused resources. Cloud is flexible, but also easy to forget. Undeleted volumes, idle instances, over-provisioned databases cost money every month. Flexera (2024) reports that organisations waste an average of 28% of their cloud spend on unused or underutilised resources.
- Licences. Windows Server, SQL Server, Oracle — some licences are not transferable to cloud without additional cost. Verify this upfront, not after the migration contract is signed.
- Training and onboarding. Your team needs to learn cloud operations. That takes time and money, but it is rarely included in migration budgets.
Approach mistakes that cause project failures:
- Lift-and-shift as a permanent end state. Moving fast is a valid speed strategy — but not an endpoint. An application built for on-premise infrastructure performs suboptimally in the cloud without optimisation. Plan that optimisation in, or pay structurally too much.
- No governance from day one. Cloud environments grow fast and become chaotic without structure. Retrofitting governance costs more than building it in from the start.
- Scope that is too ambitious. Organisations that try to migrate everything at once stall. Start small, learn fast, then scale.
Lift-and-shift vs. re-architecture: when to choose which.
This is the most common question in cloud migration discussions. The honest answer: both have their place. The decision depends on the system, not on a universal preference.
| Lift-and-shift | Re-architecture | |
|---|---|---|
| Speed | Weeks to months | Months to years |
| Initial cost | Low | High |
| Cost after 1–2 years | Rising (suboptimal cloud fit) | Declining (cloud-native efficiency) |
| Risk | Low | High |
| Recommended for | Migrate quickly, decommission legacy later | Strategic system with a long service life |
Lift-and-shift is not a bad choice. It is a deliberate choice to prioritise speed now and optimise later. That works — as long as you actually schedule and execute that optimisation. Organisations that treat lift-and-shift as a permanent solution pay structurally too much for suboptimal cloud performance.
Re-architecture is the right choice for systems that will remain critical for the next five to ten years. The higher initial investment pays back through lower operating costs, better performance, and future extensibility. The most successful migration programmes combine both approaches — per application, based on its role and expected lifespan.
Cloud migration is more strategy than technology. The organisations that derive real advantage from it start with a clear picture of why they are migrating, choose the right approach per application, and build governance in from day one. Want to know what a migration programme would look like for your organisation?