Cloud Migration Strategy: An Enterprise Decision Framework

There's a version of cloud migration that goes well. Workloads move on schedule, costs come in near forecast, and the team that ran it isn't still firefighting six months later. That version exists. It just requires a specific set of decisions getting made before anyone touches a workload.

Most enterprises skip that part.

Seventy-five percent of cloud migrations run over budget and 37% miss their timeline, according to McKinsey — not the chaotic ones, the average ones. The tooling isn't the issue. AWS, Azure, and GCP have been competing for your workloads for a decade and it shows.

What kills migrations is the decision-making that should have happened first.

So this article covers that. The six approaches, the three filters that narrow the choice, and how to build a cloud migration strategy that actually finishes.

Key Takeaways

• Cloud migration strategy is a portfolio decision. Different workloads need different approaches — picking one approach for everything is expensive.
• Six approaches, from Retire to Replace/Rebuild. Most enterprises end up using four or five across a single estate.
• Three filters decide each approach: strategic value, technical health, team capability. Apply them workload by workload.
• Most failures happen upstream. Bad assessment kills migrations before a single workload moves.
• Hybrid cloud is the destination, not a transitional state. Build your strategy around partial migration from day one.

What Is Cloud Migration Strategy?

A cloud migration strategy is the plan that decides which workloads move to the cloud, in what order, using which approach, and with what business outcomes attached.

Most cloud migrations don't fail on a single workload. They fail on the sum of decisions.

Move 50 workloads with the same lift-and-shift approach and you'll find out a year later that 12 of them should have been refactored, 8 should have been replaced, and 3 should never have been moved at all.

The cost shows up in the cloud bill that doubles, the latency that breaks customer-facing apps, and the security audit that turns up new vulnerabilities in the rehosted code.

The right cloud migration strategy answers five questions:

• Which workloads are moving, and which are staying?
• For each one, what's the right approach? Lift and shift, replatform, refactor, or replace?
• What's the sequence — which workloads move first, which wait, which are deliberately deprioritised?
• How is each workload going to be measured? Cost reduction, performance, scalability, security posture?
• Who owns the call when something has to change mid-flight?

The Six Approaches You Can Choose Between

Most cloud migration strategies map to one of six approaches. These are the same options described in the 6 Rs of application modernization, the canonical framework that runs through every application modernization decision. The order below moves from least change to most change.

• Retire. The workload doesn't move because it doesn't need to exist anymore. A typical enterprise has 15–30 percent of running applications that should be decommissioned, not migrated. Skipping this step is the most common reason cloud bills come in higher than expected.

• Retain. The workload stays on-premises, deliberately. Some applications can't migrate for compliance reasons. Some shouldn't migrate because the cost-benefit doesn't work. Some are about to be replaced and don't justify the engineering work. Retain decisions need a review date, not "forever."

• Rehost (lift and shift). Move the workload to cloud infrastructure with no code changes. Fast and cheap. Doesn't fix structural problems but useful as a step. The most overused approach. Defaulting to rehost across an entire portfolio is how cloud bills double without anything actually improving.

• Replatform. Move and make targeted changes that take advantage of the new platform. Swap a self-managed database for a managed cloud database service. Move from VM-based deployment to containers without breaking the monolith apart. Modest investment, modest gain. The sweet spot for most legacy workloads.

• Refactor or re-architect. Restructure the application internally. Break a monolith into services. Move to event-driven patterns. Adopt cloud-native services like serverless or managed queues. High effort, high value. Only attempt this when the workload is strategically important and the team has done it before.

• Replace or rebuild. Discard the old workload and either adopt a SaaS product or rebuild from scratch on cloud-native architecture. Highest risk, highest payoff. The right call when the existing system's design no longer fits the business it's meant to serve.

In practice, most enterprise cloud migration strategy work uses four or five of these across the portfolio. Picking one approach and applying it everywhere is the single most expensive mistake in cloud migration.

The Decision Framework: Three Filters That Narrow the Choice

The six approaches aren't a menu. They're a decision tree. The cloud migration framework that holds up under enterprise pressure narrows the choice for any given workload using three filters.

Filter 1: Strategic value

How central is this workload to the business now and in the next three years? High-strategic-value workloads earn the right to higher-effort approaches (refactor, replace). Low-strategic-value workloads default to lower-effort approaches (rehost, retire). Don't refactor what you should retire. Don't rehost what you should rebuild.

Filter 2: Technical health

What shape is the workload in today? Healthy workloads can move with minimal effort (rehost, replatform). Unhealthy workloads need real work (refactor) or replacement. A workload that's bleeding maintenance hours every quarter is a workload where rehosting won't fix the underlying problem.

Filter 3: Team capability

Can your team actually deliver the chosen approach? Refactoring needs senior engineering depth. Replatforming needs operational discipline. Lift and shift needs the least skill but the most willingness to live with the result. Match the approach to the team you have, not the team you want.

Lay these three filters across your portfolio and the answer for most workloads becomes obvious. The decision point for choosing a cloud application migration strategy is rarely the approach itself — it's the upstream clarity about strategic value, health, and capability. The hard cases are where a real application modernization strategy earns its keep: funding, sequencing, and governance decisions that no framework alone can make for you.

The Pitfalls That Derail Enterprise Cloud Migrations

If the framework above is what works, here's what doesn't.

• Skipping the assessment. 

  A spreadsheet of 200 workloads with "yes/no/maybe" labels is not an assessment. A real assessment maps each workload's business criticality, technical dependencies, integration complexity, security exposure, and data volume. Organizations that conduct a formal readiness assessment have 2.4x higher success rates than those that don't. Skipping it is the single biggest predictor of failure.

• Treating it as a one-time project. 

  Cloud migration isn't a project with a finish line. It's a multi-year programme with continuous optimisation. Treat it as a project and the funding dries up the moment "phase one" is declared complete. Treat it as a programme and you have the runway to fix the things you discover only after workloads are live.

• Underestimating data migration. 

  The workload is one thing. The data underneath it (schemas built up over years, downstream dependencies, transformation pipelines, regulatory constraints on where data lives) is where most migrations actually get stuck. Budget twice as much time for data as you think you need.

• Ignoring the cloud bill. 

  Cloud costs are unpredictable until you've lived with them for two quarters. Lift-and-shift migrations almost always cost more in cloud than they did on-premises in the first year because you're paying for old architecture on new infrastructure. Plan for FinOps from day one, not as a panicked response after the first invoice.

• Forcing all-cloud when hybrid is the right answer. 

  87% of enterprises now run a hybrid cloud environment. That's not a transitional state — it's the destination. A hybrid cloud migration strategy accounts for partial migration from day one, not as an afterthought when all-in proves too expensive or too complex.

• Missing the security model shift. 

  On-premises security relies on perimeter. Cloud security relies on identity, configuration, and zero-trust patterns. Most cloud migration security strategy work is treated as an afterthought, designed in week one of go-live instead of week one of planning. Misconfiguration causes 65% of cloud security incidents.

How to Build a Plan That Survives Contact with Reality

The teams that get cloud migration right share four habits.

• They start with one workload. 

  Pick something contained, visible enough that finishing it builds credibility, and similar enough to harder workloads that the lessons transfer. Avoid the most critical system and the most political one. Pick the one that earns you the right to take on the next.

• They run old and new in parallel. 

  Successful migrations don't go live with a flip-the-switch cutover. Traffic shifts incrementally. 1 percent, then 10, then 50, with the ability to roll back at every stage. Unglamorous, slow, and the single biggest reason successful projects don't end up in incident reports.

• They keep business owners embedded. 

  Every workload moving to cloud needs a business owner who can answer "is this delivering what we promised?" in plain language to the CFO. When migration is owned by IT alone, it gets cut at the first budget review. When it's jointly owned, it survives the inevitable scope debates.

• They pay down debt during the move. 

  Migration is when codebases are open, dependencies are visible, and the team is already touching the system. Reducing technical debt during the work costs almost nothing extra. Doing it after migration is "done" is much more expensive. The teams that do this well treat cloud migration as a natural moment to also tackle related legacy system modernization work in parallel.

Before You Sign Anything

Cloud migration is one of those problems that looks like a technology decision and turns out to be a portfolio decision. The teams that get it right don't argue about which cloud is best. They argue about which workloads matter, in what order, with which trade-offs, and that's the conversation that determines whether the migration finishes on plan or shows up in McKinsey's next failure statistic.

If you're staring at a portfolio of workloads and a deadline, the answer isn't to pick a hyperscaler and start moving. The answer is to apply the framework, take the assessment seriously, and let the answers tell you which approach fits which workload. Most enterprises that have done this well found that 30–40 percent of their original migration list didn't need to move at all.

At Classic Informatics, we help mid-to-large enterprises run the readiness assessment, apply the framework workload-by-workload, and sequence the migration so it actually finishes. If you've got a portfolio of workloads and you're not sure which one moves first, let's have a conversation.