SA-301d · Module 2

Deprecation & Sunset Lifecycle

3 min read

APIs must eventually retire old versions. The deprecation lifecycle determines how gracefully that retirement happens. A well-managed deprecation gives consumers predictable timelines, migration guidance, and monitoring that shows exactly who is still using the old version. A poorly managed deprecation breaks consumers on the day the version is turned off, generating a support surge that costs more than maintaining the old version for another quarter.

  1. Announce with Sunset Headers When a version enters deprecation, add the Sunset HTTP header to every response: Sunset: Sat, 01 Nov 2026 00:00:00 GMT. The header is machine-readable — consumers that monitor it can automate migration alerts. Pair the header with a Deprecation header that marks the date the deprecation began. Two headers, full lifecycle visibility.
  2. Provide Migration Guides Document every change between the deprecated version and the replacement. Field renames, structural changes, new authentication requirements, removed endpoints. The migration guide should include before/after request and response examples. The consumer's migration cost determines whether they migrate on time or escalate when the version is turned off.
  3. Monitor and Communicate Track deprecated version usage weekly. Contact consumers still using deprecated versions at 90 days, 30 days, and 7 days before sunset. Provide direct support for high-volume consumers. The goal is zero traffic to the deprecated version on sunset day. If traffic remains, decide whether to extend — but set a hard deadline that does not slip more than once.