Enterprise Migration Program Scenario

Goal

This section applies the chapter's full decision model to a realistic phased migration program with many application types, shared dependencies, and uneven modernization pressure.

The Short Version

In a large migration, the best architecture answer is a sequence of moves with different strategies, not one perfect target-state diagram.

Wave 0 -> Wave 1 -> Wave 2 -> Wave 3 -> Wave 4
  |         |         |         |         |
Foundation Low risk Shared   Customer  Hard legacy
          apps      deps     critical  and special cases

Enterprise migration architecture is a sequencing exercise: move the estate in a way the organization can absorb, validate, and operate.

Scenario

A company must exit a data center contract within eighteen months. It has about 200 applications:

regulated internal systems,
customer-facing web and API workloads,
shared authentication and reporting platforms,
Windows applications,
SQL Server databases,
batch jobs,
file transfer flows,
and several legacy tools nobody wants to modernize but somebody still depends on.

Leadership asks for one migration plan to AWS. The correct answer is not one pattern. It is one program with several patterns inside it.

A Practical Recommendation

Wave 0: Foundations First

Before the first serious production move, establish:

AWS account and environment boundaries.
Identity and access patterns.
Network connectivity and DNS approach.
Central logging, audit, and configuration evidence.
Backup and restore expectations.
Deployment, rollback, and cost-visibility standards.

Wave 0 is easy to under-value because it does not move many business applications. In practice, it is what prevents every later wave from becoming an improvisation exercise.

Wave 1: Low-Risk Learning Moves

Choose a small set of applications that are:

well understood,
lightly coupled,
easy to validate,
and tolerable if a rollback is required.

These early moves are not about maximizing headline numbers. They are about proving the landing zone, migration process, validation checklist, support model, and communications rhythm.

Likely 7R choices in this wave:

Rehost for straightforward internal systems.
Retire for obsolete utilities that are only on the list because nobody cleaned up the portfolio.

Wave 2: Shared Services And Dependency Groups

Now address the systems that many other workloads rely on:

authentication paths,
shared integration services,
central reporting dependencies,
file transfer hubs,
and databases or jobs that influence many downstream systems.

This wave is often politically difficult because shared services cross team boundaries. It is still better to face that difficulty deliberately than to pretend shared dependencies are somebody else's problem until a later outage reveals the truth.

Likely 7R choices in this wave:

Replatform for systems that need operational improvement but not full redesign.
Retain temporarily where a dependency cannot move safely yet.

Wave 3: Customer-Facing Critical Workloads

Only after the organization has proven cutover, rollback, and stabilization on earlier waves should it take on the most visible workloads.

For these systems, the recommendation should be explicit about:

downtime tolerance,
validation checkpoints,
rollback rules,
customer communication,
and the exact point at which the new environment becomes the source of truth.

Likely 7R choices in this wave:

Replatform for customer-facing applications that benefit from managed databases, containers, or improved deployment paths.
Refactor only for the workloads where architecture change clearly matters to future delivery, scale, or resilience.

Wave 4: Hard Legacy And Special Cases

Leave the most awkward workloads for the end when the organization has already built migration muscle.

These systems may include:

highly customized legacy software,
specialized licensing constraints,
unusual hardware assumptions,
low-value tools that still need replacement planning,
and workloads whose modernization path depends on decisions made in earlier waves.

Likely 7R choices in this wave:

Repurchase where SaaS replacement is cheaper than ongoing custom ownership.
Retain for a bounded period if external dependencies still block movement.
Refactor only where the business value justifies the final effort.

Why Uneven Modernization Is Healthy

Leaders often worry that different 7R choices across the estate look inconsistent.

They are inconsistent only if they are unexplained.

If the program can say:

this workload was rehosted for speed,
that workload was replatformed to reduce operational burden,
this one was retired because it no longer mattered,
and this one was refactored because it drives future revenue,

then the portfolio is being managed rationally.

Uniformity is not the goal. Controlled reasoning is.

Trade-Offs To Explain Clearly

This program should be honest about its trade-offs:

Trade-Off	Reality
Speed versus depth	Faster waves usually involve more rehost and less deep redesign.
Risk reduction versus elegance	A safe move now can be better than a perfect design later that never ships.
Platform consistency versus team autonomy	Shared migration standards matter, but workloads still differ in value and readiness.
Modernization ambition versus supportability	Deep change is only useful if the team can own it after launch.

These are architecture trade-offs, not project-management side notes.

Common Mistakes

Presenting one migration strategy for all 200 applications.
Moving critical dependencies late because they are shared and politically awkward.
Announcing modernization as a broad promise without tying it to later phases and named workloads.
Declaring early success based on migrated counts instead of stable business operation.
Letting each team define success differently with no program-level validation standard.

If Someone Asks You

How would you structure a phased migration of 200 applications to AWS?

A good answer is:

I would start with foundations such as accounts, identity, connectivity, logging, backup, deployment, and cost controls. Then I would use discovery and dependency mapping to group workloads into credible waves: low-risk learning moves first, shared services next, customer-critical systems after the operating model is proven, and hard legacy cases later. I would mix 7R decisions across the portfolio rather than forcing one migration pattern on every application, and I would keep modernization commitments tied to specific later phases instead of promising a rewrite everywhere.

What You Should Remember

Enterprise migration architecture is a sequencing exercise: move the estate in a way the organization can absorb, validate, and operate.

Questions to Check Your Understanding

Why is the first migration wave often more about foundations than customer-facing workloads?
How do different 7R decisions coexist inside one migration program?
Why should modernization commitments be tied to specific later phases instead of broad promises?