AWS Landing Zone Readiness: The Decisions Before Migration

A migration wave can be ready at the application level while the environment receiving it is still operationally incomplete. The team has tested deployment, but nobody has rehearsed emergency access, agreed who owns a network change, or confirmed where an incident responder will find logs. Those gaps become urgent at the worst possible moment: after cutover.

AWS describes a landing zone as a foundation for a multi-account environment covering identity, governance, security, networking, and logging. AWS Control Tower can automate parts of that foundation. It does not decide the organization's ownership model. See AWS guidance on creating a landing zone.

Establish the decisions that workloads depend on

Begin with a short design record for each foundational area. Include the decision, responsible owner, evidence of testing, and unresolved exceptions. An architecture diagram is helpful, but it cannot substitute for these records.

• Accounts and ownership: Identify who owns each workload and budget, and how production and nonproduction environments are separated.
• Identity: Define normal access, privileged access, emergency access, and removal of access when responsibilities change.
• Networking: Document address planning, connectivity, name resolution, egress, and who approves shared changes.
• Logging and response: Confirm what is collected, where it is stored, who can investigate, and how alerts reach an accountable responder.
• Recovery: Agree on recovery objectives with the business and demonstrate that the workload can be restored within the agreed conditions.

Avoid treating a control's presence as proof that it works. A configured log destination is different from an incident responder successfully locating an event. A backup policy is different from a successful restore rehearsal.

Prove the handoffs with a representative workload

Choose a small workload that exercises the important dependencies. A disconnected sample application may demonstrate provisioning without proving the corporate identity or network path that production requires.

For a hypothetical reporting service, follow the entire chain: request an account, assign access, deploy through the approved path, reach the required data source, trigger a test alert, investigate it, restore a test backup, and allocate the resulting spend. Capture where a team had to ask for an undocumented favor. Those favors are hidden dependencies in the migration plan.

The goal is a repeatable path with clear exceptions. It is reasonable for an unusual workload to need a different control, but record who accepts the exception, when it expires, and how it will be reviewed. Otherwise, temporary workarounds quietly become the platform standard.

Make readiness a migration gate

At the migration readiness review, ask the application owner and platform owner to accept the same evidence. Open items need a consequence, an owner, and a decision date. A critical access or recovery gap should change the migration plan; it should not become a footnote in a green status report.

Track provisioning lead time, unresolved exceptions, failed rehearsals, and operational handoff completion. These are useful signals of whether the foundation supports delivery. Account counts alone say little about readiness.

This is the practical counterpart to clear ownership in cloud transformation. When planning migration waves, include these decisions in the cloud transformation workstream before promising a cutover date.