Cloud Computing Architecture Guide

Migration, Modernization, and Operating Model Change

What This Chapter Is About

Teach migration as a portfolio change that combines business priorities, dependency evidence, landing-zone readiness, workload strategy, safe execution, and new operating responsibilities.

Keep one durable idea in view:

A successful migration moves business capability into an operating model that can support it; moving workloads is only one part of the change.

Sections

  1. Migration Is Portfolio Change, Not Workload Copying

  2. Discovery, Dependency Mapping, and Landing-Zone Readiness

  3. Migration Strategies and Modernization Timing

  4. Waves, Data Movement, Cutover, and Rollback

  5. Migrating a Portfolio While Changing the Operating Model

How the Chapter Develops

The chapter develops in this order:

  1. Frame migration as business, portfolio, architecture, and organizational change.

  2. Build an evidence base through discovery, dependencies, and destination readiness.

  3. Choose workload strategies according to outcomes and modernization timing.

  4. Organize migration waves and rehearse data movement, cutover, rollback, and validation.

  5. Apply the model to a 200-application portfolio while evolving ownership and operations.

Together, these sections show that migration is a controlled sequence of decisions and learning, not a bulk copying exercise or a forced rewrite program.

What You Will Be Able to Do

By the end of this chapter, the reader should be able to:

  • Explain the business and operating outcomes that should guide a migration.

  • Identify the discovery and landing-zone evidence needed before workload movement.

  • Choose among migration and modernization strategies without treating labels as automatic answers.

  • Design waves, cutovers, validation, and rollback around dependencies and risk.

  • Describe how skills, ownership, support, governance, and cost practices must change with the platform.

Key Ideas

  • Portfolio facts, dependencies, and business deadlines should shape the sequence.

  • The destination foundation must be ready before it receives production risk.

  • Migration strategy is chosen per workload or component and can change over time.

  • Data, integration, identity, DNS, security, and operating handoffs often control cutover risk.

  • Migration success includes adoption, decommissioning, stable operations, and realized outcomes.