This checklist is part of the monitoring tool retirement guide. The 20-minute meeting agenda gets the first answers; this page tracks them until switch-off.
Fixing the countdown dates first
Write down the three dates and the document behind each before you tick anything.
| Milestone | Typical source | If missing |
|---|---|---|
| Announcement | Engineering leadership's decision, a vendor end-of-sale notice | You are early; milestone one is unhurried |
| Cutover | The migration plan for routing, schedules and integrations | Record who owns the go-live decision |
| Switch-off | Vendor end-of-access date, contract end or retirement ticket | Leave open; the item becomes "find out who decides" |
Vendor dates are public and worth checking at source; Atlassian's licensing page, for example, gives April 5, 2027 as the date Opsgenie access ends. A customer moving to another product from the same vendor may keep its history, so confirm the company's actual path before treating any vendor date as a deadline.
AtlassianMark each item confirmed, open (with a named person) or at risk. Keep the sheet to keys, systems and owners; no alert payloads, hostnames, customer names or chat excerpts.
Milestone one: before the retirement is announced
Nothing has been scoped yet, so this is the moment to learn how the trail is built today.
| Confirm | Owner | If skipped |
|---|---|---|
| How alerts become incidents, and whether on-call engineers merge, split or move alerts by hand | Paging platform owner | The human corrections to bundling are never identified as worth keeping |
| Which key joins alert group, incident, fix ticket and written review, usually the incident ID | Reliability lead | Nobody knows what the export must preserve |
| The year that key became required on tickets and written reviews | Reliability lead | Traceable history is overstated, or undercounted |
| Who owns incident records and whether customer data appears in alert payloads | CTO or VP of engineering | Rights questions appear only after an introduction |
The first row matters more than it looks. PagerDuty documents that related alerts can be grouped into one incident, and that manually merging incidents or moving alerts helps the tool learn. Each merge is a recorded human decision about which signals belong together. A plan that exports incidents without their merge history keeps the outcome and loses the judgment.
PagerDutyMilestone two: before cutover to the replacement tool
Cutover projects are judged on whether pages still reach the right person on day one: routing, schedules, escalation policies, integrations. Old incidents get one line in the plan. These items keep the trail intact.
| Confirm | Owner | If skipped |
|---|---|---|
| The export includes incident timelines: who took the page, handoffs, notes | Platform owner | The middle of the trail, the human actions, is missing |
| Incident IDs in change tickets still resolve to an archived incident | Service desk owner | Fix tickets point at IDs that no longer exist anywhere |
| Chat channels used during incidents are exported or explicitly excluded | Collaboration tool admin | On-call notes vanish without anyone deciding to drop them |
| Written reviews keep the incident ID and their action items stay linked | Engineering wiki owner | Written closure detaches from the incident it closed |
Closure is the end of the chain, and it usually lives outside both the old and the new tool. If written reviews survive in the wiki but no longer resolve to an archived incident, the trail keeps its end and loses its middle. Ask the wiki owner to confirm the identifier format will not change when the new tool starts numbering incidents its own way.
One incident traced through the cutover plan
Illustrative. A 230-person travel booking platform is replacing its paging tool. Before cutover, the reliability lead traces one incident through the plan:
| Stage | Survives cutover? | Mark |
|---|---|---|
| Alert group, including a manual merge | Incidents exported; merge log not in scope | At risk |
| Acknowledgment and reassignment | Yes, in the incident timeline export | Confirmed |
| On-call notes in the incident chat channel | Chat export not planned | At risk |
| Rollback recorded in the change ticket | Yes, incident ID field required since 2020 | Confirmed |
| Written review with action items | Yes, wiki page titled with the incident ID | Confirmed |
Two at-risk rows, both decisions the company can still make. The trace also shows that the trail is traceable from 2020, which is exactly the metadata an introduction needs.
Milestone three: before the old tool is switched off
After switch-off, whatever was not exported is gone. This milestone is about access, retention and authority.
| Confirm | Owner | If skipped |
|---|---|---|
| Where the exported incident history lives and in what format | Platform owner | The export exists but no one can query it |
| A written retention period for incident history and written reviews | Security or compliance lead | The archive is deleted at the next clean-up |
| Whether any read-only access to the old tool remains, and until when | Platform owner | The team assumes access it does not have |
| Who can authorize a licensing discussion about the history | CTO, VP of engineering or owner | An interested company has nobody able to decide |
The PagerDuty incident export page describes what incident timelines typically hold. The founder retirement handoff checklist shows the same countdown logic for a very different kind of retirement.
Turning a finished countdown into a decision
Read the result back to the executive in one sentence per stage: bundling and merges, on-call actions, fixes, written reviews, each confirmed, open or at risk, plus the year traceable history begins. That answers the core question at metadata level. The tool-use training data page explains why multi-step operator records like these are a distinct data type.
If the executive wants to explore licensing:
- Disclose. Say you are a SourceX referral partner and may receive a reward if a qualifying license completes, funded separately by SourceX and never deducted from the company's payout. SourceX licenses approved business data directly from companies for AI training and evaluation, and manages agreement, rights review, data preparation, delivery and payout.
- Check fit. The company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records, and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 70% of the data is in English.
- Introduce. Sign the Channel Partner Agreement, run the incident records introduction checklist, then send the introduction email. The first valid introduction within the 90-day window is credited when the company submits a verified application. Illustrative only: a USD 100,000 qualifying payout to the company on its first qualifying transaction would mean a USD 55,000 default reward; the rewards page lists every condition.
Buyer need, the rights review result, customer data handling and any offer stay unknown until SourceX reviews the application.
Next step
Refer a company. No cap on rewards. Default reward on a company's first qualifying transaction: the greater of $50,000 plus 5% and 15% of Actual Supplier Payout, with no cap; further qualifying transactions first agreed within 12 months of the first Closing pay 15%. Eligibility and payment conditions apply, including the USD 100,000 Minimum Transaction, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If the countdown shows the alert-to-closure trail survives switch-off and the executive wants to talk, register as a partner, check who qualifies, and read the program terms before introducing the company.