A travel platform must move a portfolio of applications off ageing infrastructure. How should each application be assigned among rehost, replatform, refactor, rebuild, replace and retire?

The assignment logic

Start with retire. Measure actual usage. A meaningful proportion of an enterprise portfolio has almost none, and retiring is the cheapest possible migration. This should always be the first pass and it is frequently skipped because it feels like it is not doing the work.

Then replace. If the capability is commodity — identity, email, expense, monitoring — and a mature product exists, replacing avoids migrating something you should not own. The test is whether you would accept a competitor using the identical implementation.

Then rehost for applications that work, change rarely, and have no pressing constraint. Move them as they are. It buys the infrastructure objective quickly and defers the application question, which is legitimate when the application question has no urgency.

Then replatform where a bounded change unlocks disproportionate benefit — moving to a managed database, containerising, replacing a self-managed component with a service. Modest effort, real operational gain, no application redesign.

Then refactor or re-architect for the applications that are high value, change frequently, and are constrained by their current structure. This is expensive, so it must be reserved for where the cost of inaction is genuinely high.

Rebuild last and rarely. Only where the existing structure cannot support a capability the business needs and incremental change cannot get there.

The evidence that drives it

• Usage decides retire.
• Differentiation decides replace.
• Change frequency decides whether structure matters at all — a stable application's poor structure is costing nothing.
• Cost of inaction — incident rate, change lead time, features refused — decides whether refactoring earns its cost.
• Business sponsorship decides what is achievable, regardless of technical merit.

The mistake to avoid

Applying one strategy across the portfolio. A universal "lift and shift" moves the problem; a universal "re-architect everything" is unaffordable and unnecessary. The portfolio is heterogeneous and the strategy should be too.

And the second mistake: sequencing by technical interest rather than by risk and value. The most interesting application to re-architect is rarely the one whose modernisation returns most.