Cloud migration is one of the most consequential infrastructure decisions an organisation makes. Done well, it reduces costs, improves reliability, accelerates development, and opens capabilities that on-premise infrastructure cannot match. Done poorly, it is expensive, disruptive, and produces a cloud bill that exceeds what the on-premise infrastructure it replaced cost to run. This guide gives you the framework for doing it well.
Why Organisations Move to the Cloud (And Why Some Shouldn't)
The genuine reasons to migrate: you need elasticity — the ability to scale up rapidly during peak periods and scale down when demand drops. You want to eliminate the capital expenditure and operational burden of data centre management. You want access to managed services — databases, AI platforms, container orchestration — that would take significant engineering effort to build and maintain yourself. You need global reach without building regional infrastructure.
The wrong reasons: because competitors are doing it; because a vendor pitched it persuasively; because the current infrastructure feels old without a specific pain point driving change. Cloud is not categorically cheaper for all workloads. Steady-state, predictable compute loads with well-understood capacity requirements can be cheaper on owned hardware. The business case must be built on actual numbers, not assumption.
The 6R Migration Strategy Framework
Every application in your portfolio should be assessed against six migration options. Rehost (lift-and-shift): move the application to cloud infrastructure with no changes. Fast, low-risk, and preserves the current architecture including its inefficiencies. Replatform: minor modifications to take advantage of cloud capabilities — moving to a managed database, containerising the application — without refactoring business logic. Refactor: redesign the application to be cloud-native, taking full advantage of microservices, serverless, and managed services. Highest effort, highest long-term value. Repurchase: replace the application with a SaaS equivalent. Retire: decommission applications that no longer serve a business purpose. Retain: keep specific workloads on-premise where latency, compliance, or total cost of ownership requirements make cloud suboptimal.
The Migration Sequence That Works
Start with the applications that have the most to gain and the least to lose: non-critical, stateless applications with clean architectures and no regulatory data constraints. Migrating these first builds team competence, establishes your cloud operating model, and delivers quick wins — without risking business-critical systems while the team is still learning. Move business-critical systems last, after your processes, tooling, and team are well-practiced.
The Hidden Costs Nobody Warns You About
Data transfer costs — moving data out of cloud providers (egress) is expensive, and architectures that move large volumes of data between services or regions can generate surprising bills. Over-provisioned instances — teams used to on-premise infrastructure tend to over-provision cloud instances out of familiar caution, paying for capacity they don't use. Unoptimised storage — data stored indefinitely in high-performance tiers rather than tiered to cheaper storage as it ages. A FinOps discipline — systematic cost monitoring, tagging, rightsizing, and reserved capacity purchasing — should be established on day one, not as a reactive measure when the first large bill arrives.
The Operating Model Change
Cloud migration is not only a technical project — it changes how your engineering and operations teams work. On-premise infrastructure is managed by provisioning physical or virtual machines through a change control process. Cloud infrastructure is provisioned through code (Terraform, CDK) in minutes. This is a profound shift in capability and responsibility. Teams that don't develop infrastructure-as-code competence, automated security policy enforcement, and cost governance practices during migration end up with cloud infrastructure that is harder to manage than the on-premise environment it replaced.