Before You Approve a Cloud Migration

A cloud migration can move a workload without transforming the business.

The servers move.

The applications move.

The data moves.

The operating model stays the same.

The organisation then expects cloud benefits to appear automatically.

They do not.

Before approving a cloud migration, ask a more important question:

What business capability will be better after migration, and how will we measure the improvement?

Start with the outcome

Do not begin with the destination.

Begin with the capability.

Is the objective:

Faster deployment?

Better reliability?

Stronger security?

Better customer experience?

Higher developer productivity?

Greater cost transparency?

Improved resilience?

If the expected improvement is unclear, the migration case needs more work.

Decide what happens to each workload

Not every workload needs the same migration strategy.

Consider six patterns:

Rehost

Move the workload with minimal change.

Replatform

Make limited platform improvements during migration.

Refactor

Redesign the application to improve its architecture.

Retire

Remove capability the organisation no longer needs.

Replace

Adopt a new product or service instead of migrating the existing workload.

Retain

Keep the workload where it is because there is a valid business or technical reason.

The right answer may differ across the portfolio.

Do not confuse movement with transformation

Rehosting can be the right decision.

Speed may matter.

A data-centre exit may have a fixed deadline.

A contract may be ending.

The problem starts when rehosting is expected to deliver cloud-native benefits automatically.

Moving an application does not automatically improve:

Architecture

Operating model

Resilience

Delivery speed

Economics

Business capability

The migration strategy needs to match the intended outcome.

Consider the operating model

Cloud transformation requires more than infrastructure.

Consider:

Platform teams

Product-oriented ownership

Automated delivery

Standard landing zones

Observability

Security guardrails

FinOps practices

If the organisation moves workloads without changing how those workloads are operated, some expected cloud benefits may not materialise.

Treat resilience as an architectural decision

Cloud does not automatically create resilience.

Define:

Recovery time objective

Recovery point objective

Regional redundancy

Dependency mapping

Recovery testing

The resilience model needs to reflect the business consequence of failure.

Understand the difficult workloads

The easiest workloads often move first.

The final portion of a migration can be very different.

It may include:

Highly coupled systems

Poorly documented applications

Mainframes

Regulated workloads

Specialised hardware

Fragile integrations

Data-gravity constraints

A migration plan should account for these workloads before the business commits to a timeline.

Test the business case

The business case should include more than cloud consumption.

Consider:

Migration cost

Modernisation cost

Licensing

Data transfer

Observability

Security

Support

Skills

Ongoing optimisation

Also ask whether each workload needs:

Public cloud

Private cloud

Edge deployment

Hybrid arrangement

Cloud is a portfolio decision, not a destination decision.

Warning signs

Pause before approval when:

The business outcome is defined only as moving workloads.

Rehosting is expected to create cloud-native benefits automatically.

Modernisation costs are excluded from the business case.

Operating-model changes are not planned.

Resilience requirements are undefined.

Highly coupled or regulated workloads have no migration strategy.

Ongoing optimisation costs are missing.

Every workload is being forced into the same cloud pattern.

The decision

Do not ask:

How quickly can we move these workloads?

Ask:

Which workloads should move, how should each one move, and what business capability will improve as a result?

Then decide the appropriate pattern:

Rehost → Replatform → Refactor → Retire → Replace → Retain

The correct decision may differ by workload.

Five questions before approval

1. 01What business capability will be better after migration?
2. 02How will we measure the improvement?
3. 03What migration pattern is appropriate for each workload?
4. 04What operating-model changes are required to realise the expected value?
5. 05What will the migration and ongoing operation actually cost?

A successful migration is not measured by how many workloads moved.

It is measured by what became better because they moved.