Of the six migration strategies, which is most often skipped and why does that matter?

What is being tested

Whether you know where the largest and cheapest saving in a migration programme sits, and why it is routinely left on the table.

The six

Rehost (lift and shift), replatform (targeted changes), refactor/re-architect, repurchase (replace with SaaS), retire, retain.

The decision is per workload, not per programme — a portfolio typically uses four of the six.

Why retire is skipped

There is no launch, no feature, and a small risk of breaking something. Nobody's promotion case includes "switched off fourteen systems". Meanwhile every one of those systems costs licences, infrastructure, patching, security review and a share of attention, indefinitely.

Ten to twenty per cent of a typical portfolio retires on inspection. That is the cheapest win available in any migration programme, and it also reduces the scope of everything that follows — you do not migrate what you delete.

What makes it happen

• A named owner for the retirement, with time allocated.
• Consumer identification from usage data, not assumptions. This is where the real work is, and traffic data answers it definitively.
• A migration path for the consumers who remain.
• Explicit budget, or it competes with features and loses every time.
• "Systems retired" tracked as a metric with the same visibility as systems delivered.

The technique that makes it safe

Disable before deleting. Stop the workload, remove it from routing, and leave it for a period. If something breaks, restoring is immediate — which converts an irreversible action into a reversible one and is worth the extra time.

And verify before deleting: a workload with no traffic may be a disaster recovery standby, a quarterly job, a compliance archive, or a break-glass path used once a year. Deleting one of those is how a rationalisation programme loses its mandate permanently.