You need to retire a platform API used by 60 services. Describe the plan.

What the interviewer is testing

Whether you treat the migration burden as the platform's problem, which is what separates a platform teams trust from one they defend against.

The plan

1. Know exactly who uses it, before announcing anything. Per-consumer usage telemetry, including which endpoints and how often. This is the prerequisite and it is missing more often than teams admit. Without it, the announcement produces sixty inquiries you cannot answer.

2. Ship the replacement first. Never deprecate before the alternative exists, is documented, and has been used successfully by at least a couple of pilot teams. Deprecating into a gap destroys credibility.

3. Announce with a timeline in release cycles, not dates. Notice proportionate to the effort you are imposing — for sixty services, that is quarters, not weeks.

4. Make migration cheap. A codemod, a compatibility shim, a bot that raises the pull request. The platform team doing the first several migrations itself both accelerates adoption and reveals what is actually hard about it.

5. Run both in parallel long enough that teams can schedule the work rather than have it dropped into a sprint.

6. Track migration per consumer and chase the stragglers individually. The last 10% always needs direct engagement — usually teams with no capacity or an unusual usage the migration path does not cover.

7. Turn it off in stages — brownouts, where the old API fails for short scheduled windows, are an effective way to find consumers who ignored every notification, with a controlled blast radius.

What a strong answer adds

Signalling in-band as well as out-of-band: Deprecation and Sunset headers on responses, log warnings on use, and visible status in the catalogue. Announcements in a channel are missed; a warning in the caller's own logs is not.

And accepting that some consumers genuinely cannot migrate in time — a documented, time-bound extension with a named owner is better than either slipping the whole programme or breaking them.

Common weak answers

Announcing a date and expecting compliance. Turning it off and dealing with the fallout.