TCP #137: The migration strategy meeting that never needed to be a meeting.
Four questions that sort any workload into rehost, replatform, refactor, repurchase, retain, or retire, before the debate starts.
Every migration program hits the same wall.
Someone opens the workload inventory, points at application one, and asks: rehost, replatform, or refactor?
The room debates for forty minutes. They land on an answer.
Then they point at application two, and the debate starts over, because nobody wrote down why they chose what they chose for application one.
Multiply that by 200 applications, and you get a migration program that spends its first quarter in conference rooms instead of moving workloads.
The strategy debate is not the hard part of migration.
It only feels that way because most teams run it as an open discussion instead of a decision tree.
The 6 R’s (rehost, replatform, refactor, repurchase, retain, retire) are not opinions to argue per workload.
They’re the output of four questions, asked in a fixed order.
Skip the order, and you get the meeting that repeats itself 200 times.
Why the Wrong R Costs More Than the Migration
Picking the wrong strategy rarely fails loudly. It fails as a slow leak you notice two quarters later.
Refactor a workload that should have been a simple rehost, and you’ve spent six months of senior engineering time re‑architecting an application nobody asked to modernize. Meanwhile, the business misses a data center exit you could have hit with a lift‑and‑shift.
Rehost a workload that should have been retired, and you’ve paid to move an app three people still use. Once it’s “already migrated,” nobody revisits it. You’ve made a zombie workload immortal.
The cost isn’t just engineering time. It’s factory throughput.
A factory tuned for rehost velocity chokes on refactor‑sized workloads.
A factory that treats everything as bespoke refactor never hits the wave‑based timelines the business signed up for.
Wrong R’s compound:
Your best engineers get stuck on work that didn’t need them.
The workloads that do need refactor never get the attention or budget.
Migration budgets are approved once, based on an assumed strategy mix. When the mix is wrong, the budget doesn’t stretch. It just runs out before the portfolio is done.
Why Smart Teams Default to Refactor or Rehost
Two patterns explain most bad decisions. Both come from forcing a whole portfolio through one mental model.
Modernization bias
Architects who care about “doing it right” default to refactor, because that’s where the interesting engineering lives. A stable, low‑change, “good enough” app still gets nominated for re‑architecture, not because the business needs it, but because it’s more satisfying than rehosting.Deadline bias
Teams under a hard exit deadline default everything to rehost because it’s fast and predictable. Workloads that genuinely need refactoring get lifted and shifted in their brittle state, now with cloud spend on top of the technical debt.
Both biases share a root cause: strategy is being chosen from one vantage point (architect or program manager), not from the four questions that actually govern the right R.
The Four Questions That Sort Any Workload
Ask these in order. The order matters. Each question eliminates options before the next one.
1. Does the business still need this workload?
If usage is near zero, or it exists only because no one decommissioned it, retire beats every other option.
This comes first because retirement is the only R that shrinks your migration backlog. Every workload retired here is one the factory never touches.
2. Is there a commercial replacement that does this better?
If the workload is a homegrown system duplicating what a SaaS or managed product already does, repurchase often beats refactor or rehost.
This comes second because it can eliminate big, hairy workloads before you burn cycles estimating them.
3. Does it need to change, or just move?
If requirements, performance, and architecture are “good enough,” rehost or replatform gets you to cloud fastest.
Rehost: move as‑is when change doesn’t pay for itself.
Replatform: swap obvious managed services (e.g., self‑managed DB to RDS) when the operational savings justify it.
If there’s a real business reason to change (scalability limiting revenue, licensing that dies in cloud, compliance gaps), that’s the signal for refactor.
4. Does the deadline allow the strategy this workload actually needs?
This is a check, not a chooser.
If 1–3 say “refactor” and the data center exit is in 12 weeks, that conflict gets escalated. The business chooses: move the deadline or consciously downgrade the strategy.
Do not let the schedule silently pick a lesser strategy and pretend nothing changed.
Run every workload through these four and the R mostly picks itself. The 40‑minute debate collapses to four questions, many of which your CMDB already answers.
What a Portfolio Run Through This Tree Looks Like
Programs that apply these four questions consistently get a strategy mix, not a never‑ending strategy debate.
That mix is what the migration factory needs to:
Plan capacity
Sequence waves
Forecast cost and timelines
What changes:
Retire and repurchase decisions happen before wave planning, shrinking the portfolio.
Rehost and replatform carry most of the volume on a predictable, assembly‑line cadence.
Refactor is reserved for the few workloads where the business case genuinely justifies it, staffed with the senior engineers who should be there.
The visible outcome:
Portfolio reviews that used to run for weeks compress into days.
Strategy per workload becomes a lookup, not a debate.
Engineering time that used to be spent re‑litigating strategy goes into moving workloads.
That’s the leadership payoff: not a cuter framework, but a portfolio that stops arguing with itself and starts moving.
That’s it for today!
Did you enjoy this newsletter issue?
Share with your friends, colleagues, and your favorite social media platform.
Until next week — Amrut
Get in touch
You can find me on LinkedIn or X.
If you would like to request a topic to read, please feel free to contact me directly via LinkedIn or X.