Lift and Shift, Replatform or Refactor: Picking a Migration Path

Rehost most of the estate, replatform the database and anything else where a managed service genuinely removes work you are bad at, refactor only the one or two systems that make you money, and retire more than you think you can. That split, applied to a typical thirty-server estate, gets you off the hardware inside a quarter without betting the company on a rewrite.

The seven options, in plain English

The vocabulary comes from AWS’s prescriptive guidance, which builds on Gartner’s earlier work, and it is worth using because everyone in the industry recognises it.

• Rehost — lift and shift. Move the server as it is, no changes.
• Relocate — hypervisor-level lift and shift. Move the virtual machines without new hardware, rewrites or changes to operations.
• Replatform — lift and reshape. Move the application and swap one component for a managed equivalent, typically the database.
• Repurchase — drop and shop. Replace the thing with a SaaS product and stop running it at all.
• Refactor — re-architect. Rewrite around cloud-native services to change what the system can do.
• Retire — switch it off. Nobody has logged in since 2021.
• Retain — leave it where it is, deliberately, and revisit later.

One line in that guidance deserves attention because it contradicts a lot of consulting advice: AWS states that refactor is not recommended for large migrations, because it means modernising the application while you are moving it. Two hard problems at once, with one deadline. If a rewrite is genuinely needed, do it after the move, when you can measure the before and after.

What each path costs to execute

The tooling costs almost nothing, which surprises people who have been quoted a migration project. The expensive parts are the testing, the cutover windows and the weeks of attention, none of which appear on a vendor price list.

Read the free-period detail carefully on the AWS side, because it is not quite free: while source servers are replicating, including during the 90-day window, you pay for the AWS infrastructure that MGN provisions to carry out the replication. That is usually tens of dollars rather than hundreds, but it belongs in the estimate.

Rehost is the right default, and not a lazy one

Lift and shift has a reputation for being the unambitious option. In practice it is the only strategy that lets you separate two questions that are otherwise tangled together: does this run correctly somewhere else, and is this designed well? Answer the first, get off the hardware, then answer the second with real production data in front of you.

The honest downside is that a rehosted server arrives in the cloud carrying every bad habit it had before: over-provisioned memory, a patch level from two years ago, a cron job nobody understands. If you rehost and stop, your bill will be higher than your old hosting invoice and the cloud will get the blame. Rehosting is a first step, not a destination, and the follow-up is the rightsizing and commitment work we cover in our comparison of commitment discounts.

Replatform: what the managed service premium really is

Replatforming usually means handing a component to the provider, and the database is almost always the first candidate. The trade is visible in the price list. In West Europe, a general-purpose managed PostgreSQL Flexible Server with four vCores lists at $0.424 an hour, while the Standard_D4s_v5 virtual machine you would run PostgreSQL on yourself is $0.23 an hour. Both figures come from Microsoft’s retail prices API in October 2026.

That $142 a month is the question in one number. If your team currently spends more than two hours a month on database patching, backup verification and the occasional 2 a.m. failover, the managed service is cheaper in the only currency that matters. If you have a database administrator who enjoys the work and the server has run for four years without incident, keeping it is a defensible choice.

The same arithmetic applies to message queues, caches, search indexes and container orchestration. Price the managed option, estimate the hours it removes, and decide with the two numbers side by side. Our guide to IaaS, PaaS and SaaS sets out where the responsibility boundary sits in each case.

Refactor: narrow, expensive and sometimes correct

Refactoring is the only strategy that changes what your product can do, which is why it is tempting and why it overruns. It is the right call in a narrow set of cases: when the current design physically cannot meet a business requirement, when licensing makes the status quo untenable, or when the system is the thing you compete on and the architecture is holding it back.

It is the wrong call when the motivation is tidiness, when the team has not run the technology in production before, or when it is bundled into a migration with a fixed deadline. AWS’s guidance makes the last point for us: refactoring is not recommended during large migrations precisely because it couples two risky programmes together.

Retire and retain, the two everybody skips

Every estate contains servers nobody needs. In our experience somewhere between 10% and 20% of a long-lived estate can simply be switched off, and the work is almost entirely social rather than technical: find the owner, give notice, shut it down for a week, see whether anyone complains.

Retain is the other underused option. Some systems should not move yet: a licence that expires in eight months, an appliance with a hardware dongle, a regulated workload waiting on an approval. Writing retain next to a server and a revisit date is a decision. Leaving it off the plan entirely is how migrations end up with a forgotten rack in a colocation facility that bills for three more years.

Sequencing a thirty-server estate

Here is how we would sort thirty servers in a first pass, and roughly what each group gets. The exact split varies, but the shape is consistent across the estates we see.

Note what goes first: the environments where a mistake costs nothing. By the time you reach the customer-facing systems you have rehearsed the process eight times and the cutover is boring. Note also that the region decision sits underneath all of this, because moving twice is expensive — how to choose a cloud region covers that choice, and the introduction to cloud technology covers the groundwork.

Eudora Technology plans and runs these migrations remotely, including the inventory work, the cutover rehearsals and the month-after rightsizing that decides whether the project looks like a success on the invoice. Our cloud solutions page describes how we structure it, and our provider comparison helps if the target is not settled yet.

If you have an estate to move and no clear view of which servers belong in which group, we can do the inventory and hand you a sequenced plan. Get in touch with Eudora Technology to talk about your project.