Disposition Decision
Choosing one of the standard migration treatments for each application, on the basis of its value, condition and the constraint that is actually binding.
The standard set: retire (switch it off), retain (leave it where it is, for now), rehost (move it unchanged), replatform (move it with targeted changes), repurchase (replace with a commercial product), and refactor or rearchitect (rebuild it).
The value of the framework is that it forces a decision on every application, including the ones nobody has complained about — which is where retire candidates hide.
How to choose, in practice:
Retire anything with negligible use. Establish usage from evidence; every system has an advocate whose description of its importance exceeds its logs.
Retain where the business case does not justify movement yet, or where a dependency must move first. This is a legitimate decision and should be recorded with a review date rather than treated as failure.
Rehost where the driver is time or a data-centre exit. Fast, low risk, and it carries the existing inefficiencies forward — including the cost profile, which frequently rises.
Replatform where a targeted change removes a disproportionate burden — a self-managed database to a managed one being the usual example.
Repurchase where the capability is context rather than core.
Refactor only where the capability is genuinely differentiating and the current implementation blocks the business. It is the most expensive option by a wide margin and is chosen far more often than it is justified.