Cloud migration means moving applications, data and infrastructure from equipment you own to services you rent. In practice it covers everything from moving email to Microsoft 365 through to relocating an entire server estate.
The term covers such a wide range that "we are migrating to the cloud" tells you almost nothing about what is involved. What matters is which workloads are moving and by which method.
What you are actually renting
Three service models, distinguished by how much you remain responsible for:
- Software as a Service — you use an application and manage nothing beneath it. Microsoft 365, Salesforce, most modern line-of-business software. The vendor handles infrastructure, updates and availability.
- Platform as a Service — you deploy applications onto a managed platform, without managing servers or operating systems. Managed databases and app hosting fall here.
- Infrastructure as a Service — you rent virtual machines, storage and networking, and remain responsible for the operating system upward. The closest analogue to running your own servers, and the usual destination when lifting an existing server estate.
One point that applies across all three: the shared responsibility model. The provider secures the infrastructure; you remain responsible for your data, your access control, and your configuration. This is where the most common misunderstanding in cloud adoption lives — Microsoft keeps your email service running, and protecting your data within it is your responsibility, not theirs.
The six ways to move a workload
Deciding this per workload rather than wholesale is what separates well-run migrations from expensive ones.
- Rehost — move as-is onto cloud infrastructure. Fastest and cheapest to execute, and it carries every existing inefficiency with it. Often the right first step when the driver is a datacentre exit or hardware reaching end of life.
- Replatform — move with modest changes, such as a database moving to a managed service. Moderate effort, meaningful ongoing benefit in reduced administration.
- Refactor — rework the application to use cloud-native services. High effort, generally reserved for software you own and depend on heavily.
- Repurchase — replace with a SaaS equivalent. Usually the right answer for email, file servers and commodity applications.
- Retain — leave it where it is. Some workloads genuinely should not move, and a deliberate hybrid outcome is better than a forced one.
- Retire — switch it off. Discovery consistently finds applications and servers nobody has used in years, and every one retired is migration effort saved.
Most small business migrations are predominantly repurchase and rehost, with a meaningful amount of retire once someone actually looks.
How a project actually runs
- Discovery. Inventory every application, its data, its dependencies and its licensing. The dependency map is the most valuable output, because applications rarely stand alone.
- Decide the approach per workload, using the six options above.
- Design the destination — identity, network, security configuration, and how it will be backed up.
- Prepare. Clean up the directory before synchronising it, resolve licensing, and confirm bandwidth is adequate.
- Pilot with one group doing real work, for long enough to surface problems.
- Migrate in waves rather than all at once, with a defined rollback position for each.
- Cutover, decommission the old environment deliberately, and right-size after 60 to 90 days of real usage data.
Identity is the item that should come first and frequently comes last. Nearly everything else depends on it, and migrating a directory full of stale accounts carries that mess forward permanently.
What genuinely changes afterwards
The operational model shifts in ways that are easy to underestimate.
- Capital spending becomes operating spending. No more five-year hardware cycles, and no more capital approval for capacity.
- Your internet connection becomes critical infrastructure. Traffic that stayed on the LAN now crosses it, and an outage becomes a total outage. A secondary connection stops being optional.
- Capacity becomes elastic, which removes the need to buy for peak load permanently — provided somebody actually right-sizes, which is where most ongoing waste originates.
- Security shifts from perimeter to identity. There is no longer an inside, which makes MFA and conditional access foundational rather than optional.
- Backup becomes a separate purchase and a separate responsibility.
- Remote work stops being a special case.
What it does not fix
Worth stating plainly, because expectations shape whether a migration is judged a success.
Cloud migration does not automatically reduce cost. Counted honestly against the full cost of owning hardware, it is frequently comparable rather than dramatically cheaper, and it can be more expensive where resources are over-provisioned and never reviewed.
It does not make you more secure by itself. It changes the shape of the security problem — a well-configured cloud environment is generally more defensible than a neglected server room, and a badly configured one is exposed to the entire internet rather than to your office.
And it does not remove the need for IT management. It removes hardware maintenance and replaces it with identity management, configuration, cost governance and vendor management. The work changes rather than disappearing, which is a better argument for migration than cost saving, and a more honest one.