Loading…
Loading…
A practical 2026 guide to cloud migration: the 6 Rs, real cost ranges, lift-and-shift vs refactor, AI-readiness, and the failure modes that derail projects.
Cloud migration is a per-application portfolio decision, not one project, and the 6 Rs are how you make those decisions.
Lift-and-shift is fast and cheap but rarely delivers cloud value, while refactoring delivers value but costs more; the migrate-then-modernize pattern works only if the modernize phase is actually funded.
Budget for one-time migration cost and ongoing run-cost separately, and govern run-cost from day one to avoid cloud waste.
Most failures come from skipping assessment, lift-and-shifting everything, ignoring cost governance, and treating security as an afterthought.
The biggest opportunity in a migration is to become AI-ready by building a coherent data foundation while systems are already in motion.
Cloud migration is the movement of computing workloads, applications, databases, and the data behind them, from where they run today, whether a data centre, a server room, or aging on-premise hardware, to cloud infrastructure run by a provider. In practice it is rarely one project. It is a portfolio of decisions, one per application, because a payroll system, a customer-facing web app, and a decades-old database each want to move differently.
The reason to do it has shifted over the last decade. Early migrations chased cost savings and the end of hardware refresh cycles. Today the stronger driver is capability: elastic scale, managed data and machine-learning services, and the fact that most modern AI tooling assumes a cloud-shaped data platform underneath it. That is why we treat migration as a modernization opportunity rather than a simple relocation.
Gartner and the major cloud providers popularized a simple way to classify how each workload should move, and getting this decision right per application is the heart of a good migration.
Rehost, or lift-and-shift, moves the app as-is to cloud servers with low effort, and suits stable, deadline-driven cases. Replatform lifts and then makes small optimizations such as a managed database or autoscaling, for quick wins without a rewrite. Repurchase drops the app and adopts a SaaS product where a good commercial one already exists. Refactor or re-architect redesigns the app for cloud-native building blocks, which is high effort but right for strategic applications. Retire decommissions what nobody actually uses, and there is always some. Retain leaves an app where it is for now, for regulatory, latency, or not-yet-worth-it reasons.
The mistake we see most often is treating the whole estate with one strategy. A healthy migration is a mix: rehost the urgent and stable, refactor the strategic, repurchase the commodity, and be honest about what to retire.
Two of the 6 Rs cause most of the debate. Lift-and-shift, or rehost, moves the application unchanged onto cloud servers. It is fast, low-risk, and cheap up front, and it gets you out of the data centre quickly, but it carries all the old inefficiency with it, so you are now paying cloud rates to run software that was never designed for the cloud, and the promised savings often do not appear.
Refactor, or re-architect, redesigns the application to use cloud-native building blocks such as containers, managed databases, serverless functions, and autoscaling. It costs more and takes longer, but it is the path that actually delivers elasticity, resilience, and lower run-cost, and it is what makes an application ready for AI features and real scale.
The pragmatic pattern many enterprises adopt is to migrate then modernize: lift-and-shift under deadline pressure to exit the data centre, then refactor the highest-value applications once the fire is out. That is legitimate as long as the second phase is actually funded and scheduled. When it is not, temporary lift-and-shift becomes permanent technical debt at cloud prices.
There is no single price, but you can frame a budget around a few honest realities. Total cost is driven by the number and complexity of applications, the migration strategy per app, the volume of data to move, and how much refactoring you take on.
Assessment and planning is a fixed early cost and the highest-leverage money you will spend, and skipping it is the most expensive saving in the whole project. Rehosting a straightforward application is the cheapest path, dominated by labour and the data transfer, while refactoring is materially more expensive per application because it is software engineering, not just relocation.
Run-cost after migration is the figure people forget. Cloud is operational spend, not capital, so without cost governance such as right-sizing, autoscaling, reserved capacity, and shutting down idle resources, the monthly bill drifts upward, and cloud waste is a well-documented industry problem. The single most useful budgeting habit is to separate one-time migration cost from ongoing run-cost, and to model both before you commit, because a migration that looks cheap to execute but doubles your monthly run-rate is not a saving.
Cloud migrations rarely fail for exotic reasons; the failure modes are consistent and avoidable.
Teams start moving before they understand dependencies and discover mid-migration that one application silently depends on a database and a file share elsewhere, so map the estate first. The whole portfolio gets lift-and-shifted for speed, the cloud value never materializes, the bill rises, and leadership wrongly concludes that cloud is expensive. Resources are provisioned generously to be safe, nothing is ever turned off, and spend balloons, because cost control is a discipline rather than a one-time setting.
Security is treated as an afterthought, when the shared-responsibility model means the provider secures the infrastructure and you secure your configuration and data, and misconfigured storage and over-broad permissions cause most cloud incidents, so align to a recognized framework such as the NIST Cybersecurity Framework from day one. There is no skills plan, and the team that ran servers is asked to operate a cloud platform they have never used, so budget for training or a partner during the transition. And a big-bang cutover moves everything in one weekend, when an incremental, application-by-application migration with a rollback plan for each is far safer.
The most valuable reframing we can offer is that a migration is the rare, funded moment when leadership is willing to touch core systems. Waste it on pure relocation and you have simply moved the old constraints to a new address. Use it well and you can put in place the data foundations that modern AI actually requires.
That means, where the workload justifies it, moving toward managed data services, clean data pipelines, and an architecture where data is accessible rather than trapped in application silos. The systems that ship AI features successfully are almost always the ones with a coherent data layer underneath, which is why we increasingly advise clients to sequence a migration and a data-platform effort together rather than as separate projects.
Assess and map first, inventorying every application, its dependencies, data volumes, and business value, because this is where the project is won or lost. Classify with the 6 Rs, assigning a strategy per application rather than per portfolio. Prioritize by moving low-risk, high-clarity workloads first to build momentum and learn your patterns.
Migrate incrementally, one application or bounded group at a time, each with a tested rollback. Govern cost from the start by right-sizing, autoscaling, and setting spend alerts before the bill surprises you. Then modernize the strategic few, refactoring the applications where cloud-native design and AI-readiness genuinely pay back. The cloud is elastic and removes hardware refresh cycles, gives access to managed data and AI services, and shifts spend from capital to operational, but poorly planned migrations move inefficiency rather than eliminate it, so the discipline of the sequence matters as much as the destination.
Cloud migration is moving your applications, data, and workloads from your own servers or a legacy data centre to cloud infrastructure run by a provider. It is usually done application by application, with a different approach for each depending on how valuable and how cloud-ready that application is.
The 6 Rs are six strategies for moving a workload: rehost, which is lift-and-shift as-is; replatform, which is lift with small optimizations; repurchase, which is replacing the app with a SaaS product; refactor or re-architect, which is redesigning for cloud-native; retire, which is decommissioning it; and retain, which is leaving it where it is for now. A good migration uses a mix across the portfolio.
Lift-and-shift is a good idea when speed matters, the application is stable, and you have a hard deadline to leave a data centre. It is a poor idea as a whole-estate strategy, because it moves old inefficiency to cloud pricing and rarely captures the value that justified the move. The common pattern is to lift-and-shift under deadline and then refactor the strategic applications afterward.
There is no single figure. Cost is driven by the number and complexity of applications, the strategy chosen per application, the volume of data, and how much refactoring you undertake. The most important budgeting habit is to separate one-time migration cost from ongoing monthly run-cost and to model both before committing, because a migration that is cheap to execute but expensive to run is not a saving.
The common causes are starting without a dependency assessment, lift-and-shifting everything and never capturing cloud value, failing to govern run-cost so the bill balloons, treating security as an afterthought under the shared-responsibility model, and attempting a risky big-bang cutover instead of an incremental move.
Usually yes, at least for the data and workloads the AI will depend on, because most modern AI tooling assumes cloud-shaped data services and scale. The strongest approach is to treat the migration as the moment to build a clean data foundation, so the systems arrive in the cloud AI-ready rather than merely relocated.