Application Decommission Checklist Template
Three documents and four sheets that cross-reference your connection logs against the report catalog to find what nobody remembered.
Free download · No account needed
Dependency Map
Averill Mutual Insurance, PolicyCore retirement
| 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.
What's in the pack
Decommission Plan
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.
Data Retention Note
Every retained data category with its own reason and its own retention period, confirmed against your actual regulatory and contractual requirement rather than assumed.
Final Comms
Three separate messages for three separate audiences, sent at three different points once each dependency is actually verified, not all announced at once.
Dependency Map
Real connection logs cross-referenced against your existing integration list and your report catalog, with every gap classified dead or live.
Decommission Checklist
Sequenced from what the Dependency Map actually found: every live connection rerouted and verified before anything gets deleted.
Archive Register
One row per data category with a real location, a real retention date, and a named restore owner, not one blanket archival note.
Licence Termination
Every licence, add-on, and related contract tied to the old system tracked to a written confirmation, not just a notice sent.
How to use it
- 1
Open in River, or take it blank
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.
- 2
Send your logs, list, and catalog
The connection or API gateway logs for the system, your current integration list, and however your reports and dashboards are inventoried.
- 3
Get the gap, classified
Every connection not on your list, marked dead or live, plus any report that traces back one hop through a table something still feeds.
- 4
Sequence the shutdown, then close out
Live dependencies rerouted and verified first, then the archive, the final shutdown, and licence termination tracked to a written confirmation.
Frequently asked questions
Is this template free?
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.
What format are the downloaded files?
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.
We already have a "map dependencies" step in our checklist. What does this add?
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.
What if we don't have much connection log history?
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.
Does this help pick or migrate to the replacement system?
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.
How is this different from a vendor offboarding checklist?
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.
What if the old system's integration starts failing before we're ready to decommission it?
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.
Find out what nobody remembered to mention
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