The interesting shift here is treating API deprecation as an enforcement and telemetry problem rather than a communication problem. If the old endpoint continues returning 200 with no observable consequence, migration will naturally lose priority until the cutoff becomes an incident.

The per-consumer decision loop is particularly useful. Aggregate traffic can tell you that 8% of requests remain, but it doesn't tell you whether those requests belong to one critical payment integration or hundreds of dormant clients. That distinction should determine how aggressively enforcement progresses.

I’d also treat brownouts as a compatibility test, not just a forcing mechanism. The retry behavior, ownership gaps, and clients that ignore 429s can expose failure modes before hard retirement. That makes the deprecation process itself a form of production readiness testing.