Application Dependency Mapping

February 13, 2026 | Cloud Migration Discovery

Automated discovery and wave planning.

Application Dependency Mapping for Migration

You can't migrate what you don't understand. Application dependency mapping discovers all servers, applications, and their interconnections — providing the foundation for migration wave planning. Without it, you risk breaking integrations and missing critical dependencies.

Why Mapping Matters

Prevent outages — Migrating App A without its dependency App B causes failures
Plan migration waves — Group tightly coupled applications into the same wave
Right-size infrastructure — Understand actual resource usage for target sizing
Identify retirement candidates — Discover unused servers and applications

Discovery Methods

1. Automated Discovery (Recommended)

Use agents or agentless scanning to automatically discover servers and connections:

AWS Application Discovery Service — Agent-based or agentless discovery
AWS Migration Hub — Centralized tracking with discovery integration
Third-party tools — Device42, Flexera, ServiceNow CMDB

# Install AWS Discovery Agent on each server
# Agent collects:
# - Server configuration (CPU, memory, disk, OS)
# - Running processes
# - Network connections (source IP:port → destination IP:port)
# - Resource utilization over time

aws discovery start-data-collection-by-agent-ids \
  --agent-ids agent-xxx agent-yyy

2. Network Flow Analysis

Use network flow data to identify dependencies without installing agents:

Firewall logs (Palo Alto, Cisco ASA)
NetFlow/sFlow data from switches
VPC Flow Logs (for workloads already in AWS)

3. Manual Interviews

Supplement automated discovery with application owner interviews:

What external systems does this application connect to?
What internal APIs does it consume?
What databases does it access?
What file shares or storage does it use?

Dependency Types

Type	Example	Migration Impact
Hard dependency	App → Database	Must migrate together
Soft dependency	App → Monitoring	Can tolerate brief disconnection
One-way	App → API endpoint	API must be reachable from new location
Bidirectional	App ↔ Message broker	Both must be reachable simultaneously

Wave Planning

Group applications into migration waves based on dependencies:

Wave 1: Independent applications (no dependencies on remaining on-prem)
  - Static websites
  - Standalone tools
  - Dev/test environments

Wave 2: Applications with cloud-ready dependencies
  - APIs that only depend on managed services (RDS, S3)
  - Applications whose dependencies were migrated in Wave 1

Wave 3: Complex applications
  - ERP systems
  - Applications with bidirectional on-prem dependencies
  - Databases serving multiple applications

Wave 4: Remaining applications
  - Tightly coupled legacy systems
  - Applications requiring refactoring

Migration Hub Dashboard

aws migrationhub create-progress-update-stream \
  --progress-update-stream-name MainMigration

# Track application status:
# - Not Started → In Progress → Complete
# Automatically aggregates from DMS, MGN, and partner tools

Common Pitfalls

Hidden dependencies — Batch jobs, cron-based integrations, file-based data exchange
DNS dependencies — Hardcoded hostnames that need DNS cutover planning
License portability — Some software licenses don't transfer to cloud
Incomplete discovery — Run discovery for at least 30 days to capture monthly batch processes

Eazy SaaS Tip: We run automated discovery for a minimum of 30 days before starting migration planning. This captures monthly batch jobs and infrequent integrations that shorter discovery periods miss. The output is a dependency map that becomes the migration blueprint.

← Back to Blog