Cloud Computing Architecture Guide

Discovery, Dependency Mapping, and Landing-Zone Readiness

Goal

Build credible workload evidence and prove that the destination can safely receive production risk.

The Short Version

Inventory says what appears to exist. Discovery explains what a workload does, who owns it, what it depends on, and how confidently the team knows those facts. Landing-zone readiness proves that the destination provides the identity, connectivity, governance, evidence, security, automation, cost, and support boundaries the workload needs.

Migration readiness exists only when source evidence and destination capability meet.

The Readiness Decision

flowchart TB
    A["Inventory, business context, dependencies, and confidence"] --> C{"Ready for a pilot?"}
    B["Landing-zone controls, connectivity, operations, and cost model"] --> C
    C -- No --> D["Resolve gaps or change scope"]
    C -- Yes --> E["Pilot, observe, and improve"]

Discover the Workload in Context

Combine automated inventory with interviews, documentation, traffic and authentication evidence, incident history, contracts, and operating knowledge. Record application versions, infrastructure, data stores, interfaces, users, service windows, owners, criticality, compliance needs, costs, and lifecycle.

Map more than network connections. Dependencies include identity providers, DNS, certificates, scheduled files, batch windows, shared databases, message brokers, vendor allowlists, user devices, reporting, backup processes, and support teams. Distinguish hard runtime dependencies from soft reporting or administrative relationships.

Record source, recency, and confidence. A presumed dependency based on an old diagram should not be treated like an observed production flow. Unknown ownership or traffic is evidence that more investigation or a safer pilot is needed.

Prove Destination Readiness

A landing zone is not merely a network. It establishes resource hierarchy, identity and privileged access, connectivity and DNS, policy and security baselines, centralized logging and audit, cost allocation, deployment automation, quota management, backup expectations, and support ownership. Provider landing-zone patterns differ, but these responsibilities persist.

Use a representative, low-to-moderate-risk pilot to test both technology and handoffs. The pilot should validate provisioning, access, monitoring, deployment, incident escalation, cost reporting, backup, and feedback into the platform.

Example: The "Standalone" Application

An inventory lists one web server and one database. Traffic evidence and interviews reveal federated identity, a nightly partner file, a hard-coded address, an on-premises reporting database, and a certificate renewed manually by another team. The application cannot move safely until hybrid connectivity, DNS, certificate ownership, and data sequencing are resolved.

Common Mistakes

  • Treating a configuration database as complete and current evidence.

  • Grouping by organizational chart while ignoring runtime dependencies.

  • Hiding uncertainty instead of recording confidence and ownership gaps.

  • Building a landing zone with connectivity but no operational or cost controls.

If Someone Asks You

Before placing a workload in a wave, understand its business owner, criticality, runtime and operating dependencies, data, constraints, and evidence confidence. Then prove the landing zone can provide those dependencies with the required controls and support.

What You Should Remember

Understand what the workload depends on and prove that the destination can meet those dependencies safely.

Questions to Check Your Understanding

  1. Why should discovery combine tools with human operating knowledge?

  2. Which non-network dependencies commonly control cutover?

  3. What should a production-representative pilot validate?

Further Study