Ask two experienced people whether to rehost a workload or rewrite it and you will get an argument about taste. One says a straight lift-and-shift wastes the migration and buys your old problems back at cloud prices. The other says rewrites are a fantasy that gets funded once and delivered never. Both are describing real failures they have watched happen. Neither is a way of deciding anything.
The question isn't answerable for an estate. It is answerable for a workload, and the variable that decides it isn't technical.
The deciding variable is remaining commercial life
How long is this workload going to matter, and is it going to change while it does?
A workload with eighteen months left and no roadmap is not a re-architecture candidate, however ugly it is. A workload the business intends to build on for the next five years is not a rehost candidate, however well it runs today. The technical assessment tells you the price of each option: how tangled the dependencies are, where state lives, what breaks if latency doubles. It does not tell you which option to buy. That comes from the commercial life, and it usually lives with someone who was not invited to the migration workshop.
This is why triage stalls in so many programmes. The technical assessment gets done thoroughly, and then the decision gets made on preference, because the input that would have settled it never arrived.
Retire first
Every migration programme finds workloads nobody needs. The cheapest workload to migrate is the one you switch off, and running that pass before anything else shrinks every estimate that follows.
The obstacle is never technical. Switching something off requires a named person to say out loud that they don't need it, which is a harder sentence to say than it looks. Take the risk out of saying it: stop the service, keep the backup, delete the backup after ninety days. If nobody has called by then, the workload was as unloved as it looked. If someone does call, you can put it back the same afternoon.
Four moves, and when each one is right
Retire where nobody needs it. Do this pass first, and repeat it when the migration is half done, because a second sweep always finds more.
Rehost where the workload is stable and unloved, with a known end date, or where a datacentre exit clock is running and the clock outranks the elegance.
Replatform where a managed service removes operational toil without a code change. SQL Server onto Azure SQL Managed Instance, a self-hosted broker onto Service Bus, a hand-patched web tier onto App Service. This is the best return per unit of risk in most estates, and the option that gets skipped most often, because rewrites are more interesting to talk about than swapping who patches the thing at 2am.
Re-architect where the workload sits on a growth path, where the business wants to change it anyway, or where the scaling economics are already broken. Re-architecting a stable, low-change workload is engineering as a hobby, funded by someone who thinks they are buying a business outcome.
The same judgement applies one level down, to the target as well as the move. Not everything deserves Kubernetes. AKS earns its operational cost for services with real scaling demands and a team that owns them, and a great deal of what gets pushed into clusters by default would be happier as Functions or managed PaaS, with nobody on call for a control plane.
The move is legitimate. The silence afterwards isn't
Lift-and-shift is a legitimate move with a written end date and a liability without one.
Rehosting with no follow-up is the most reliable way for a cloud programme to lose its business case. The estate lands in Azure at roughly what it cost in the datacentre, sometimes more, because a VM sized against a five-year hardware refresh is the wrong shape for consumption billing. Everyone knew that at the time. The savings were always going to arrive in phase two, when the rehosted workloads were replatformed properly.
Phase two rarely gets scheduled. The programme that promised it closes, its plan becomes a document nobody opens, and the people who understood the intent move on. What remains is a subscription full of VMs with no stated future, which is indistinguishable from a subscription full of VMs somebody chose.
Make the end date something the estate can answer
A date in a migration plan is a sentence in a file. A date on the resource is a fact you can query.
tags = {
owner = "payments"
migration = "rehost"
review_by = "2027-03-31"
}
That single tag turns "which rehosted workloads are past their date" from an archaeology project into a query you can run in a Monday meeting. Pair it with a policy that audits virtual machines arriving without one and the estate stops quietly accumulating undated debt. Neither piece is clever. The value is that the answer outlives the people who knew it.
The other half of making it real is how the workload lands. Phase two usually fails for a duller reason than lost will: the rehosted workload arrived as a click, so every later change to it is priced at hand-built prices. Nobody is certain what it depends on, no change to it is reviewable, and the replatform gets quoted as a project with a discovery phase bolted to the front.
Bring the workload over as code and the same change is a diff. Swapping a VM's self-managed database for a managed instance becomes a pull request against a file that already describes the workload, read by someone who can see the whole thing in one screen. The distance between rehost and replatform stops being a programme and becomes an edit, which is the only version of phase two that ever happens.
That is the argument for insisting the migration output is Terraform rather than a wave of portal work with a spreadsheet tracking it. Code is what keeps the cheap move cheap to reverse.
Sequencing, and the constraint that keeps it honest
Landing-zone readiness comes before volume. Migrating forty workloads into a governance model you are about to change means doing it twice, and the second time is done under the pressure of a live estate. Settle policy, network, identity and tagging on the first few, then open the taps.
Order the waves by risk rather than by enthusiasm. Lowest-risk stateless workloads first, to prove the pattern and build the team's muscle, then the hard tail once the pattern is known rather than hoped for.
What stops this being a matter of nerve is an error budget. Define SLOs on the critical user journeys, agree the budget policy with product leadership before the first incident rather than during it, and the migration becomes accountable to a measurable stability constraint. When the budget burns, migration slows and reliability work takes priority, and nobody has to win an argument for that to happen. It is how you migrate quickly while production stays solid, without those two goals being settled by whoever is most senior in the room.
Every workload gets one of four answers, and every rehost gets a date. An estate where both of those are true can be handed to someone else without a briefing, which is a fair definition of a migration that worked.
The tag policy and the Resource Graph queries are in the blog-examples repo.
More useful tidbits coming — one a week.