CASE 170 · STOIC · 2024
Old services that retire on schedule, not on incident.
An enterprise SaaS company had 23 deprecated services still running because no one had a clean process for decommissioning. Two of them caused incidents in a year. We built a service-deprecation framework with timelines, callers-inventory tracking, and an automated decommission flow.
Enterprise SaaS
PLATFORM
2024
RESULTS
What changed, by the numbers.
SERVICES DECOMMISSIONED
17
INCIDENTS FROM ORPHAN SERVICES
0
DEPRECATION TIMELINES
PUBLIC
CALLER INVENTORY
AUTO
HOW IT WENT
The 23 deprecated services existed because deprecation was always somebody else’s problem to start. Owners had moved teams; callers were unknown; the risk of decommissioning was unmeasured. Two services had caused incidents during the year because they’d been running unattended on patches that never got applied.
The framework defined deprecation phases — announced, sunset-warned, restricted, decommissioned — each with a target date and an automated check. API Gateway usage metrics surfaced caller inventory automatically; callers got notified at each phase. Backstage rendered the public deprecation status so teams could plan around it.
17 services decommissioned on schedule in the first year. Incidents from orphan services dropped to zero. The framework runs as a quarterly rhythm — services get nominated for deprecation, timelines are set, the automation handles the rest. The team now starts deprecation almost as routinely as they ship new services.
RELATED · SAME DOMAIN
Other engagements in this space.
READY WHEN YOU ARE
Let's get your AWS bill (and architecture) in order.
The discovery call is free. You walk away with at least one concrete idea — even if we never work together.