Obsolescencia y retirada de componentes

As a design system scales, some components become outdated, redundant, or superseded by better versions. Keeping them forever bloats the system.

This lesson covers deprecation - retiring components gracefully without breaking consumers.

Never delete a component out from under teams. Deprecation is a phased process: mark it, warn, provide a path, then remove.

Abrupt removal breaks builds and destroys trust in the system. Patience is the whole game here.

Flag the component in code and docs so usage surfaces a warning. The snippet shows a simple runtime warning wrapper.

A deprecation notice must answer three questions: why it is going away, what to use instead, and when it will be removed.

Without a clear replacement, teams cannot migrate and will simply ignore the warning.

Document the before/after for the swap. Where APIs differ, show how old props map to new ones.

Codemods - automated migration scripts - can rewrite usages mechanically, removing nearly all migration friction for large codebases.

Teams have their own roadmaps. A removal scheduled for next week is hostile; one or more major releases away is reasonable.

Announce deprecation in a minor release and remove only in a future major, respecting semantic versioning.

Measure how many apps still use the deprecated component. Usage analytics or code search show real progress.

Do not remove until usage approaches zero or all teams have confirmed migration. Data, not assumptions, drives the timeline.

One changelog line is not enough. Announce in release notes, team channels, and office hours. Repeat as the removal date nears.

People miss messages; over-communicating deprecations is far cheaper than a surprise broken build.

When usage is gone and the deadline arrives, remove the component in a major release. Note the removal clearly in the changelog.

Keep the migration guide live afterward for any stragglers on old versions.

Some bloat comes from adding components too eagerly. A strong intake process and willingness to say no keeps the system lean from the start.

Deprecation cleans up; governance prevents the mess.

A design system that never removes anything is not maturing - it is accumulating debt. Thoughtful sunsetting is a sign of a healthy, evolving system.

Prune with care and the system stays sharp as it scales.

You learned to sunset components gracefully:

• Deprecate in phases - never delete abruptly.
• Communicate why, what to use, and when, with a migration guide and codemods.
• Give generous timelines tied to major releases and track adoption.
• Over-communicate and remove only when usage is gone.

Thoughtful pruning keeps a scaling design system lean and healthy.