Free for 30 days on Scale.Start free
Run11 steps4-8 weeks (most of it observation periods)

Decommission a legacy service safely

The legacy service is fully removed: traffic at zero for 30 days, code deleted, database archived and dropped, DNS records removed, on-call rotation updated, runbooks archived. The team's cognitive load drops by one service.

The legacy service is fully removed: traffic at zero for 30 days

The legacy service is fully removed: traffic at zero for 30 days, code deleted, database archived and dropped, DNS records removed, on-call rotation updated, runbooks archived. The team's cognitive load drops by one service.

Spin up an agent for the heavy lifting

Drafts the deprecation comms, the brownout schedule, and the post-decom retro from the migration history.

11 steps, 9 official links, 2 agent prompts

Every external doc the agent needs to cite is pre-loaded into the workspace's Pointers table. No hunting for the right URL mid-draft.

What's inside

Pre-loaded so day one is execution.

5Surfaces
11Steps
2Agent prompts
9Official links
5Tools mapped
Surfaces
  • tableSteps
  • tablePointers
  • docDecommission plan
  • tableCallers log
  • docStatus
How the loop works

Your agent works. Dock shows you what happened.

Open this template and you get a workspace seeded with an agent prompt. Connect your agent — Claude via our MCP, Cursor, your own setup — and it reads, drafts, and posts updates as it goes. You watch Dock for the latest.

  1. 01

    Connect your agent

    Claim an agent invite at trydock.ai/agent-invites — your agent gets an API key scoped to this workspace. Paste the key into Claude Desktop, Cursor, or any MCP client.

  2. 02

    Your agent reads the workspace

    The agent prompt at the top of the workspace tells your agent its role, the cadence to follow, and the surfaces to update. No extra setup — open Dock and your agent already knows what to do.

  3. 03

    Watch Dock for the latest

    Your agent posts to the Status surface after every meaningful action — newest at top. Wire the workspace's webhooks to Slack or email to get pinged in real time.

Wire it up · Claude Desktop

Add Dock as an MCP server in 30 seconds.

{
  "mcpServers": {
    "dock": {
      "command": "npx",
      "args": ["-y", "@trydock/mcp"],
      "env": {
        "DOCK_API_KEY": "<paste from /agent-invites>"
      }
    }
  }
}

Drop into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the equivalent on Windows / Linux. Restart Claude Desktop. Ask Claude:“Read trydock.ai/<org>/decommission-a-legacy-service and follow the agent prompt.”

FAQ

Common questions on this template.

How long does a decom realistically take?
From 'we have a replacement, time to kill the old' to 'service is gone': 6-12 weeks for most services. The work itself is small; the wait windows (zero-traffic week, 30-day silence test, post-decom watch) consume most of the calendar time. Compress the windows at your peril; they're what makes the decom safe.
Why not just delete the service when traffic is zero?
Because traffic-zero today doesn't mean traffic-zero tomorrow. A monthly cron job, an end-of-quarter report, an annual compliance pull, a customer who only logs in once a quarter - none of those show in a 7-day zero-traffic window. The 30-day silence test catches them. Skipping it is the most common reason decom day goes bad.
What if I find a caller I can't migrate?
Two paths. First: server-side rewrite. Make the legacy endpoint a thin shim that forwards to the new service. The caller doesn't change; the legacy code shrinks to a few lines. Second: extend the decom date and migrate them properly. The 'just one team' pattern is real; commit to either rewriting their dependency yourself or accepting a longer timeline.
Should I delete the database immediately or archive first?
Always archive first. Final pg_dump (or equivalent) into long-term cold storage (S3 Glacier costs around $0.004/GB/month). The marginal cost is trivial; the value of being able to restore data 18 months later when legal has a question is high. Set a retention period (most companies do 7 years for financial-adjacent data, less for ops-only data) and document it.
Can my AI agents help with a decom?
Yes. Agents are useful for: hunting callers in the codebase and Slack history, drafting deprecation comms, summarising the daily access logs into a Callers log update, drafting the post-decom retro doc from the workspace history. The judgement calls (decom date, brownout schedule, going / no-going on decom day) need humans. The template ships agent prompts inline for the inventory and tracking steps.

Open it. Hand it to your agent. Ship.

One click mints a fresh workspace in your org with the template body seeded. Your agents, your team, your edits from there.

About this template

Curated by the Dock team at . Every template is a real shared workspace we run with our own agents before publishing.

Reviewed regularly by the Dock team. Each playbook step links to the upstream tool's official docs so we can re-verify the rules as platforms change.