Migration Decision Mental Model

Goal

Establish migration as an architecture and operating-model decision before the chapter moves into discovery, wave planning, and AWS execution tooling.

The Short Version

Migration is not one big move. It is a controlled sequence of business, architecture, security, and operations decisions.

Business goals and constraints
            |
Portfolio and dependency understanding
            |
Landing-zone and operating-model readiness
            |
Migration path and modernization timing
            |
Cutover, validation, and stabilization

Teams usually get into trouble when they collapse those layers into one sentence such as "move everything to AWS this year." That statement describes urgency, not strategy.

What Migration Strategy Actually Does

Migration strategy answers a small set of hard questions:

• Why is the estate moving now?

• Which applications matter most to the business?

• Which systems are tightly coupled and must move together?

• Which controls must exist before production workloads land in AWS?

• Which workloads should move quickly, and which should wait?

• Which changes belong in the first move, and which should wait for later modernization?

If those questions are unanswered, migration becomes a series of local technical projects with no stable program logic behind them.

Migration Is A Change Program

Migration affects more than infrastructure placement.

This is why migration can fail even when the servers boot correctly in AWS. The move may be technically successful while the workload is still operationally unready, weakly monitored, expensively configured, or owned by the wrong team.

Separate Migration From Modernization Timing

One of the most useful migration habits is to separate these two decisions:

1. How do we get the workload into a safe, supportable AWS landing place?

2. When should we improve the workload more deeply?

Those decisions are related, but they are not identical.

A team under data center exit pressure may choose to rehost an application first because speed matters more than elegance in the first phase. That is not automatically weak architecture. It can be the strongest answer when the real goal is to reduce contract risk, establish support ownership, and stop running on fragile infrastructure.

Later, once the workload is observable and stable in AWS, the team can decide whether it should be replatformed, decomposed, containerized, moved to managed databases, or redesigned around events. Strong migration design avoids forcing every long-term improvement into the first cutover window.

Landing Zone Readiness Changes The Answer

Migration plans often look simpler on paper than they are in reality because teams assume the target platform is ready.

It may not be.

Before large production waves begin, the organization usually needs:

• Account and environment boundaries.

• Identity and access patterns.

• Network connectivity and DNS decisions.

• Central logging and audit paths.

• Backup and recovery expectations.

• Deployment and rollback patterns.

• Tagging, cost visibility, and ownership standards.

Without those foundations, the team is not migrating into an operating model. It is relocating technical debt into a new address.

Example: "Move Everything Fast"

A company receives notice that one of its data center contracts will end in twelve months. Executives ask the technology organization to move 200 applications to AWS as fast as possible.

At first, that sounds like a capacity and tooling exercise. It is not.

The estate contains customer-facing systems, batch jobs, SQL Server databases, Windows applications, internal portals, shared authentication services, file-transfer jobs, and reporting tools. Some applications have named owners. Others survive mostly through tribal knowledge. Some are worth modernizing. Some only need a safe landing. Some should probably be retired instead of moved.

A practical migration strategy would start by turning this panic into a decision structure:

• Identify business deadlines and non-negotiable constraints.

• Group systems by dependency and criticality.

• Prepare the landing zone and operational controls.

• Decide which workloads need speed, which need redesign, and which should not move at all.

• Reserve deeper modernization for the places where it changes cost, resilience, or delivery speed enough to matter.

That sequence is slower in the first week and faster over the full program.

Common Mistakes

• Treating migration as a uniform technical project for every application.

• Assuming modernization must happen before anything can move.

• Ignoring the support-model and ownership changes that begin after cutover.

• Starting replication or server builds before the landing zone and controls are ready.

• Measuring migration success only by moved servers instead of stable business operation.

If Someone Asks You

Why is migration strategy more than choosing a migration tool?

A good answer is:

Because the hard part is not copying workloads. The hard part is deciding what should move, what should wait, what should change, which dependencies matter, which controls must exist first, and how the workload will be owned after it reaches AWS. Tools help execute those choices, but they do not make them for you.

What You Should Remember

Migration design starts with risk, ownership, and sequencing. Tools only help after those decisions are clear.

Questions to Check Your Understanding

1. Why can a rushed migration fail even when the technology works?

2. What kinds of constraints change the right migration path?

3. Why is modernization timing a separate decision from initial migration?

Further Study

• AWS Cloud Adoption Framework: Introduction - Use this for AWS adoption capabilities, operating-model thinking, and migration context.