Skip to content

Decision guide · Cloud migration

Moving to the cloud is not one decision. It is many.

A migration mandate tells a team to move. It does not tell them what to move first, what to leave, or what changes once it lands.

A mandate is not a plan.

“Move to the cloud” is a direction, not a decision. The actual decisions happen system by system: whether a workload should move as-is, be adjusted for its new environment, be replaced outright, or stay exactly where it is for now.

Treating migration as one enterprise-wide project usually produces one of two outcomes - a stalled initiative that never reaches the harder systems, or a rushed one that moves everything on the same timeline regardless of risk or readiness.

The useful question is not “are we cloud-first.” It is: for this system, does moving it change cost, risk, ownership, or capability in a way leadership actually wants - and can the organization absorb that change now?

Working test

For any system on the list, can someone name which of four migration patterns applies to it, and why?

Four patterns

Every system fits one pattern - until evidence says otherwise.

PatternFits whenWhat changesWatch for
RetainThe system is stable, low-risk, and moving it would cost more than the benefit.Little - the decision itself is the useful record.“Retain” becoming “forgotten” with no review date.
RehostTiming is tight and the workload can run on new infrastructure largely unchanged.Where it runs; not how it is administered or supported.Carrying old operating problems into a new environment.
ReplatformModest adjustment unlocks real operating or cost benefit without a full rebuild.Administration, integration points, and some operating cost.Scope creep toward a full replacement mid-project.
ReplaceA cloud-native or SaaS alternative genuinely fits better than the current system.The application, the data model, and often the vendor relationship.Underestimating migration, training, and parallel-run cost.

Deciding the sequence

Classify before you schedule.

A date-driven plan without this sequence tends to move the easiest systems first and the highest-risk systems last - often the reverse of what business consequence would suggest.

  1. Inventory and classify

    List systems, owners, dependencies, contract dates, and a first-pass pattern for each.

  2. Test dependencies

    Identity, data flows, integrations, and compliance obligations that would block or reorder a move.

  3. Sequence by risk and reversibility

    Move what is reversible and well-understood first; hold what is fragile or poorly understood until evidence improves.

  4. Set the operating change

    Confirm who administers, supports, and pays for each system once it lands - before, not after, cutover.

Decision examples

The pattern rarely announces itself.

i.Ownership

A line-of-business application with no clear technical owner

Resolve who accepts operating responsibility before choosing rehost, replatform, or replace.

ii.Support risk

A file or application server nearing end of vendor support

A support deadline forces timing; it should not silently decide the pattern as well.

iii.Contract

A platform under a multi-year contract with an early-exit penalty

Compare the penalty, the remaining term, and the cost of waiting against the cost of moving now.

The decision does not end at cutover

Migration changes who owns the system.

Moving infrastructure or a platform usually changes administration, support routing, and cost structure - even when the workload itself looks unchanged to its users. That ownership question deserves the same explicit decision as the migration pattern.

See how ownership decisions get made

Next step

Bring the system nobody wants to schedule.

Name the workload, the pressure behind the timeline, and who currently owns it - that is enough to start.