Backed by Y CombinatorThree documents and four sheets that cross-reference your connection logs against the report catalog to find what nobody remembered.
Free download · No account needed
What you get
Pack of 7 files: 3 documents, 4 spreadsheets
Application Decommission Checklist TemplateDependency Map
| Found via | Status | Count |
|---|---|---|
| Existing integration inventory | Known | 13 |
| 180-day connection log only | Not known | 6 |
Of the 6 nobody had listed, 4 were already dead and 2 were live: a dashboard reading the database directly, and a job feeding a table a quarterly report depends on, one hop removed.
Every decommission checklist ranked for this query already has the bullet: map every upstream and downstream system, integration and report before you turn anything off. None of them say how, and how is the entire difficulty; a list built by asking a team what still connects is a list of what people remember. Even a well-built one caps its own verification short: one widely used decommissioning template recommends monitoring for 24 to 48 hours after cutover, which never touches a dependency that only runs once a month.
On the worked example already in the sheets, a 180-day connection log pull for Averill Mutual Insurance's retired PolicyCore system found 19 live connections against 13 the existing integration inventory named. Of the 6 nobody had listed, 4 were already dead and 2 were live: a commission dashboard reading the database directly, and a nightly job feeding a table a quarterly reinsurance report depends on, one hop removed. Cross-referencing the report catalog separately found that same reinsurance report; the connection logs alone never would have, because the report itself never queries PolicyCore.
This space starts once a replacement is already live and handling real transactions, not before. Picking or building that replacement is a separate CRM implementation job, and validating the one-time data cutover itself is what a systems migration plan covers. What is left, finding every connection and report nobody remembered before anything gets deleted, and sequencing the shutdown around what that check actually found, is what this pack tracks to close.
Dependency Map19 live connections found in a 180-day log pull, for a fictional insurer, Averill Mutual, retiring PolicyCore.
| Found via | Status | Count |
|---|---|---|
| Existing inventory | Known | 13 |
| Log pull only | Dead | 4 |
| Log pull only | Live | 2 |
The 2 live-and-unknown rows: a commission dashboard reading the database directly, and a nightly job feeding a table a quarterly reinsurance report depends on, one hop removed.
ChecklistSequenced so every live dependency is rerouted and verified before anything is deleted.
| Step | Status |
|---|---|
| Reroute commission dashboard | Done, 1 month verified |
| Rebuild nightly ETL | Done, 1 quarter verified |
| Hold database read-only | In progress |
| Final shutdown | Not started |
The read-only hold runs a full quarter, not a fixed 24 to 48 hour window, because the slowest live dependency found here is quarterly.
Archive RegisterOne row per data category, each with a real location and a named restore owner.
| Category | Location | Restore owner |
|---|---|---|
| Policy records | S3 Glacier | IT ops |
| Commission detail | Warehouse cold table | BI lead |
| Access logs | S3 Glacier | IT ops |
A category with no named restore owner is not archived. It is deleted with extra steps, because nobody knows how to get it back.
States what already replaced the old system, the corrected shutdown sequence, and a named sign-off owner for the dependency check, the export, and the shutdown decision.
Every retained data category with its own reason and its own retention period, confirmed against your actual regulatory and contractual requirement rather than assumed.
Three separate messages for three separate audiences, sent at three different points once each dependency is actually verified, not all announced at once.
Real connection logs cross-referenced against your existing integration list and your report catalog, with every gap classified dead or live.
Sequenced from what the Dependency Map actually found: every live connection rerouted and verified before anything gets deleted.
One row per data category with a real location, a real retention date, and a named restore owner, not one blanket archival note.
Every licence, add-on, and related contract tied to the old system tracked to a written confirmation, not just a notice sent.
Open the pack in River and hand it your logs and inventories, or download the Word documents and CSV sheets and fill them in yourself.
The connection or API gateway logs for the system, your current integration list, and however your reports and dashboards are inventoried.
Every connection not on your list, marked dead or live, plus any report that traces back one hop through a table something still feeds.
Live dependencies rerouted and verified first, then the archive, the final shutdown, and licence termination tracked to a written confirmation.
Yes. The zip is Word documents and CSV sheets, with no account and no card needed. Edit with AI is the optional half: River reads your actual connection logs, integration list, and report catalog, cross-references all three, and sequences the shutdown from what it actually finds.
Three Word documents and four CSV sheets, zipped together. Excel, Numbers and Google Sheets read the sheets with no reformatting, and Word, Pages or Google Docs open the plan, retention note, and comms directly. Nothing needs converting first.
The actual method. Most checklists list mapping dependencies as one bullet and leave the how unstated, which usually means asking a team what still connects. This pack also follows the report catalog one hop past any direct connection, because a dashboard can silently depend on a table another team owns, invisible to a source system's own connection logs.
Send whatever window exists, even thirty days. A short window still catches daily and weekly consumers; it just means treating anything absent from it as unconfirmed rather than dead, since a monthly or quarterly dependency needs a longer pull before it can be ruled out safely.
No, that happens first and separately. Designing the replacement is a CRM implementation job, and validating the one-time data cutover is what a systems migration plan covers. This pack assumes the replacement is already live and handling real transactions.
Scope. Vendor offboarding computes a contract's actual notice deadline and tracks data return with a vendor who is exiting the relationship. This pack's Licence Termination sheet tracks the resulting dates rather than deriving them, and its real focus is the technical dependency check, not the contract.
That's a live incident, not a retirement, and it's a different job: this pack reconciles the destination against the source to name exactly which records a sync failure dropped, rather than mapping dependencies before a planned shutdown.
Written by
Co-founder & CEO, River
Chandler has spent the last six years working in AI, building tools for millions of users and Fortune 100 companies. In 2025, he co-founded River to build a new kind of operating system for AI agents.
Send your connection logs, integration list, and report catalog. The first thing back is the gap between what people remember and what's actually still connected.
Edit with AI