You moved to the cloud. The bill didn't go down. If that sounds familiar, you didn't do a cloud migration wrong: you did a lift-and-shift and called it a migration. There's a difference, and it's worth money. In this article you will see why Cloud Replatforming vs Cloud Migration aren't the same thing.
"Cloud migration" gets used as a catch-all term for anything that ends with your servers running somewhere else. In practice, most of what gets sold as migration is lift-and-shift: the same application, the same architecture, the same over-provisioned infrastructure, just repointed at AWS or Azure instead of a data centre you own.
Understanding cloud replatforming vs cloud migration as separate decisions, not stages of the same process, is the first step to spotting which one you're actually getting.
Lift-and-shift is popular for reasons that have nothing to do with your outcome. It's lower risk for the systems integrator delivering it: nothing changes structurally, so there's less to get wrong and less to be accountable for. It's faster to bill against, because there's no redesign phase eating into the timeline. And it looks like progress on a status update, because the migration completes on schedule.
What it doesn't do is reduce cost. You've taken a workload that was over-provisioned on your own hardware and over-provisioned it on rented hardware instead. The invoice moved. The waste didn't. Batch jobs still run on schedules built for physical servers. Databases still run at fixed capacity sized for peak load that happens twice a year. None of the inefficiency that was costing you money on-prem gets addressed, because nothing about how the application works has changed.
This is why so many cloud migrations end with a CFO asking why the promised savings never showed up. The answer is usually: because nothing was actually redesigned.
Replatforming is not a step up from lift-and-shift on some migration taxonomy. It's a different kind of decision. You're not moving the application: you're redesigning it for the environment it's moving into. That means asking what the target platform is actually good at, then changing the application to use it. A few examples of what that looks like in practice:
None of this requires vendor-specific jargon to understand, and that's deliberate: the principles hold whether the target is AWS, Azure, or Google Cloud. The mechanics differ; the design decisions don't. For a broader look at how those platform differences affect the decision, see our guide to choosing the best cloud service provider.
Here's a real number. We worked with Renault on a legacy ERP system running on bare metal. Rather than lifting it onto AWS as-is, we rearchitected it for the platform. Result: a 15–25% reduction in infrastructure cost.
That range didn't come from cheaper hardware. AWS compute isn't inherently cheaper than owned hardware once you factor in the premium of running it well. The saving came from design decisions:
This is the part most cloud migration content skips. The 5 Rs and 6 Rs frameworks you'll find in hyperscaler documentation explain replatforming as a category. They don't explain that the savings come from specific, deliberate decisions made during the redesign: decisions a lift-and-shift never makes, because a lift-and-shift asks "how do we move this" instead of "how should this work here."
Renault is the clearest illustration we have of cloud replatforming vs cloud migration as a cost decision, not a technical one.
Most sales conversations about "cloud migration" don't distinguish between the two. Here's how to find out which one you're actually being sold, before you sign anything. The cloud replatforming vs cloud migration distinction rarely gets spelled out in a proposal: you have to ask for it directly.
Are they proposing to redesign the data layer, or just move it? If the answer is "we'll migrate your database to an equivalent instance in the cloud," that's a rehost. A replatforming proposal should include a plan for the data layer itself — managed services, schema changes, or both.
Do they have a right-sizing plan? Ask what your compute and storage will be sized against. If the answer is "the same as what you have now," nobody has looked at whether that sizing still makes sense.
Are they proposing managed services or IaaS replicas? A proposal that recreates every server you currently own as a virtual machine in the cloud is a rehost with extra steps. Managed services should show up somewhere in the plan.
Have they done this for a comparable workload before? Ask for a reference architecture or case study, not a capability slide. If they can't point to a workload similar to yours that they've actually rearchitected, you're the first attempt.
Does the cost model change, or just the cost centre? If the proposed run-rate in the cloud is roughly what you'd expect from replicating your current environment, nothing has been redesigned. A genuine replatforming proposal should come with a cost model that looks structurally different from what you have today. Our CloudOps vs DevOps breakdown is useful here too, since who owns ongoing optimisation after go-live tells you a lot about whether cost reduction was ever part of the plan.
Replatforming isn't the answer for every migration, and treating it as one is its own kind of mistake.
If you're under a hard deadline — a data centre contract ending, a licence expiring — lift-and-shift gets you out the door on time. Redesigning an application properly takes longer than moving it as-is, and sometimes the clock doesn't allow for that.
If the application is scheduled for decommission or replacement within the next year or two, investing in a redesign makes no sense. You'd be optimising something you're about to retire.
And if you're running an exploratory migration, testing whether a workload behaves acceptably in the cloud before committing budget to a full rearchitecture, lift-and-shift is the right first step. You learn what you need to know without spending on a redesign you might not need.
The mistake isn't choosing lift-and-shift. It's choosing lift-and-shift, being sold it as transformation, and being surprised when the invoice doesn't shrink.
Our approach starts with the target platform, not the current one. Before we touch an architecture, we assess what the destination environment does well and where the current design fights against it: that's what shaped the Renault engagement, where the redesign decisions came before the migration plan, not after. It's also the basis of our cloud migration consulting service: an assessment of whether your workload needs redesigning, right-sizing, or genuinely just moving, before we commit you to any of the three.
If you're planning a cloud migration and want to understand whether replatforming is right for your workload, speak to our team.
Replatforming is redesigning an application for the environment it's moving into, rather than moving it as-is. It typically means changing how the application uses compute, storage, and data services so it works with the target platform instead of just running on top of it.
Cloud replatforming is replatforming applied to a cloud migration: redesigning an application's architecture — scaling, data layer, managed services — to fit a cloud platform such as AWS or Azure, instead of copying the existing on-prem setup into a cloud environment.
No. Cloud migration is the broad category of moving workloads to the cloud, and it includes several approaches — rehosting (lift-and-shift), replatforming, and refactoring among them. Replatforming is one specific approach within that category, and it's the one most likely to reduce cost, because it involves redesign rather than a straight move.
Replatforming makes targeted changes to fit the new platform — switching to managed services, right-sizing, adjusting how components scale — without rewriting the application's core logic or codebase. Refactoring goes further: it changes the application's code and architecture itself, often to move to a different model entirely, such as breaking a monolith into microservices. Replatforming is faster and lower-risk; refactoring delivers more transformation potential but costs more in time and engineering effort. Most organisations should replatform first and refactor only where a specific workload justifies the investment.
Cloud migration is the umbrella term for moving any workload to the cloud, whatever approach you take to get there. Cloud replatforming is one of those approaches — the one where you redesign the application for the target platform rather than moving it unchanged. Every replatforming project is a cloud migration; not every cloud migration involves replatforming. Most of the ones that disappoint on cost don't.
