Q&A: what "maintenance only" really means for a service
Questions we kept getting once some services were put into maintenance mode, and what that means operationally.
Q&A
What does it mean when a service is in “maintenance only” mode?
It means we don’t plan major new features for it, but we still:
- keep it within its SLOs
- fix bugs that affect users or dependent systems
- patch security issues
"Maintenance only" is not a euphemism for "abandoned".
Does maintenance-only change who owns incidents?
No.
The owning team remains responsible for:
- responding to incidents
- keeping runbooks and dashboards usable
- communicating risks and limitations to other teams
If a service is important enough to keep in production, it’s important enough to own.
Can we change the service while it’s in maintenance mode?
Yes, but the bar is higher.
We try to:
- avoid risky refactors that don’t reduce operational load or risk
- prefer small, well-understood improvements (better metrics, simplified paths)
Changes that materially improve reliability, cost, or safety are still welcome.
How do we handle dependencies for maintenance-only services?
We document:
- which other services and teams depend on this one
- what they expect (latency, availability, data contracts)
If someone wants to add a new dependency, we:
- ask whether another, actively-evolving service is a better fit
- treat new dependencies as a signal that the service might no longer be "quiet" enough for maintenance-only
What about migrations away from a maintenance-only service?
Ideally, maintenance-only is a step toward decommissioning.
When we put a service into this mode, we:
- write down conditions under which we would retire it
- identify candidate replacement paths
We then:
- avoid adding new responsibilities to the service
- track usage over time, looking for opportunities to migrate callers
Does maintenance-only save on-call effort?
Sometimes.
If we stop adding features that increase complexity, the service tends to:
- become more predictable
- require less firefighting
But if we ignore maintenance, the opposite happens: dependencies evolve, and the service slowly becomes the brittle part of the system.
Takeaways
- "Maintenance only" is a commitment to stability, not a license to ignore a service.
- Ownership and on-call responsibilities stay in place as long as the service is on a critical path.
- New dependencies on maintenance-only services should be deliberate and justified.
- Writing down an exit plan when entering maintenance mode keeps "temporary" states from becoming permanent drift.