API Sunset Readiness Checklist: How to Run the Process
A repeatable vendor deprecation readiness process: build the affected-surface inventory, route owners, track guarded readiness states, and keep the evidence for the next cycle.
A vendor deprecation notice just landed, and you are the platform or engineering lead who has to answer for it. The vendor's docs explain what is changing and when; they do not tell you which of your repos, scripts, dashboards, and jobs are affected, who owns each one, or what proves you are ready. This is the process that closes that gap: inventory, owners, readiness states, evidence, then a watch that outlives the date.
The API sunset readiness checklist#
Copy this into whatever tool your team already uses. The rest of the post explains each item and shows a filled example you can pattern-match against.
Vendor API sunset readiness checklist
- Capture the deadline as a record: vendor, affected API or feature, the exact date if one is published, and the source announcement.
- Build the affected-surface inventory: every repo, script, dashboard, scheduled job, integration, and client project that touches the deprecated API.
- Assign one named owner per surface, not a team alias.
- Map each surface to its replacement path: the new API, version, or vendor-recommended migration target.
- Test each replacement with real credentials and real payloads before calling anything ready.
- Record evidence per surface: what was tested, when, by whom, and the result.
- Mark blockers and waivers explicitly, so skipping a surface is a signed decision, not a hidden gap.
- Assemble the evidence packet: a stakeholder-ready readiness snapshot for leadership.
- Keep the inventory after the date passes and put it on a re-check schedule for the next notice.
A filled example: the Zapier Assistants-step stop
Here is the checklist filled in against a real dated sunset. Zapier is turning off its OpenAI-Assistants-API Zap steps, and per Zapier, "Zap workflows using these steps will stop working" on August 26, 2026. The full breakdown is in our post on the Zapier OpenAI-Assistants Zap-step shutdown.
| Affected surface | Owner | Deadline | State | Evidence |
|---|---|---|---|---|
| Zap: support triage (Conversation With Assistant step) | A. Rivera, RevOps | Aug 26, 2026 | tested | Rebuilt on the Responses-API Conversation action; live payload run recorded |
| Zap: lead enrichment (Create Assistant step) | M. Chen, Ops eng | Aug 26, 2026 | in progress | Replacement drafted; sandbox credentials pending |
| Internal script on the AI Actions (NLA) API | P. Singh, Platform | None published (unsupported) | mapped | Zapier MCP identified as the replacement path |
| Webhook consumer for assistant outputs | A. Rivera, RevOps | Aug 26, 2026 | blocked | Waiting on payload confirmation from the workflow owner |
| Dormant Zap, no runs since March | P. Singh, Platform | Aug 26, 2026 | waived | Owner sign-off recorded: workflow retired, no replacement needed |
If your stack includes Zaps, the free Zapier readiness scan flags every deprecated step without signup and maps each to its Zapier MCP or Responses-API replacement: the starting rows for this table.
Why vendor docs leave you scrambling#
The problem is not missing documentation. Vendors publish migration guides and dated announcements. But documentation stops at the vendor's border: it cannot see your stack, so it cannot say whether a notice touches one dormant script or forty production workflows.
Every notice arrives with the same unanswered questions:
- Which deadlines can actually break production, customer workflows, or partner commitments?
- Which repos, scripts, dashboards, jobs, and clients are affected?
- Who owns each dependency?
- What is the replacement path, fallback, or sign-off requirement?
- Has the replacement been tested with real credentials and payloads?
- What can you show leadership as proof of readiness?
Most teams answer them ad hoc: a Slack thread, a spreadsheet built under pressure, tribal memory of who owns what. It works once, barely, and the spreadsheet dies with the deadline; the next notice restarts from zero. And notices keep coming: Forge CLI's legacy template URL loses support in November 2026, and every vendor runs its own deprecation calendar.
Ad hoc scramble
- Deprecation notice sits in one inbox
- Affected systems found by memory and luck
- Owners guessed from git blame
- Status lives in a weekly meeting
- Spreadsheet deleted after the date
Readiness process
- Deadline captured as a record with a source
- Affected-surface inventory, org-keyed
- One named owner routed per surface
- Guarded readiness states per surface
- Inventory retained and re-checked
The five-stage process, step by step#
1Inventory
list affected surfaces
2Owners
one name per surface
3Readiness
guarded states
4Evidence
stakeholder snapshot
5Keep watching
scheduled re-checks
- 1
Build the affected-surface inventory
Search code for deprecated endpoints and SDK calls, list the automation workflows and integrations that touch the vendor, and ask each team what else they run. Put it all in one org-keyed affected-system inventory: repos, scripts, dashboards, jobs, integration connections, client projects. A surface missed here becomes an incident later.
- 2
Route one owner per surface
Deadline owner routing means every row names a person who can say "tested" or "blocked" about that surface. A team alias is not an owner; nobody in a group of eight feels responsible for row 14.
- 3
Move surfaces through guarded readiness states
Use the ladder: untriaged, owner assigned, mapped, in progress, tested, ready. "Mapped" means the replacement path is identified. "Tested" means the replacement ran with real credentials and real payloads. "Blocked" and "waived" are explicit states, so exceptions are decisions, not gaps.
- 4
Produce the evidence snapshot
For each surface, record what was tested, when, by whom, and the result. Roll it up into an evidence packet: readiness evidence for stakeholders ahead of the date. It is a stakeholder-ready readiness snapshot, not legal or compliance certification.
- 5
Keep the inventory and keep watching
The deadline was an event; the inventory is the asset. Keep it, and re-check it on a schedule: has anything drifted, is a new deadline approaching, is a key or credential rotation coming due. That standing watch turns the next notice into a lookup instead of a scramble.
The readiness state ladder
The guarded part matters. A surface cannot jump from untriaged to ready; it must pass through owner assigned, mapped, and tested first. Blocked and waived make the two honest exceptions, "we cannot proceed" and "we chose not to," visible states with a name attached.
Common mistakes that sink readiness#
- Treating the vendor's migration guide as the plan. It covers the vendor's timeline, not your dependency map; your plan starts from the inventory.
- Assigning surfaces to teams instead of people. Shared accountability means a row without one name stays untriaged forever.
- Calling a surface ready because someone read the docs. Ready requires a tested replacement with real credentials, real payloads, and evidence of the run.
- Deleting the tracker when the date passes. The inventory and owner map are the most expensive artifacts you built; retaining them makes the next cycle cheap.
- Ignoring undated wind-downs. A deprecation without a published end date still belongs in the inventory as an owned finding, never as an invented deadline.
Undated wind-downs still count
Zapier's AI Actions / NLA API is "no longer being developed and supported," and Zapier points users to Zapier MCP, but there is no published end date. Track it as an unsupported-dependency finding with an owner and a replacement path, not as a deadline. See what the AI Actions deprecation actually means.
What counts as an affected surface in an API sunset inventory?
Anything that touches the deprecated API and can break when it changes: repos and scripts that call it, dashboards that read from it, scheduled jobs, automation workflows, webhooks, integration connections, and client projects. If it would page someone or fail silently on the sunset date, it is a surface.
How is a readiness evidence packet different from a compliance report?
An evidence packet is a stakeholder-ready readiness snapshot: which surfaces were affected, who owned each, what was tested, and what remains blocked or waived. It is built for leadership before a deadline, and it is not legal or compliance certification.
What should we do with the inventory after the sunset date passes?
Keep it. The deadline was a thin event; the inventory of surfaces, owners, and evidence is the durable asset. Put it on a re-check schedule so drift, approaching deadlines, and credential rotations surface on their own, and the next notice starts against an existing map.
How do we run this process for a deprecation with no published end date?
Same process, different urgency. Inventory the affected surfaces, assign owners, and map replacement paths now, but do not invent a deadline the vendor never published. Describe the dependency honestly as unsupported, prioritize by production risk, and let owners schedule the migration like normal engineering work.
Put your inventory under a standing watch
Duefront keeps a retained, org-keyed inventory of monitored surfaces, routes each to an owner, tracks these readiness states, and re-checks everything on a schedule with drift and approaching-deadline digests: this process as a running system instead of a spreadsheet.