# Service Deprecation Plan

> Use when performing service deprecation plan — template for planning and executing the deprecation and decommissioning of services. Covers consumer impact analysis, migration path definition, communication timeline, traffic monitoring, graceful shutdown procedures, and resource cleanup to safely retire services without disrupting dependents.

- Skill: `cloudthinker-ai/service-deprecation-plan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add cloudthinker-ai/service-deprecation-plan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cloudthinker-ai/service-deprecation-plan/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cloudthinker-ai (https://skillmd.com/u/cloudthinker-ai)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/cloudthinker-ai/service-deprecation-plan

---


# Service Deprecation Plan Skill

Plan deprecation of **{{ service_name }}** (replacement: **{{ replacement_service }}**, sunset: **{{ sunset_date }}**).

## Workflow

### Phase 1 — Impact Analysis

```
SERVICE INVENTORY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Service: {{ service_name }}
[ ] Current traffic: ___ requests/day
[ ] Consumers:
    Consumer            | Integration Type | Traffic | Owner
    ____________________|__________________|_________|______
                        |                  |         |
                        |                  |         |
                        |                  |         |

[ ] Data owned by service:
    - Databases: ___
    - Storage: ___ GB
    - Data migration required: [ ] YES  [ ] NO
[ ] Scheduled jobs/cron tasks: ___
[ ] Infrastructure resources:
    - Compute: ___
    - Monthly cost: $___
```

### Phase 2 — Migration Path

```
MIGRATION STRATEGY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Replacement service: {{ replacement_service }}
[ ] Feature parity assessment:
    Feature              | Legacy | Replacement | Gap
    _____________________|________|_____________|_____
                         |        |             |
                         |        |             |
                         |        |             |

[ ] Migration guide for consumers:
    [ ] API mapping document (old endpoint -> new endpoint)
    [ ] SDK/client library updated
    [ ] Code examples provided
    [ ] Data migration tooling available
[ ] Migration support:
    - Support channel: ___
    - Office hours: ___
    - Migration deadline: ___
```

### Phase 3 — Communication Timeline

```
DEPRECATION TIMELINE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
T-6 months: [ ] Deprecation announcement
            [ ] Migration guide published
            [ ] Deprecation headers added to API responses

T-3 months: [ ] Reminder notification to all consumers
            [ ] Usage report sent to consumer teams
            [ ] Migration support sessions offered

T-1 month:  [ ] Final warning notification
            [ ] Unmigrated consumers contacted directly
            [ ] Rate limiting on deprecated endpoints (optional)

T-0:        [ ] Service sunset: {{ sunset_date }}
            [ ] Traffic rejected with informative error
            [ ] Redirect to replacement service docs

T+1 month:  [ ] Infrastructure decommissioned
            [ ] Data archived or migrated
            [ ] DNS records removed
```

### Phase 4 — Graceful Shutdown

```
SHUTDOWN PROCEDURE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Traffic monitoring:
    - Current consumer count: ___
    - Consumers migrated: ___
    - Consumers remaining: ___
[ ] Pre-shutdown checks:
    [ ] Zero or near-zero traffic confirmed
    [ ] Remaining consumers acknowledged sunset
    [ ] Data backup taken
[ ] Shutdown steps:
    [ ] 1. Return 410 Gone with migration info
    [ ] 2. Stop accepting new requests
    [ ] 3. Drain in-flight requests
    [ ] 4. Stop service processes
    [ ] 5. Remove from service registry/load balancer
    [ ] 6. Remove DNS entries
```

### Phase 5 — Resource Cleanup

```
DECOMMISSIONING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Compute resources terminated
[ ] Database instances removed (after archive period)
[ ] Storage buckets emptied and deleted
[ ] CI/CD pipelines removed
[ ] Monitoring dashboards and alerts removed
[ ] Source code archived (read-only)
[ ] Documentation marked as deprecated
[ ] Secrets/certificates revoked
[ ] IAM roles/permissions removed
[ ] Monthly cost savings realized: $___
```

## Counter-Rationalizations

| Shortcut | Counter | Why |
|----------|---------|-----|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |

## Output Format

Produce a service deprecation plan with:
1. **Service profile** (traffic, consumers, resources, costs)
2. **Migration path** (replacement mapping, feature parity, support)
3. **Communication timeline** (notifications at each milestone)
4. **Consumer migration status** (migrated vs remaining)
5. **Decommissioning checklist** (resources to clean up, cost savings)