An exit plan is a short note, written before you adopt a library, that says when you would drop it, what you would switch to, how much work that is, and who decides. Five answers on half a page are enough. Writing it also exposes lock-in you would otherwise miss.
Why plan the exit on day one
Libraries get archived, change license terms, stop fixing security issues or simply stop fitting. When that happens, the cost of leaving depends on decisions made at adoption: how widely the library is called, whether its types leak into your code, and whether anyone remembers why you chose it.
You do not need a detailed migration. You need enough to make the later decision quick.
The five answers
- Triggers. What would make you leave? Examples: the repository is archived, a high severity advisory stays unfixed past an agreed window, the license changes to terms you cannot accept, or a required feature never ships.
- Alternatives. Name at least one other library or the in-house fallback. If none exists, say so, because that raises the stakes of the adoption.
- Swap cost. Estimate in days: how many files import it, and how many call sites use library-specific types? A search across the repository gives a count in seconds.
- Data and formats. Does the library write anything you cannot read without it, such as a custom file format, serialized objects or stored configuration? These are the hardest parts to migrate.
- Owner. One named person or team who watches the triggers and makes the call.
A filled example
| Item | Entry |
|---|---|
| Library | A date parsing package used in the billing service |
| Triggers | Archived repository, or unfixed advisory after 30 days |
| Alternatives | Standard library date handling, plus one other package |
| Swap cost | About 14 files, 2 to 3 days |
| Data risk | None, we store plain ISO 8601 strings |
| Owner | Billing team lead |
The numbers are illustrative; yours come from your own repository search.
Make the plan cheaper to execute
Two habits do most of the work. First, keep library calls behind a thin interface of your own, so most of your code never imports the library directly. We cover that in wrapping a library to keep exits cheap. Second, keep an accurate inventory so you can see everywhere the library is used across services.
GitHub notes that an archived repository becomes read-only and signals that it is no longer actively maintained, which is a clear trigger to write into the plan. See also what to do when a dependency is archived.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how an inventory lets you see where a component sits, which is the input for swap cost.
Where Safeguard fits
Safeguard's SBOM and dependency scanning give you the inventory behind the swap cost estimate, and continuous monitoring can alert you when a trigger such as a new advisory appears. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Do we need an exit plan for every dependency?
No. Write one for libraries that are hard to replace or sit on a sensitive path. Small helpers need only a line of notes.
Where should the plan live?
Next to the code: in the pull request that adds the dependency, or a short decision file in the repository.
Sources
Last reviewed: 19 October 2026.
