The question this answers
For this specific component, is the right move to lift it, adjust it, rewrite it, leave it, or delete it?
The dependency map from discovery lists thirty-one components. A single strategy applied to all thirty-one will be wrong for most of them: some are trivial to lift, some are the reason the platform is slow, two have not received a request in ninety days.
A per-component decision with an explicit effort, risk and benefit, so the migration plan is a set of justified choices rather than one policy applied uniformly.
Five choices, per component
Rehost moves the component essentially unchanged onto cloud infrastructure — the same operating system, the same processes, a virtual machine instead of a physical one. Lowest effort, lowest risk, no architectural improvement, and it carries the old sizing and the old operational model with it. Replatform makes targeted changes that trade the parts with the worst operational cost for managed equivalents: the self-managed database becomes a managed one, the file share becomes object storage, the init scripts become a container image. Same application code, much better operations. Refactor changes the application itself to suit the new environment — decomposition, statelessness, a different data store. Highest effort, highest risk, and the only option that actually removes an architectural problem.
Retain is the decision to leave it where it is, deliberately and with a recorded reason: a hardware licence, a physical dependency, a system already scheduled for replacement, or simply a component where moving costs more than it returns. Retain is a decision, not a failure to decide, and the difference is whether it is written down with an owner and a review date. Retire is the decision to switch it off. It is the only one of the five with a negative ongoing cost, and it is systematically under-used.
These are decisions, not a certification vocabulary. Different consultancies and providers group and name them differently, add a sixth for buying a product instead, or split refactoring in two. The names matter far less than the discipline of making the choice per component and recording the reason — a migration plan that says "we are rehosting" applied to thirty-one heterogeneous components is not a plan, it is a way of avoiding thirty-one conversations.
| Disposition | Effort | Risk | Benefit | Choose it when |
|---|---|---|---|---|
| Retire | Very low | Low — if usage was measured | Very high — removes cost, risk and surface permanently | Nothing has used it in a full business cycle and an owner confirms it |
| Retain | None | Low | Avoids spending on a move with no return | A physical, licence or timing constraint makes moving uneconomic — recorded, with a review date |
| Rehost | Low | Low | Low — exits the facility, changes nothing else | A deadline forces the move and the component is stable and unremarkable |
| Replatform | Medium | Medium | High — removes the worst operational burden | Self-managed infrastructure around the app is the real pain, not the app itself |
| Refactor | High | High | High, eventually — removes the architectural problem | The component is a genuine constraint on the business and will be invested in anyway |
Retire is the one nobody puts on the plan
In an estate that has been running for a decade, a meaningful fraction of components are serving nobody. A reporting service replaced by a dashboard two years ago and never switched off. A staging environment for a product that was discontinued. An integration with a partner whose contract ended. A "fax gateway" that has not accepted a connection in ninety days. Each of these has a server, a certificate, a backup job, a monitoring alert, a set of credentials and a place in someone's on-call rotation.
Retiring one of them returns more than migrating it ever could: it removes the migration effort, the ongoing infrastructure cost, the patching obligation, the attack surface and the on-call noise, permanently. It is the only disposition where the ongoing cost goes negative. And it is under-used for an entirely human reason — nobody wants to be the person who switched off the thing that turned out to matter.
So make it safe to do. Measure usage over a full business cycle rather than a fortnight. Find a named owner and get an explicit confirmation. Then stage the retirement: disable and observe for a period with the ability to re-enable in minutes, and only after that delete the resources and archive the data. The intermediate stage is what converts a scary irreversible decision into a reversible one, and it is why "turn it off and see who screams" is a genuinely good technique when it has a rollback attached.
migration_plan: strategy: rehost-everything rationale: "fastest path off the lease" components: 31 # every component gets a like-for-like VM # sizing: match existing hardware # outcome: 31 VMs sized for 2019 peak, billed monthly, # including 2 nothing has called in 90 days # and 1 whose database was the actual bottleneck
migration_plan:
components:
- name: fax-gateway
disposition: retire
evidence: "0 connections in 90d; owner confirmed 2026-02-14"
stage: "disabled 30d, then delete + archive"
- name: discontinued-product-staging
disposition: retire
evidence: "product sunset 2024-11; no owner claims it"
- name: label-printer-controller
disposition: retain
reason: "serial link to floor hardware; licence bound to host"
review: 2027-06
- name: order-api
disposition: rehost
reason: "stable, unremarkable, lease deadline"
then: "right-size after 30d of real metrics"
- name: order-db
disposition: replatform
reason: "self-managed patching and backups are the real burden"
to: "managed database, same engine and major version"
- name: settlement-batch
disposition: refactor
reason: "single-host cron is the constraint on close time"
risk: "highest in the programme; do it last, not first"The second plan is longer because it contains thirty-one decisions instead of one. It also deletes two components before paying to move them, avoids re-provisioning 2019 sizing forever, and puts the highest-risk item last rather than first — where a failure would stall the whole programme.
Sequencing, and the trap of modernizing mid-move
Once each component has a disposition, the order follows from risk and dependency. Retire first: it is free progress and shrinks everything downstream. Then move the low-risk rehosts and replatforms in dependency order, which builds confidence and proves the toolchain on real workloads. Leave refactors for last, or better still for after the migration is complete — because a refactor during a move means that when something breaks, you cannot tell whether the cause was the new environment or the new code.
That is the core argument against modernizing mid-migration, and it is worth stating plainly because the opposite instinct is very strong. "We are touching it anyway, so let us fix it" doubles the variables in a change whose whole purpose is to be verifiable. Move first, establish that behaviour is equivalent against the criteria you agreed, then improve with a working baseline to compare against. The exception is a component whose current form genuinely cannot run in the target environment at all — then the refactor is not optional and should be scoped as its own project rather than smuggled into the migration.
The second sequencing trap is deferring the right-sizing that rehosting makes necessary. Rehost is a legitimate choice under deadline pressure, but it converts a capital asset sized for a 2019 peak into a monthly bill sized for a 2019 peak. Attach the right-sizing to the plan with a date — thirty days of real metrics, then resize — or the temporary inefficiency becomes the permanent architecture. See Right-Sizing Without Causing an Outage and Idle Capacity: Headroom or Waste?.
component usage (90d) owner disposition why / accepted cost ---------------------- ------------ ----------- ------------ ----------------------------- fax-gateway 0 conns none found RETIRE stage 30d disabled, then delete prod-x staging 0 conns none found RETIRE product sunset 2024-11 label-printer-ctrl constant operations RETAIN serial hardware; review 2027-06 order-api 1.2k rpm orders REHOST deadline; resize after 30d order-db 1.2k rpm orders REPLATFORM managed engine; accept less tuning reporting-svc 4 req/day finance REPLATFORM scheduled job, not a service settlement-batch nightly finance REFACTOR close time is a business constraint legacy-sso-shim constant security RETAIN replaced by IdP project Q3; review 2 retired before moving. 2 retained with a review date. The only refactor is the one with a business reason, and it is scheduled last.
Key points
- Five dispositions — rehost, replatform, refactor, retain, retire — assigned per component, never as one policy across an estate.
- Retire has the highest return of the five and is the most under-used; measure usage over a full cycle, confirm an owner, then stage it.
- Retain is a decision and needs a recorded reason, an owner and a review date — otherwise it is just an omission.
- Rehost is legitimate under deadline pressure, but it carries yesterday's sizing into a monthly bill unless right-sizing is scheduled.
- Replatform usually has the best effort-to-benefit ratio: same application, far less operational burden.
- Do not refactor during the move; it doubles the variables in a change whose purpose is verifiability.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • Each component from the dependency map is scored on usage over a full business cycle, owner, technical constraints and business value.
- • Zero measured usage plus a confirming owner routes to retire; a physical, licence or timing constraint routes to retain.
- • Everything else is sorted by where the pain is: in the surrounding infrastructure it is replatform, in the application itself it is refactor, and nowhere in particular it is rehost.
- • Each decision is recorded with its reason and its accepted cost, so a future reader knows whether it still applies.
- • The plan is sequenced retire → low-risk rehost/replatform → high-risk refactor, in dependency order within each band.
- • You own the disposition record as a living document — a decision made against 2026 constraints needs revisiting when they change.
- • You own the follow-through on rehosts: the right-sizing pass, on a date, or the inefficiency becomes permanent.
- • You own the retain reviews, so "we will move it later" does not silently become "we never revisited it".
- • You own the staged retirement window, including the ability to re-enable quickly and the archive of the data.
- • After a replatform, you own less than before but not nothing: the schema, the queries, the capacity choice and the bill remain yours. See Managed vs Self-Hosted.
- • One disposition applied to the whole estate, producing thirty-one wrong-sized virtual machines and two migrations of components nobody uses.
- • Retirement based on a two-week usage sample, deleting a component whose only job runs monthly.
- • A refactor undertaken during the move, so a failure has two possible causes and the rollback is ambiguous.
- • Rehosting without the follow-up right-sizing, converting an amortized capital asset into a permanent monthly overcharge.
- • A replatform to a managed service with different behaviour — a different default isolation level, a different backup semantics — validated only against "it starts".
- • Retain with no owner and no review date, which is indistinguishable from having forgotten about it.
- • Decision effort scales linearly with component count, which is why retiring early shrinks everything that follows.
- • Refactor effort scales with coupling, not with size — a small component with fifteen callers is harder than a large one with two.
- • Replatform effort scales with how much the managed equivalent differs in behaviour, not with data volume.
- • A programme's risk is concentrated in a handful of refactors; sequencing them last keeps the rest of the plan movable.
- • Retiring a component removes an attack surface permanently — the highest-value security outcome available in a migration.
- • Rehosting carries the old security posture across unchanged, including static credentials and an operating system nobody has patched.
- • Replatforming to a managed service shifts patching to the provider but hands you a new access-control model to configure correctly.
- • Retained components stay on the old estate and must keep receiving patches and attention after the team's focus has moved on — this is where forgotten systems get compromised.
- • Archive retired data rather than deleting it blindly; retention obligations survive the system that produced the data.
- • Retire is the only disposition with a negative ongoing cost, and the saving compounds every month.
- • Rehost is cheapest to execute and most expensive to run, because it preserves the old sizing.
- • Replatform costs project time once and reduces operational cost permanently — usually the best return of the five.
- • Refactor is the most expensive by a wide margin and only pays back when the component is a genuine business constraint.
- • Retain avoids a migration cost but keeps a fixed on-premises cost and a support obligation on the books.
- • Usage per component over a full business cycle — the evidence base for every retire decision.
- • Owner coverage: components with no identified owner are simultaneously retirement candidates and the largest risk in the plan.
- • Post-rehost utilization, which is what makes the right-sizing conversation concrete rather than theoretical.
- • Behavioural equivalence after a replatform: same results, same batch windows, same error rates — not just a healthy endpoint.
- • The signal that lies: a component that looks busy because monitoring polls it every thirty seconds. Exclude your own health checks before declaring anything in use.
- • Replace with a purchased product. For commodity capabilities — email relay, file transfer, identity, monitoring — buying is frequently cheaper than any of the five, and it is the sixth option most lists omit.
- • Retire is itself the alternative most plans skip. Before choosing between the other four, prove the component is used at all.
- • Do nothing for now: retain the whole estate and revisit when the constraint that would force a move actually arrives.
- • Rehost as a deliberate holding action, with replatform scheduled as a separate project once the deadline pressure is gone — two small changes are safer than one large one.
- • Rehost buys speed and low risk; costs an inefficient shape and no improvement in operations.
- • Replatform buys a large reduction in operational burden; costs behavioural differences that must be found in testing rather than in production.
- • Refactor buys the removal of a real constraint; costs the most time and carries the most risk of any option here.
- • Retire buys permanent savings; costs the small but real risk of switching off something that mattered — which staging is designed to bound.
What people believe, and what is true
Rehosting is the lazy option and refactoring is the right one.
Refactoring during a migration is the highest-risk choice available, and it is right only for components that are genuine business constraints. Rehost-then-improve is frequently the more professional plan.
Everything should end up on managed services.
Replatform is usually excellent, but a component with an unusual configuration requirement, an unsupported extension or a hard licence constraint may be worse off managed. Decide per component.
Retiring things is a nice-to-have we will do afterwards.
Afterwards never comes, and by then you have paid to migrate, validate and re-platform something nobody uses. Retirement is the first phase of the plan, not the last.