eol-checklist

# EOL Checklist

## Purpose

Turn a sunset decision into a phase-gated operational plan: what must happen, in which lifecycle
phase, and who owns it. The output is a working checklist — sticky-note-sized items, each with a
verb and a named function — not a strategy document.

The checklist is **sized to the sunset**. A deprecated internal tool gets a dozen items across
three phases. A regulated hardware line gets a cross-functional playbook across six phases with
gate criteria between them. Both are correct; using the wrong one is the failure.

## Input

**Works best with:** The product being sunset and any dates you're already committed to.

**Also useful:** Customer and revenue scale, whether a replacement exists and how ready it is,
contract or regulatory obligations, and whether hardware, inventory, or channel partners are in
play.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or
an appended `ARGUMENTS:` line — counts as answers already given. Use it and skip whatever it
covers; don't re-ask.

**Arriving empty-handed? That works too.** The skill asks up to three questions — what's being
sunset and at what scale, whether there's a replacement, and what hard deadlines exist — then picks
a level and builds. Unknowns become labeled assumptions rather than blockers.

**Example invocations:**
- `EOL checklist for our legacy reporting module, shutting down Dec 31, ~400 accounts.`
- `Build the heavy checklist for a hardware retirement — service contracts, 8 resellers, UL certified.`

---

## Key Concepts

### Right-Size Before You Build

**Not all EOLs play out the same.** Most land in the middle. Pick the level deliberately:

| | **Level 1 — Light** | **Level 2 — Standard** | **Level 3 — Heavy** |
|---|---|---|---|
| Typical scope | Feature, internal tool, unversioned API | Commercial product, active customers | Revenue-critical, hardware, regulated |
| Phases used | 2-3 (NSC, EOS, EOL) | 4-5 (NSC, EOS, EOE, EOM, EOL) | All 6 (NSC through EOSRV) |
| Functional areas | 4 | 11 | 15 |
| Gate criteria | Not needed | Between major phases | Between every phase, with approvers |
| Output feel | Punch list | Working checklist with owners and dates | Cross-functional playbook |

**Level 2 is the default.** Recommend a level, say why in one line, and let the user move it. If
they go lighter, name the specific area that drops out so the choice is informed. **Never default
to Level 3** — a heavy checklist applied to a light sunset teaches teams that EOL process is
ceremony, and they'll skip it next time when it matters.

The level is yours to change mid-build. "Actually make this heavier" is a normal thing to hear
after the Legal row surfaces something.

### The Lifecycle Gates

- **GA (General Availability):** Actively sold and fully supported
- **NSC (Notice of Status Change):** The decision is communicated; planning begins
- **EOS (End of Sale):** No new customers can purchase
- **EOE (End of Expansion):** Existing customers cannot add capacity or seats
- **EOR (End of Renewal):** Existing contracts will not be renewed
- **EOM (End of Maintenance):** Bug fixes and patches stop
- **EOL (End of Life):** The product is retired
- **EOSRV (End of Service):** All support and service obligations end

**Which of these become checklist phases:** GA is a *state*, not a phase of work — nothing is
checklisted there. EOR is contract-driven and only appears when renewals are in play. So working
checklists usually span the six actionable phases: **NSC, EOS, EOE, EOM, EOL, EOSRV**, with EOR
inserted when subscription or service contracts run past EOS.

**Naming the gates you're not using is as useful as naming the ones you are.** A Level 1 checklist
should say "EOE and EOSRV don't apply — nothing to expand, nothing to service."

### The Fifteen Functional Areas

Filtered by level. The parenthetical marks the lowest level where each appears:

| Area | Level |
|---|---|
| Product and Strategy | 1 |
| Engineering and Technical | 1 |
| Support | 1 |
| Documentation and Training | 1 |
| Legal and Contractual | 2 |
| Financial Planning | 2 |
| Sales | 2 |
| Marketing | 2 |
| Customer Success | 2 |
| IT Systems | 2 |
| Data Management | 2 |
| Inventory and Supply Chain | 3 |
| Channel and Partner Management | 3 |
| Regulatory and Compliance | 3 |
| Internal Organizational Alignment | 3 |

### The Sticky-Note Rule

Every item is **4 to 8 words**, names a **verb**, and carries a **named owner** (a function, not a
person's calendar). "Legal reviews contracts" is an item. "Ensure appropriate review of all
relevant contractual obligations across the customer base" is a paragraph wearing a checkbox.

**Why the owner is mandatory:** an unowned item is a wish. Forcing a function onto every line
surfaces cross-functional gaps early — when you can't name who owns "notify channel partners," you
have just discovered that nobody does.

### Phase Gates Are Commitments, Not Dates

A phase gate is what must be **true** before you advance, with an approver. "EOS to EOE: last-time-buy
orders closed — Approver: Sales VP." This is what stops an EOL from being one announcement followed
six months later by somebody quietly pulling a plug.

### Anti-Patterns (what this is NOT)
- **Not a project plan.** No Gantt, no dependencies graph, no resource loading.
- **Not exhaustive by default.** Coverage proportional to risk, not maximum ceremony.
- **Not the decision.** If the sunset itself is still in question, this is premature.
- **Not a substitute for the conversations.** A checklist item saying "align with Legal" is not
  alignment with Legal.

---

## Application

### Step 1: Set the level

Recommend from blast radius — customers, revenue, contracts, hardware, partners — then present all
three and let the user choose. If the level is genuinely unclear, ask:

"How complex is this sunset?
1. **Light** — a feature, internal tool, or unversioned API. Few users, all reachable.
2. **Standard** — a c