The three strategies, and why the choice is per-workload
“Lift and shift” is one of the most expensive shortcuts in enterprise IT. It sounds responsible (low risk, no redesign, “we’re just moving what we have to the cloud”), and that is exactly why it gets chosen by default rather than on purpose. Lift-and-shift, replatform and refactor are three points on a spectrum of how much you change a system as it moves to the cloud, from “nothing” to “almost everything”, and the right answer is almost never the same for every workload in an estate. The costly mistake is treating cloud migration as a single decision rather than a portfolio of decisions, each made on the merits of the system in front of you.
Get the per-workload choice right and the cloud earns its keep. Get it wrong (usually by defaulting to one strategy for everything) and you inherit the worst of both worlds: the disruption of change without the benefit, or the inertia of the old world running on a more expensive meter. For the manufacturers, banks and operators we work with across the UAE and the wider MENA region, that meter is real money leaving the business every month for an outcome nobody decided on.
Lift-and-shift (rehost)
You take the application as it is and run it on cloud infrastructure with minimal changes. Same architecture, same code, new home.
What it buys you: speed and low immediate risk. It is the fastest way out of a data centre that is closing or hardware that is failing, and because the application barely changes, there is little to test beyond “does it still run here”.
What it costs you: lift-and-shift moves the application but not its assumptions. A system designed for fixed on-premise servers, with all its built-in assumptions about networking, storage and scaling, does not become elastic by changing address. It runs, technically, but on a meter that bills by the hour for resources the old architecture demanded rather than the ones the cloud is built to deliver. Done without discipline, costs go up, because cloud infrastructure is rarely cheaper than owned hardware when you use it the same way. Then the second bill arrives: six months later someone says “we need to optimise,” and now you are paying for the migration, the inflated cloud spend, and the rearchitecture you skipped the first time. Lift and shift does not remove complexity. It relocates it, and adds a monthly invoice.
When it is the right call: a hard deadline to vacate a data centre; a stable application nobody intends to invest in further; or as a deliberate first step to get into the cloud quickly, with a plan to optimise afterwards. The danger is when “first step” quietly becomes “final state” and the optimisation never happens. The lift-and-shift that inflates the bill without delivering value is exactly the cloud spend without control pattern we see most often.
Replatform
You make targeted changes to take advantage of cloud capabilities, without rearchitecting the application. The shape stays the same; specific components are swapped for managed equivalents: a self-managed database becomes a managed database service, a hand-rolled queue becomes a managed one, the runtime moves into containers.
What it buys you: meaningful operational relief for moderate effort. Offloading database patching, backups and scaling to a managed service removes a category of work entirely. It is the pragmatic middle: more value than a rehost, far less risk than a rewrite.
What it costs you: more testing than lift-and-shift, and some new operational learning. You are changing real components, so you have to prove the system still behaves.
When it is the right call: most workloads that are worth keeping but expensive to operate. Replatform is the strategy that quietly delivers the best return for the broadest set of systems, which is why it deserves serious consideration before anyone reaches for a full refactor.
Refactor / rearchitect
You substantially change the application to fit cloud-native patterns: decomposing into services, adopting event-driven flows, moving to serverless where it fits. This is composable architecture territory.
What it buys you: the full benefit of genuine elasticity, independent scaling, faster change and the removal of long-standing structural limits.
What it costs you: the most time, money and risk of the three. You are rebuilding, and rebuilds can run long and destabilise the business if approached as a big bang. When refactoring is warranted, the incremental, downtime-free approach is what keeps it safe.
When it is the right call: a system that is strategically important and actively constrained by its current architecture: the scaling ceiling is real, the change cost is painful, and the business case for fixing it is clear. Refactoring a system that is neither growing nor changing is effort spent for an outcome nobody needed.
How to choose: a short decision frame
For each workload, ask three questions in order:
- How much business value and change does this system carry? Low value and low change argues for the cheapest move: rehost, or retire it altogether. High value with constant change earns investment.
- What is the actual pain? If operational toil is the problem, replatform usually solves it. If the architecture itself blocks the business, only refactoring will.
- What is the timeline forcing? A data-centre exit deadline can justify lift-and-shift now and optimisation later, provided “later” is written into the plan with an owner and a date.
A healthy migration plan is a mix: rehost the commodities, replatform the workhorses, refactor the few systems where it genuinely pays, and retire whatever no longer earns its place.
The trap to avoid
The single most expensive pattern is the all-or-nothing posture: “we are lifting and shifting everything to hit the deadline” or “we are going cloud-native across the board because that is the strategy”. Both ignore that the estate is heterogeneous. The systems are not all worth the same, not all changing at the same rate, and not all constrained in the same way, so a uniform strategy guarantees you over-invest in some and under-invest in others.
If the goal is genuinely the cloud, start with the question that matters: what should this system look like if we designed it for the cloud from day one? The answer might still include moving some things as-is, but then it is a conscious decision, not a default. Choosing well requires an honest look at each workload’s value, change rate and constraints, which is the heart of any serious cloud migration assessment, and the kind of decision discipline that European engineering practice takes seriously and that we bring to estates here in the region. If you are staring at a portfolio and trying to decide what gets rehosted, replatformed or rebuilt, talk to TrueForge and we will help you sort it without the one-size-fits-all default.