Level Up

How to Detect Application Dependencies Before an AWS Migration

Level Up Team
AWS MigrationAutomationCloud Native

The fastest way to break an AWS migration is to move an app whose database, identity source, or file share is still on the far side of a cutover.

Dependencies should be evidence, not workshop sticky notes.

Level Up's migration assessment treats every important edge as known or inferred, then makes engineers decide the inferred ones. You can apply the same method before any wave plan.

Collect known edges first

Start with artifacts the system already has:

  • Connection strings and JDBC/ODBC DSNs
  • Reverse-proxy and load-balancer backends
  • systemd After= / Requires=
  • Cron targets and file drop locations
  • DNS CNAMEs and service records
  • Ansible inventories and Terraform depends_on / implicit refs
# Cheap, high-signal greps on a Linux app host
sudo grep -RInE 'jdbc:|postgres://|mongodb://|amqp://|\\\\[a-zA-Z0-9_.-]+\\' /etc /opt /var/www \
  --exclude-dir=proc --exclude-dir=sys 2>/dev/null | head

ss -lntp
dig +short app.internal.example.com

Ansible can wrap the same collection and write JSON per host. See Linux inventory with Ansible.

Add runtime observation

Config misses the edges nobody documented:

  • Established TCP connections to data stores
  • Periodic jobs that only appear in logs
  • Authentication against Active Directory or LDAP
  • SMB mounts that applications open at runtime
ss -antp | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr

Label these observed. They are stronger than a slide, weaker than an owned interface contract.

Mark inference explicitly

If a CRM host has a nightly cron and a JDBC URL fragment pointing at ERP, that is an inferred data edge. It belongs in the graph. It does not belong in a high-confidence wave until someone confirms the job owner and failure mode.

- from: crm
  to: erp
  type: data
  basis: inferred
  evidence: "cron + JDBC fragment on crm-app-01"
  action: "Confirm job owner before wave 4"

Hiding inference inside a pretty graph is how assessments lose engineer trust.

Use the graph to sequence waves

A useful rule: do not migrate a node until its hard runtime and identity dependencies are already in the target environment, retained on purpose, or scheduled in the same wave with a tested cutover.

That is the method behind building migration waves from dependencies and the Acme example graph.

The report is not the system of record. The evidence is. If you want that graph produced as part of a full assessment, inspect the open-source project or request an assessment.