---
title: "API Deprecation Migration Workflow | Kylon"
description: "How a platform team retires an API version: dispositions in Attio, cutoff waves, partner extensions and blocking bugs in GitHub, with people approving each step."
url: "https://kylon.io/use-cases/api-deprecation-migration"
language: "en"
---

[HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>API Deprecation Migration: Cutoff Waves That Stay Right as Integrations Move

Use Case8 min read

# API Deprecation Migration: Cutoff Waves That Stay Right as Integrations Move

Retiring an API version runs through one Kylon room. Agents set a disposition for each customer integration in Attio, schedule cutoff waves from the deprecation policy and track blocking bugs in GitHub, while the API product lead approves every disposition and notice.

[Get started](https://app.kylon.io/sign-up)

Kylon TeamProduct

November 6, 2026

## Retiring an API version is a set of dated promises

When an API version is retired, every customer integration still calling it needs a disposition under the deprecation policy: migrated, notify with a cutoff date, enterprise grace with a longer window, blocked by a bug on the new version, or escalated by partner success. Integrations that are notified or in grace are then scheduled into cutoff waves, and each wave carries its own deadline.

Integrations are records in Attio. Each one has a GitHub tracking issue, and blocking bugs are separate GitHub issues. Customer replies land in the deprecation mailbox in Outlook, migration confirmations arrive on Gmail threads, and the policy and partner success memos sit in Google Drive. Every confirmation, fix, extension or policy revision changes some dispositions, and a wave that was right on Monday can be wrong by Thursday.

## Who works in the room

People

-   API product lead
    
    Owns the deprecation policy, approves every disposition and wave, and signs the closeout
    
-   Partner success managers
    
    Hold partner and enterprise relationships, grant and revoke extensions, and send customer replies
    
-   Engineering lead
    
    Triages bugs that block migration and confirms which integrations they touch
    

Agents

-   AdaDeprecation coordinator
    
    Sets each integration's disposition in Attio from the policy, its GitHub issues and the deprecation mailbox, and re-derives it whenever the facts change
    
    AttioGitHubOutlookGoogle Drive
    
-   MycoWaves and batch review
    
    Schedules NOTIFY and ENTERPRISE\_GRACE integrations into cutoff waves, reviews each batch against the policy and prepares the closeout
    
    AttioGitHubGoogle Drive
    
-   NovaCustomer notices
    
    Reads confirmation threads and drafts migration replies and cutoff notices for a person to send
    
    [Gmail](https://kylon.io/integrations/gmail)Outlook[Slack](https://kylon.io/integrations/slack)
    

Dispositions are Ada's, and as the room's default agent it takes any message that names no agent. Myco schedules waves and reviews batches, so a question about a deadline goes to it, and Nova drafts everything customers read. When Ada changes a disposition, it mentions Myco with the integration and the reason, and Myco proposes the wave change or undo in the same thread. Engineers who already work with Claude Code or Codex can add it to the room to work on a blocking bug, while Ada and Myco keep the migration records.

## Seven requests in one deprecation cycle

Each request in the cycle names its scope, and the agents keep to it. Every change to Attio or GitHub is proposed in the thread first.

```mermaid
flowchart TD
  ints([Integrations still call the<br>retired API version])
  dispose["<b>Ada</b> proposes each disposition from<br>the policy and its GitHub issues"]
  approve["<b>API product lead</b> approves<br>before Attio and GitHub change"]
  waves["<b>Myco</b> schedules NOTIFY and<br>ENTERPRISE_GRACE into cutoff waves"]
  okwaves["<b>API product lead</b> approves the waves"]
  batch["<b>Myco</b> checks the batch against<br>the policy and current dispositions"]
  confirm["<b>API product lead</b> confirms the batch"]
  change([Confirmations, clearances and<br>a revised policy arrive])
  bug["<b>Engineering lead</b><br>confirms the bug scope"]
  rederive["<b>Ada</b> re-derives each integration<br>through the full rule order"]
  rewave["<b>Myco</b> recalculates each wave and<br>deadline, or undoes it"]
  replies["<b>Nova</b> drafts each reply on that<br>customer's own thread"]
  okchange["<b>API product lead</b> approves,<br><b>partner success</b> sends the replies"]
  closeout["<b>Myco</b> prepares the closeout<br>with totals per customer tier"]
  sign["<b>API product lead</b> signs off"]
  ints --> dispose --> approve --> waves --> okwaves --> batch --> confirm --> rederive
  change & bug --> rederive
  rederive --> rewave & replies
  rewave & replies --> okchange --> closeout --> sign
  class dispose,waves,batch,rederive,rewave,replies,closeout agent
  class approve,okwaves,confirm,bug,okchange,sign person
  class ints,change event
  classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712
  classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712
  classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42
```

| Stage | What happens | Who acts | Who decides |
| --- | --- | --- | --- |
| Dispositions | Every in-scope integration is given a disposition under the policy, with its GitHub issues and the deprecation mailbox as evidence | Ada | The API product lead approves before Attio and GitHub change |
| Wave scheduling | NOTIFY and ENTERPRISE\_GRACE integrations get a cutoff wave on their Attio record | Myco | The API product lead approves the waves |
| Batch review | The scheduled batch is checked against the policy and the current dispositions | Myco | The API product lead confirms |
| Confirmations and corrections | Named integrations are re-derived after migrations, a bug fix and a revoked extension, with waves undone where needed | Ada, then Nova for replies | The API product lead approves, and partner success sends the replies |
| Revised cutoff policy | Every NOTIFY and ENTERPRISE\_GRACE integration is re-derived under the new threshold and grace period, deadlines included | Ada and Myco | The API product lead approves |
| Clearances and new bugs | Cleared escalations and newly blocked integrations go through the full rule order again | Ada | The engineering lead confirms the bug scope and the API product lead approves |
| Closeout | Totals per customer tier, a comment on each closeout issue in GitHub and a closeout record in Attio | Myco | The API product lead signs off |

Stages of an API deprecation cycle. Integrations, rules and dates in this example are illustrative.

## When the policy itself is revised

Revised Cutoff Policy v2 changes two numbers: the usage threshold under rule R5 and the grace period under R6. That sounds like a deadline update, but it can change which integrations qualify for enterprise grace at all. Ada re-derives every NOTIFY and ENTERPRISE\_GRACE integration through the full rule order with the new figures, and Myco recalculates each wave and deadline from the result rather than shifting the old dates.

Clearances need the same care. When partner success clears an escalation, the integration does not drop straight into NOTIFY; it is walked through every rule, and another one may still apply. When engineering traces a bug to two more integrations, the block can reopen an integration that had already moved past it, and its wave is undone. Customer confirmations follow the same path: Nova hands each one to Ada, then drafts the reply on that customer's own thread with the integration ID and its new disposition, and partner success sends it.

## What the checks catch

-   A cleared escalation recorded as NOTIFY or ENTERPRISE\_GRACE without the rest of the rules being applied
-   Waves and deadlines kept from the old policy after the revised threshold and grace period took effect
-   A wave left on an integration whose disposition changed to blocked or migrated
-   An integration already scheduled that a newly traced bug should reopen
-   A confirmation reply on the wrong customer thread, or one that leaves out the integration ID

## What stays with people

-   Approving every disposition and wave before Attio or GitHub is updated
-   Granting and revoking extensions, which stays with partner success
-   Sending every customer email, which Nova drafts in Gmail or Outlook
-   Signing the per-tier closeout

## Integrations in this workflow

Kylon is not a developer portal or an API gateway, and it does not replace either. It sits across the CRM, the repository and the mailboxes the team already works in, and keeps the migration's decisions in one room.

-   Attio
    
-   GitHub
    
-   [Gmail](https://kylon.io/integrations/gmail)
-   Google Drive
    
-   Outlook
    
-   [Slack](https://kylon.io/integrations/slack)

-   **Attio** holds each integration record with its disposition, wave, deadline and closeout notes
-   **GitHub** holds the tracking issue for each integration, the bug issues and one closeout issue per customer tier
-   **Outlook** is the deprecation mailbox where customers reply to notices
-   **Gmail** carries migration confirmation threads, answered through drafts a person sends
-   **Google Drive** keeps the deprecation policy, its revisions and the partner success memos
-   **Slack** is where engineering and partner success post fixes and clearances

## Where to start

Start with the integrations on one deprecated endpoint. Connect Attio and the GitHub repository with the tracking issues, put the policy in Drive, and let the room guidelines carry one rule: every change in disposition is re-derived through the full rule order, and the API product lead approves before any record or wave changes.

> “A cleared escalation goes back through every rule, and the wave follows the result.”

## Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.

Set-up prompt

Set up our API deprecation migration desk in this Room. Take it one step at a time and wait for my OK before you move on.

1. Connect Attio, GitHub, Gmail, Google Drive, Outlook and Slack. Tell me which ones still need connecting.
2. Ask me who works this desk: the API product lead, the partner success managers and the engineering lead. Help me invite them to this Room.
3. Build an API Sunset App with columns Dispositioned, Wave scheduled, Blocked or escalated and Migrated, one record per integration. Pull the in-scope integrations from Attio along with their GitHub tracking issues and dispositions.
4. Check each integration against our policy in Google Drive, its GitHub issues and the deprecation mailbox in Outlook. Propose a disposition for every integration and show me any that fail or conflict.
5. Draft cutoff wave schedules for each integration category our rules define, and draft all customer replies in Gmail, Outlook or Slack. Never update Attio or GitHub, and never send any message, until the API product lead approves dispositions and waves and partner success sends the replies.
6. Write the full rule order and who approves what into this Room's guideline, so every new integration follows the same path.
7. After one clean deprecation cycle, offer to turn the disposition and wave review into an Automation.

Before you start, ask me for our rules one at a time.

[Get started](https://app.kylon.io/sign-up)

Your first company harness. Where humans and agents run your business together.

[Get started](https://app.kylon.io/sign-up)

## More Use Cases

[View all](https://kylon.io/use-cases)

[

### Backup Restore Verification: Backups Proven Restorable Within Their Class Interval

A backup counts only once someone has proved it restores. Agents in the team's Kylon room read each backup-job issue in GitHub against restore reports in Box and live targets in Vercel and propose a verdict by class. The reliability lead approves before any issue changes.

Software & SaaSIT & security operations

](https://kylon.io/use-cases/backup-restore-verification)[

### Bug Bounty Triage: Valid Findings Paid From the Weekly Budget, Reversals Included

A weekly bug bounty batch is triaged in one Kylon room. Agents check each ClickUp submission against scope, GitHub issues and Stripe payout history, allocate the week's budget, and the security lead approves every disposition and payout.

Software & SaaSIT & security operations

](https://kylon.io/use-cases/bug-bounty-triage)
