Cloud Computing Architecture Guide

Migration Is Portfolio Change, Not Workload Copying

Goal

Frame migration as coordinated business, technical, platform, and operating change rather than a count of moved assets.

The Short Version

A cloud migration succeeds when a business capability reaches a supportable destination, users can rely on it, responsible teams can operate it, and the old risk is retired. Copying servers or applications is only one activity in that outcome.

Migration drivers differ: a data-center exit, resilience gap, security requirement, product goal, acquisition, cost problem, or delivery constraint. These drivers determine priorities and measures. A fixed exit date may favor a smaller initial technical change; a product bottleneck may justify deeper modernization.

Coordinated Transitions

flowchart TB
    A["Business outcome"] --> B["Workload and data transition"]
    A --> C["Platform and control transition"]
    A --> D["Team and operating transition"]
    A --> E["Legacy retirement and benefit realization"]

Define success across continuity, performance, security, adoption, support, cost, risk reduction, and decommissioning. A workload that runs in the cloud while retaining its old licenses, network paths, support contract, and unmanaged ownership may have moved without delivering the intended benefit.

Architecture Meaning

Treat the estate as a portfolio. Workloads differ in business value, criticality, deadline, lifecycle, technical condition, dependencies, evidence quality, and owner readiness. Segmenting by these dimensions exposes why one migration strategy or wave schedule cannot fit everything.

Make assumptions visible early: architecture and data knowledge, licensing portability, vendor support, network capacity, regulatory constraints, required skills, and availability of business testers. Unknowns are not empty cells; they are risks that affect sequencing and contingency.

Modernization is a separate timing decision. It may happen before migration, during a targeted replatform, after a lower-change move, or independently. Separating the decisions prevents the false choice between "copy everything" and "rewrite everything."

Example: A Data-Center Exit

A company plans success around moving 600 servers before a lease expires. Discovery shows that several applications have no active owner, shared databases cross application boundaries, licenses cannot move unchanged, and the cloud support team has no recovery process. The program resets its measures around business services, dependency groups, operational acceptance, and decommissioned cost. Some systems move, some are replaced, and some are retired.

Common Mistakes

  • Measuring progress only by servers or applications moved.

  • Treating every workload as equally valuable and urgent.

  • Assuming a technical owner can provide business validation.

  • Forcing modernization into the move without a payoff or safe transition path.

If Someone Asks You

A migration changes where and how a business capability is delivered, governed, secured, supported, and funded. Workload movement matters, but success also requires operational ownership, user validation, legacy retirement, and realized outcomes.

What You Should Remember

Move outcomes, controls, ownership, and operations, not just technical assets.

Questions to Check Your Understanding

  1. Which measures reveal whether migration benefits were realized?

  2. Why should modernization timing remain a separate decision?

  3. When is a technically completed migration still incomplete?

Further Study