Skip to content

Running an impact analysis

Use Impact Analysis (/impact-analysis, Planning → Impact Analysis) before any retirement, migration, or major change to see what it touches.

Steps

  1. Open Impact Analysis.
  2. Pick a starting category from the tabs: Application, Technology, Data store, or Capability.
  3. Choose the specific entity from the picker (a searchable modal list — no need to type the exact name).
  4. Read the blast radius:
  5. Affected applications — what depends on your starting point.
  6. Capability coverage gaps — capabilities that would lose support.
  7. Initiatives in flight — planned work already touching the affected assets.
  8. Replacement candidates — alternatives already in your estate.
  9. Data at risk — data feeds that would break; flagged feed_lost when the affected applications are the only producers.

Recent analyses are saved per user, so you can return to them.

Testing several changes at once

Impact Analysis answers "what does this one change touch?". When you need to model multiple moves together — retire X, introduce Y, reconnect Z — reach for the Scenarios engine (/scenarios, Planning → Scenarios), which dry-runs the combined change against a copy of the graph and shows the second-order effects before you commit.

Getting good results

Impact analysis is only as sharp as your relationships. If results look thin, the cause is almost always missing links — go link the application to its capabilities and technology, then re-run. This is the practical payoff of keeping capability mapping and dependency links current.

Typical uses

  • Before a decommission: confirm nothing critical depends on the asset and no sole-source data feed breaks.
  • Before a technology upgrade/migration: see every application that rides on the component.
  • When scoping an initiative: understand the footprint before committing dates.