Cloud Migration 
Lift-and-Shift or Re-Architect? 

Cloud migration is one of the easiest projects to start with a wildly wrong mental model, and the wrong model is expensive in both directions. Move too crudely — pick up your servers and drop them in the cloud unchanged — and you often end up paying more than you did on-premises while getting none of the agility you were promised. Try to do it too purely — pause the roadmap to re-architect everything into microservices and serverless before you migrate anything — and you sign up for a multi-year project that starves the product and frequently collapses under its own ambition. The real decision isn't lift-and-shift versus re-architect as a binary; it's understanding the spectrum of migration strategies, being honest about which workloads deserve which, and sequencing the work so you get value early instead of betting everything on a big-bang cutover. Most teams that succeed do so by being pragmatic, not pure.

The spectrum: more than two choices

It helps to see migration as a spectrum rather than a binary, and the industry's '6 Rs' name the points along it. Rehosting (lift-and-shift) moves an application as-is onto cloud infrastructure with minimal change — fast and low-risk, but it just relocates your existing design, warts and all. Replatforming makes a few targeted optimizations during the move — swapping a self-managed database for a managed one, for instance — capturing some cloud benefit without a rewrite. Refactoring (re-architecting) meaningfully redesigns the application to be cloud-native, which unlocks the real elasticity and managed-service leverage but costs the most time and risk. The remaining Rs are decisions not to migrate as-is at all: repurchase (drop the custom thing for a SaaS product), retire (switch off what nobody uses — and something always turns out to be unused), and retain (leave a workload where it is for now, often for latency, compliance, or data-residency reasons). The skill is assigning each workload to the right R rather than applying one strategy to everything.

Lift-and-shift: fast, but understand what you're deferring

Rehosting is genuinely the right first move in many cases — it gets you out of a datacenter or off failing hardware quickly, with limited risk and a short timeline, and it stops the bleeding when a lease is expiring or an on-prem system is on fire. What you must be clear-eyed about is that lift-and-shift defers the real work rather than doing it. An application designed for fixed on-prem servers doesn't automatically become elastic, cheaper, or more resilient just because it's now running on cloud VMs — in fact it frequently costs more, because on-demand cloud compute running 24/7 at steady-state is priced for flexibility you're not using. Lift-and-shift buys you speed and a foothold; it does not, by itself, deliver the cloud's economics or agility. Used well, it's a deliberate first phase — get in, stabilize, then optimize — and the mistake is treating the rehost as the finish line and being baffled months later when the bill went up and nothing got more flexible.

Re-architecting: real payoff, real cost — so be selective

Re-architecting is where the cloud's actual promise lives: autoscaling that matches spend to demand, managed services that erase operational toil, and resilience patterns that are hard to build on fixed hardware. But it's expensive in engineering time and risk, and — this is the part teams miss — you rarely need to do it to everything. The value is wildly uneven across your system: the workload with spiky, unpredictable traffic gets enormous benefit from cloud elasticity and autoscaling; the internal admin tool that three people use at a steady trickle gets almost none and should just be rehosted and left alone. So target re-architecting where the payoff is concentrated — your highest-traffic, most-elastic, most-strategic services — and be ruthless about not gold-plating the rest. This is also where a monolith may get carved along its real seams, which is a discipline of its own covered in monolith-to-microservices. Selective re-architecture captures most of the benefit for a fraction of the cost of trying to modernize everything at once.

'The cloud is cheaper' is a conditional, not a fact

The most damaging assumption behind many migrations is that moving to the cloud automatically saves money — it doesn't, and believing it unconditionally is how teams end up shocked by the bill. The cloud is cheaper when you use it the way it's designed to be used: scaling down or off when demand drops, buying commitments for steady-state baselines, using managed services instead of paying people to run infrastructure, and turning off what isn't needed. Run cloud resources like on-prem servers — provisioned for peak, on all the time, never rightsized — and you get on-prem inflexibility at cloud prices, which is the worst of both. The cost benefit is real but conditional on operational discipline, which is precisely why cloud cost management and FinOps aren't an afterthought to migration but part of the plan. Budget for the migration to cost more before it costs less, and make the optimization work an explicit, funded phase rather than something you'll 'get to eventually.'

A pragmatic, phased path

The approach that reliably works is phased and value-driven, never big-bang. Start by discovering and honestly assessing what you actually have — the inventory is always messier than anyone remembers, and this is where retire and repurchase decisions surface real savings before you move a single thing. Then sequence the migration so early wins come fast: rehost the straightforward, low-risk workloads to establish your cloud foundation, landing zone, and team muscle, while explicitly planning to optimize and selectively re-architect the high-value services in later phases rather than blocking the whole program on them. Keep the infrastructure as code from day one so the environment is reproducible and reviewable, and treat cost optimization as a scheduled phase, not a someday. Crucially, migrate in waves you can prove and roll back, so the business keeps running and confidence compounds. The teams that succeed treat migration as an incremental program with early value and honest tradeoffs — not a heroic cutover weekend.

How Infiniti Tech Partners runs cloud migrations

We run cloud migrations as pragmatic, phased programs that deliver value early instead of betting everything on a big-bang cutover. We start with honest discovery and assessment — what you have, what's actually used, and which of the 6 Rs each workload deserves — so you're not blindly rehosting things that should be retired or repurchased. We use lift-and-shift deliberately, to get you in fast and stabilized, then selectively re-architect only the high-traffic, elastic, strategic services where the payoff is concentrated, leaving the rest appropriately alone. We build on infrastructure as code from the first wave and treat cost optimization as a funded phase, so you actually capture the cloud's economics rather than paying cloud prices for on-prem habits. The result is a migration that gets you off the old world quickly, modernizes where it genuinely pays, and lands you with a cloud footprint that's cheaper, more elastic, and operable — without stalling your roadmap for two years.