Knowledgebase

Deprecating and Retiring Endpoints Print

  • 0

Removing things safely.

WHAT TO ESTABLISH FIRST

Who is actually using it.

HOW

Logging by endpoint and by caller.

WHY THAT MATTERS

You cannot notify people you cannot identify.

WHAT TO DO BEFORE ANNOUNCING

Confirm an alternative exists and works.

WHAT NOTICE TO GIVE

Far more than feels necessary.

WHY

Callers have their own release cycles, approvals and priorities.

WHAT THE SEQUENCE SHOULD BE

Announce, with a date Mark responses as deprecated in a header Contact heavy users directly Reduce availability briefly, as a rehearsal Retire

WHAT A REHEARSAL OUTAGE ACHIEVES

It surfaces users who ignored every notice, while recovery is trivial.

WHAT TO DO ABOUT THOSE USERS

Contact them individually.

WHAT TO MONITOR THROUGHOUT

Remaining traffic.

WHAT TO NEVER DO

Retire something with traffic still on it, without warning those callers.

WHAT TO DOCUMENT

The date, the reason and the alternative.

WHAT TO KEEP AFTERWARDS

A response explaining that it was retired, rather than a bare not-found.

WHY

It tells whoever eventually notices what happened.

WHAT TO LEARN FROM EACH RETIREMENT

How long it actually took.


Was this answer helpful?
Back

Are you happy with your experience? Leave us a review on Trustpilot.


Trustpilot