Skip to content

Playbook — What breaks if I retire this?

Outcome: a blast-radius report for a planned change — everything that depends on the thing you want to retire, the capabilities that would lose coverage, the change initiatives already in flight, and candidate replacements.

The situation

You're planning to decommission an application, sunset a technology, or move a data store — and before you commit, someone (rightly) asks "what does this touch?" Guessing is how you take down a system nobody remembered depended on it. You need the dependency picture on one screen, fast.

You'll walk away with

A blast-radius analysis showing, for the thing you're changing: - the applications affected downstream, - the business capabilities that would lose coverage, - the initiatives in flight that touch it, and - replacement candidates already in your estate.

Before you start

The relationships that make impact meaningful: applications linked to the technologies they run on, and to the capabilities they deliver. Impact analysis traverses those links — so the quality of the answer is the quality of your connections. (If you've run the portfolio and capability playbooks, you're already set.)

Steps

  1. Open Impact Analysis. Planning → Impact Analysis (/impact-analysis).
  2. Pick what's changing. Choose the category — Application, Technology, or Data Store — then select the specific item from the list.
  3. Read the blast radius. The result lays out affected applications, capability coverage gaps the change would create, initiatives in flight that intersect it, and replacement candidates.
  4. Re-run as needed. Recent analyses are saved, so you can revisit a scenario or compare a few retirement options side by side before you commit to a plan.

When the retire is part of a bigger move

Impact Analysis answers "what breaks if I retire this one thing." When the change is a set of moves — retire X, introduce its replacement Y, reconnect Z to the new one — reach for the Scenarios engine instead: Planning → Scenarios (/scenarios). Compose the change set from three verbs (retire / introduce / reconnect), and the engine runs it as a dry-run against your estate, surfacing the second-order effects — including the ones you didn't think to check — before anything is written. When you're satisfied, you can optionally commit the scenario to make the changes real. It's the difference between "what does this touch?" and "if I do all of this, what did I forget about?"

Where people get stuck

Impact analysis can only show what's been connected. If your applications aren't linked to their technologies and capabilities, the blast radius will look reassuringly small — and be wrong. An empty result is usually a missing-relationships signal, not a safe-to-delete signal. Build the connections first (the portfolio and coverage playbooks do exactly this).

Make it stick

Make this the standard pre-flight check before any decommission or migration decision. Once "run the blast radius" is a step in your change process, the repository stops being a documentation exercise and becomes the thing that prevents outages — which is the most durable reason anyone keeps a tool alive.

Impact Analysis, Scenarios, and the risk/coverage intelligence these playbooks lean on are Professional-tier capabilities.