Zhivko Todorov
ALL CASE STUDIES

CASE 170 · STOIC · 2024

DEPRECATIONAPI LIFECYCLEGOVERNANCEBACKSTAGE

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.

INDUSTRY

Enterprise SaaS

DOMAIN

PLATFORM

DELIVERED

2024

STACK

BACKSTAGE·API GATEWAY USAGE METRICS·CLOUDWATCH METRICS·EVENTBRIDGE·TERRAFORM

RESULTS

What changed, by the numbers.

SERVICES DECOMMISSIONED

17

ON SCHEDULE

INCIDENTS FROM ORPHAN SERVICES

0

POST-FRAMEWORK

DEPRECATION TIMELINES

PUBLIC

BACKSTAGE-VISIBLE

CALLER INVENTORY

AUTO

FROM API USAGE

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.

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.

Or email directly →