Almost every business now uses the cloud in some way, from email and file storage to accounting and customer relationship tools. But "cloud migration" means something bigger: moving your core systems, data and applications out of servers you own and into infrastructure you rent. Done well, it brings resilience, speed and flexibility. Done carelessly, it brings surprise bills and downtime.
This guide explains cloud migration in plain English, with a practical plan you can follow.
Key takeaways
- Cloud migration is decided application by application, not as one giant move.
- The 6 Rs (rehost, replatform, repurchase, refactor, retire, retain) give you a simple menu of options.
- Start with an inventory and cost baseline; most failures begin with skipped discovery.
- Security, backups and cost monitoring must be designed in from day one.
What is cloud migration?
Cloud migration is the process of moving digital assets (applications, databases, files and workloads) to cloud infrastructure. The cloud is simply computing resources (servers, storage, networking, databases and services) delivered over the internet by providers such as Amazon Web Services, Microsoft Azure and Google Cloud, with pay-as-you-go pricing. Our comparison of AWS, Azure and Google Cloud helps you choose a provider.
Common migration types:
- On-premises to cloud: the classic move from your own server room.
- Cloud to cloud: switching providers or consolidating accounts.
- Cloud repatriation: moving some workloads back on-premises when economics or compliance demand it.
- Hybrid: keeping some systems on-premises and others in the cloud.
Why businesses migrate
- Cost model: replace big hardware purchases and refresh cycles with usage-based billing.
- Scalability: handle seasonal spikes without buying equipment you use twice a year.
- Resilience: multi-zone hosting, managed backups and disaster recovery that small firms cannot afford alone.
- Speed: new environments in minutes instead of weeks.
- Security tooling: access to enterprise-grade encryption, monitoring and identity services.
- Remote work: systems reachable securely from anywhere.
The 6 Rs: how to decide what happens to each application
| Strategy | What it means | Effort | Best for |
|---|---|---|---|
| Rehost ("lift and shift") | Move the application as-is to cloud servers | Low | Deadlines, data-centre exits, stable legacy systems |
| Replatform | Small optimisations, such as moving to a managed database | Low to medium | Quick wins in cost and operations |
| Repurchase | Replace with a SaaS product | Medium | Email, CRM, HR, accounting |
| Refactor / rearchitect | Redesign to use cloud-native services | High | Strategic apps that need scale and agility |
| Retire | Switch off applications nobody needs | Low | Duplicate or obsolete tools |
| Retain | Keep on-premises for now | None | Regulated, latency-sensitive or recently upgraded systems |
A useful rule: retire first, repurchase where possible, rehost for speed, refactor only what is strategic.
A step-by-step migration plan
1. Define the business goal
Cost reduction, resilience, speed, compliance or a data-centre contract ending? The goal changes your strategy and your success measures.
2. Inventory and assess
List every application, database, integration, owner, user count, data volume, dependency and current running cost. You cannot move what you cannot see. Automated discovery tools can help, but interviews with the people who use the systems reveal what tools miss.
3. Choose a strategy per application
Apply the 6 Rs. Group applications into waves: start with low-risk, low-dependency workloads to build confidence.
4. Design the target environment
Plan accounts and organisation structure, networking, identity and access management, encryption, logging, backups, disaster recovery and tagging for cost allocation. This is the "landing zone" and it is far easier to build properly once than to retrofit.
5. Plan security and compliance
Map regulatory requirements (data residency, retention, audit). Adopt least-privilege access and multi-factor authentication for every administrator. See small business cybersecurity threats for the basics.
6. Pilot a small workload
Migrate one non-critical application end to end. Measure performance, cost and effort; fix the process before scaling.
7. Migrate in waves
For each wave: back up, replicate data, test in parallel, schedule a cutover window, communicate to users, and keep a rollback plan.
8. Test thoroughly
Functional tests, performance and load tests, security scans and user acceptance testing. Confirm integrations and scheduled jobs behave.
9. Cut over and monitor
Switch traffic, watch dashboards closely for the first days, and keep the old environment available until you are certain.
10. Optimise continuously
Right-size instances, delete idle resources, use reserved or savings plans for steady workloads, automate shutdown of dev environments and review the bill monthly. Cost management is an ongoing practice (often called FinOps), not a one-off task.
What does cloud migration cost?
There is no honest single number, because costs depend on how many applications you have and how much you change them. Budget for:
- Assessment and planning: discovery, architecture and a business case.
- Migration labour: engineering effort, often the largest line.
- Cloud running costs: compute, storage, data transfer, licences and support plans.
- Temporary double-running: paying for old and new environments during the transition.
- Training and change management.
- Data egress and licensing surprises: some software licences change in the cloud.
Top risks and how to avoid them
- Bill shock: set budgets and alerts on day one; tag every resource.
- Misconfiguration: public storage buckets and over-permissive roles cause many breaches. Use infrastructure as code and automated checks.
- Underestimated dependencies: an undocumented integration breaks at cutover. Test end to end.
- Vendor lock-in: use open standards and containers where sensible; keep data exportable.
- Skills gap: train staff or bring in an experienced partner for the first waves.
- Downtime: rehearse the cutover and keep a rollback path.
Should your business migrate?
Migrate if your hardware is ageing, you want resilience without owning a data centre, your workloads fluctuate, or your team spends too much time on maintenance. Think carefully if you have strict data-sovereignty needs, steady predictable workloads that are already cheap on-premises, or very specialised hardware.
A sample migration wave plan
To make the process tangible, here is how a 20-person company with eight systems might sequence its move:
| Wave | Systems | Strategy | Why in this wave |
|---|---|---|---|
| 0 (cleanup) | Two unused legacy tools | Retire | Removes cost and risk before moving anything |
| 1 (quick wins) | Email, file sharing, accounting | Repurchase (SaaS) | Low risk, immediate benefit, easy to roll back |
| 2 (supporting) | Company website and blog | Replatform to a managed host | Moderate effort, clear performance gains |
| 3 (core) | Customer portal and database | Rehost first, refactor later | Business critical; needs careful testing and a rollback plan |
| 4 (retain) | Specialised on-site equipment controller | Retain | Latency and hardware constraints make cloud impractical |
Pre-migration checklist
- Named business owner and technical lead for each application.
- Complete inventory of servers, databases, integrations, licences and scheduled jobs.
- Baseline measurements: performance, uptime, and monthly cost today.
- Data classification: which data is personal, financial or regulated.
- Backup and rollback plan for every cutover.
- Target architecture documented, including network, identity and logging.
- Budget, alerts and tagging rules defined in the cloud account.
- Communication plan: who tells users what, and when.
Cost optimisation after the move
Most overspending in the cloud comes from a handful of causes that are simple to fix:
- Oversized servers: check CPU and memory use after a month and downsize.
- Idle resources: unattached disks, old snapshots, unused load balancers and forgotten test environments.
- Always-on development environments: schedule them to shut down at night and on weekends.
- No commitment discounts: steady workloads can use reserved capacity or savings plans for lower rates.
- Expensive data transfer: keep traffic within a region where possible and use a CDN for public content.
- Untagged spend: without tags you cannot say which team or product costs what.
Security design principles for the new environment
- Identity first: single sign-on, MFA for every human, no shared accounts, short-lived credentials for services.
- Least privilege: grant the minimum permissions and review them regularly.
- Encrypt everywhere: data at rest and in transit, with managed keys.
- Segment the network: keep databases private; expose only what must be public.
- Log and alert: central logs for administrative actions and unusual access.
- Automate configuration: infrastructure as code reduces human error and makes audits easier.
- Plan for failure: test backups and practice a recovery.
Questions to ask a migration partner
- How will you inventory our systems, and who from our side needs to be involved?
- Which of the 6 Rs do you expect for our key applications, and why?
- How do you handle security design and compliance requirements?
- What will be documented and handed over, and will we own all accounts?
- How do you forecast and control running costs?
- What is the rollback plan if a cutover fails?
Next steps
Our cybersecurity and cloud team runs migration assessments that give you an application inventory, a recommended strategy per system, a security design and a realistic budget. If you are still weighing whether to bring in specialists or hire, read IT consulting vs in-house IT, then request your assessment.
