How to use
- Start after Token Rollout Checklist and Token Deprecation Plan already define the release and warning order.
- Enter the target token, replacement token, migration stage, adoption, replacement coverage, blockers, docs, telemetry, and remaining old consumers.
- Read the result as a status checkpoint for freeze and removal decisions, not as a substitute for repository-specific migration governance.
See whether migration is really moving
This page fills the gap between “the rollout checklist exists” and “the old token can actually be frozen, deprecated, or removed.”
How to choose between nearby pages
Use Token Rollout Checklist when the next question is what to review before shipping. Use Token Deprecation Plan when the next question is warning cadence, freeze timing, and removal order. Use this page after that, when the next question is whether the migration itself has progressed far enough for freeze or removal.
FAQ
What does this page organize?
It combines adoption, replacement coverage, blockers, telemetry, and remaining old consumers into a compact migration-status checkpoint before freeze or removal.
When should I use this instead of Token Rollout Checklist?
Use Token Rollout Checklist when the next question is what to review before shipping a change. Use this page when the next question is how far the migration itself has progressed toward freeze and removal.
Does this replace repository-specific migration governance?
No. It is a practical migration-status checkpoint and should be combined with the actual repository deprecation policy and release gate.
What is stored in the share URL?
The share URL stores the target and replacement token, migration stage, adoption coverage, replacement coverage, fallback mode, blocker count, docs readiness, telemetry readiness, and old-consumer count.