Purpose
Turn a raw inventory of applications and their integrations into a structured dependency map that reveals tightly coupled clusters, exposes hidden migration risks, and produces a sequenced migration plan organized into waves. Solves the core pre-migration problem: knowing what breaks if you move an application before its dependencies.
When to Use
Invoke this skill when the user asks to:
- Map dependencies across a set of applications before a migration
- Plan the sequence or order in which applications should be migrated
- Identify which applications are too tightly coupled to move independently
- Assess migration risk for a data center exit, cloud move, or modernization program
- Understand the blast radius of moving or decommissioning an application
- Group applications into migration waves or move groups
Inputs Required
Before starting, collect:
- Application inventory: List of applications with a name and, ideally, business criticality (e.g., Tier 1 / 2 / 3)
- Integration touchpoints: Which applications call, feed, or consume which other applications (API calls, message queues, file transfers, batch jobs)
- Shared databases: Which applications read from or write to which databases, and which databases are shared across multiple apps
- Data flows: Direction and nature of data movement (source → target, real-time vs. batch, sync vs. async)
- Migration goal: The target end-state (cloud lift-and-shift, re-platform, decommission, data center exit) and any deadline
- Constraints: Freeze windows, apps that must move together, apps that cannot move (regulatory/legacy holds)
- External dependencies: Third-party SaaS, partner systems, or on-prem services the applications rely on
If business criticality tiers are missing, infer them from integration centrality and note the assumption. If flow direction is unclear, treat integrations as bidirectional and flag them for verification.
Instructions
Step 1: Normalize the Inventory
Build a clean node list before mapping edges.
- Assign each application a short identifier and record its criticality tier.
- Classify each application as a source (produces data others consume), a sink (consumes only), a hub (both produces and consumes across many apps), or isolated (no dependencies).
- List each shared database as its own node — databases are dependency carriers, not passive infrastructure.
- Flag any application named in integrations but missing from the inventory as an unknown dependency requiring discovery.
Step 2: Build the Dependency Map
Construct directed relationships between nodes.
- For each integration touchpoint, record: source → target, mechanism (API / queue / file / batch / shared DB), and cadence (real-time / batch / on-demand).
- For each shared database, create an edge from every application that touches it, labeled read / write / read-write.
- Represent the map as a dependency table: one row per relationship (From, To, Type, Mechanism, Cadence, Coupling Strength).
- Assign coupling strength per edge: Tight (real-time sync API, shared write DB, no fallback), Moderate (async queue, scheduled batch, read-only shared DB), Loose (occasional file transfer, one-way feed with tolerance for delay).
Step 3: Identify Tightly Coupled Clusters
Find the groups that must move together.
- Detect clusters: sets of applications connected by Tight edges (especially shared-write databases and real-time bidirectional APIs).
- Name each cluster and list its member applications and the specific edges that bind them.
- Mark each cluster atomic (must migrate as one wave) or separable with rework (can split only if a specific integration is refactored — name the rework).
- Identify hub applications whose removal disconnects the map — these are single points of migration failure.
Step 4: Flag Migration Risks
Surface what will break and where uncertainty lives. For each risk, record severity (High / Medium / Low), the affected applications, and a mitigation.
- Circular dependencies: Apps that mutually depend — neither can go first without a temporary bridge.
- Shared-write databases: Multiple apps writing the same DB cannot be split without data-sync tooling.
- Real-time synchronous chains: Latency-sensitive API chains where moving one node adds cross-network hops.
- Unknown/undocumented dependencies: Edges to apps not in the inventory.
- External dependencies: Third-party or partner systems that constrain timing or add contract risk.
- High-fan-in hubs: Applications many others depend on — high blast radius, migrate late or with extended parallel-run.
Step 5: Recommend Migration Sequencing (Waves)
Sequence to minimize disruption.
- Order waves by dependency direction: migrate leaf sinks and isolated apps first (low blast radius), then loosely coupled mid-tier, then hubs and atomic clusters, decommission candidates last or opportunistically.
- Keep every atomic cluster inside a single wave.
- For circular dependencies, prescribe a strangler/bridge pattern: stand up a temporary integration shim so one app can move ahead of its partner, then remove the shim.
- For each wave, specify: applications included, prerequisite waves, estimated blast radius (count of downstream apps affected), required cutover approach (big-bang / parallel-run / phased), and the rollback trigger.
- Provide a one-line rationale per wave explaining why it precedes the next.
Output Format
- Structure: Normalized inventory summary → dependency table → cluster analysis → risk register → wave-based sequencing plan
- Length: 1,000–1,400 words plus tables
- Format: Structured document with tables for the dependency map, risk register, and wave plan; prose for cluster analysis and rationale
- Sections: Inventory & Node Classification → Dependency Map (table) → Tightly Coupled Clusters → Migration Risk Register (table) → Migration Sequencing Plan (wave table + rationale) → Open Questions / Discovery Items
- Tone: Enterprise architect — precise, risk-aware, decisive on sequencing without hedging
Quality Checklist
Before delivering output, verify:
- [ ] Every application in the inventory appears as a node and in at least one relationship (or is explicitly marked isolated)
- [ ] Every edge in the dependency table has a coupling strength (Tight / Moderate / Loose)
- [ ] Each identified cluster is labeled atomic or separable-with-rework, with the specific binding edges named
- [ ] The risk register assigns a severity and a concrete mitigation to every flagged risk — no risk left without a mitigation
- [ ] The wave plan keeps every atomic cluster within a single wave and lists prerequisite waves for each
- [ ] Circular dependencies each have a named bridge/strangler resolution, not just a flag
- [ ] Any dependency referenced in integrations but missing from the inventory is listed under Open Questions
Notes
- Shared-write databases are the most commonly underestimated coupling — two apps writing the same table are effectively one migration unit until data-sync tooling exists.
- Sequence bottom-up by data flow: sinks and low-fan-in apps first build confidence and cutover muscle before touching high-blast-radius hubs.
- Migrating a hub late is usually correct, but a hub with only loose downstream edges can move earlier — coupling strength matters more than raw dependency count.
- If the inventory is large, recommend a discovery pass (network flow logs, APM traces) to confirm undocumented edges before finalizing the wave plan.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills