In a design system, a deprecated data table's removal release arrives with thirty usages left across five teams' apps; what do you do?

## The situation A **design system** deprecated its old data table in favour of a new one, published a migration guide and a codemod, and announced removal for the next major release. That release is now ready, and a scan of consuming codebases on a travel-expense tool still finds **thirty usages** across five teams: the expense report list, the approvals queue, the finance export screen and two admin tools. Shipping the removal as-is, or quietly postponing it, are both tempting and both usually wrong. The first step is diagnosis. ## Why usages remain | Reason | Whose problem | Response | |---|---|---| | The replacement lacks a capability, such as row grouping | The system's | Close the gap, or grant a time-boxed extension for those usages | | The codemod fails on a common pattern | The system's | Fix the codemod and rerun | | The migration guide misses a case teams hit | The system's | Update the guide, help the affected team | | The team knew but did not schedule the work | The team's | Keep the date; offer help, not an extension | | The team never heard about the deprecation | Both | Check the communication path, then decide | Splitting usages this way usually shows that most remaining work sits in a few teams and a few causes. ## Tracking remaining usages This decision is only possible if usages were tracked all along: - **Code scans** across consuming codebases, counting references to the deprecated component per team and per codebase. - **Flagged cases** left by the codemod, counted separately, since they are the hard part. - **Design library usage**, since designs that still use the old table will produce new code that uses it. - **A visible trend**, published with each release, so teams and their managers see progress, and flat lines prompt a conversation early rather than at the deadline. ## Deciding the removal 1. **Resolve the system's blockers first.** If the replacement cannot do the job, holding teams to the date is unfair and will push them to copy the old table into their code. 2. **Help with the hard cases.** Pair with the teams that own the flagged usages; often a few hours of help clears most of them. 3. **Grant extensions only by rule.** Extensions should be time-boxed, tied to a system-side blocker, and recorded, not handed to whoever asks loudest. 4. **Remove on schedule otherwise.** Postponing for teams that simply did not prioritise the work teaches every team that dates are soft, which makes every future deprecation slower. ## What removal at a major means for stragglers Removing the component in a **major release** does not break anything already installed. A team that has not migrated breaks only when it upgrades to the new major, so it can stay on the previous major while it finishes. The cost is that it misses whatever the new major and later releases bring, unless the system team backports fixes to the previous major. Many systems therefore define a limited period of fixes for the previous major, often only for severe and accessibility defects, which gives stragglers time without making the old version a permanent home. ## Preventing it next time After the removal, review the deprecation itself: - Was the window long enough for a component this widely used? - Did the replacement reach feature parity before deprecation started? - Did the codemod handle the patterns teams actually use? - Did every team hear about it, including teams that rarely read release notes? It also helps to look at when usages fell. If most teams migrated in the last two weeks, the window length mattered less than the reminders, and earlier, targeted nudges will do more next time than a longer window. If a few usages never moved at all, the issue is usually a blocker nobody reported, which argues for asking teams about blockers early instead of waiting for the count to fall. The answers feed back into the deprecation policy. Thirty usages at the deadline is a signal about the process as much as about the teams, and the most useful outcome is a next deprecation that finishes on time.