Rehost, replatform or rebuild?

Every migration eventually comes down to a decision made per workload: move it as it is, change it a little on the way, or rewrite it. The names vary (lift and shift, rehost, replatform, refactor, rebuild) but the choice is the same, and it is usually made too early and too uniformly.

The useful framing is not "which approach is best" but "what does this particular workload need, and what does the business need from it in the next eighteen months".

The three options, plainly

Rehost moves the workload onto cloud infrastructure with as few changes as possible. A virtual machine becomes a virtual machine. The operating system, the application and the configuration all come across largely intact.

Replatform keeps the application essentially the same but swaps some of what sits underneath it for a managed service. The most common version is moving a self-managed database onto the platform's managed database service, leaving the application code untouched or nearly so.

Rebuild rewrites the workload to suit the platform, usually meaning managed services, smaller deployable units and a different operational model.

There is a fourth option that gets forgotten: retire. On most estates a meaningful number of workloads are running because nobody has confirmed they can be switched off. Confirming that is cheaper than migrating them.

What actually drives the decision

How much time you have

If there is a hard date (a lease ending, a contract expiring, hardware going out of support), rehost is usually the answer for most of the estate. It is the fastest path and the one with the fewest unknowns. You can replatform afterwards, once the deadline is behind you.

Teams that try to modernise under deadline pressure tend to do both badly.

Whether the application is changing anyway

If a workload is already under active development, replatforming it costs less than it appears to, because the team is in the code and has the context. If nobody has touched it in three years and the people who wrote it have left, every change is expensive and risky.

The best rebuild candidates are usually applications already scheduled for significant work. The migration becomes part of that work rather than a separate project competing with it.

What the workload costs to run and operate

A rehosted virtual machine still needs patching, backup, monitoring and someone to look after the operating system. Moving it to the cloud does not remove that work; it just changes where it happens.

Replatforming a database onto a managed service removes a genuine, recurring operational burden. That is often worth more than the infrastructure saving, and it is the reason replatforming the data tier is frequently the best value change in a migration.

Licensing

Licensing frequently decides the question, and it is often discovered late. Some licences are tied to physical cores, some change cost dramatically on cloud infrastructure, and some do not permit it at all. Check before you design, not after.

A workable default

For most estates, a reasonable starting position looks like this:

• Rehost by default. It is predictable, it is reversible, and it gets you off the hardware.
• Replatform the data tier where it is straightforward. Managed databases remove real operational work and the application usually does not need to know.
• Rebuild only where there is an independent reason to. The application is being rewritten anyway, or its current form genuinely prevents something the business needs.
• Retire what nobody uses. Confirm rather than assume, but confirm.

This is deliberately conservative. Migration projects fail more often from taking on too much change at once than from being insufficiently ambitious.

The cost trap in rehosting

Rehosting has a well-known failure mode: you move a workload sized for hardware you bought five years ago onto infrastructure you now rent by the hour, and the bill is higher than the depreciation was.

On-premises servers were usually specified for peak load plus headroom plus a margin for the procurement cycle. That specification makes no sense when capacity can be changed in minutes.

Right-size after the move, not during it. Measure real usage for a few weeks under normal load, then adjust. Doing it during the migration means you are changing two things at once and cannot tell which one caused the problem.

Questions worth asking per workload

Before deciding, get short answers to these:

1. What breaks if this is unavailable for four hours? For a day?
2. Who supports it now, and will they still be here next year?
3. When was it last patched, and can it be patched?
4. What does it talk to, and what talks to it?
5. Is the licence portable?
6. Is anyone actually using it?

The last one closes more migration items than any technical analysis.

Sequencing

Start with something real but not critical. A workload with genuine users and genuine dependencies, but where a bad afternoon is survivable. This surfaces the problems in your process (network paths, identity, monitoring gaps, change control) while the stakes are low.

Do not start with the easiest possible workload, because it teaches you nothing. Do not start with the most critical one either.

Then group the rest by dependency rather than by convenience. Applications that share a database or talk to each other constantly should move together or in quick succession; splitting them across a long migration window means running traffic between two environments for months, which is slow, expensive and fragile.

The honest summary

Most estates end up mostly rehosted, with the data tier replatformed and a small number of applications rebuilt because there was already a reason to rebuild them. That is not a failure of ambition. It is what happens when the decision is made per workload, on evidence, rather than as a single strategy applied to everything.