The VP went back to school.
Not a sabbatical. An actual UX program. He came back with enough knowledge to have opinions and enough authority to act on them without being questioned. His opinion was that his division needed its own design system. The org system was fine for the rest of the organization. His division needed to stand out in the market. He had studied user experience now. He understood what the division needed in a way that the shared system could not provide.
The org design system did not end that day. Nobody said it was over. It continued to be maintained, updated, and documented. It simply stopped being the system his division used. And because his division was large enough to matter, the org system lost its most visible proof of adoption without a single conversation about whether that was the right decision.
This is how most design systems end. Not with a decision. With a divergence. One division builds something parallel. Then another. The org system persists because nobody has the political will to formally retire it — and because someone, somewhere, is still using it and does not want to be told that the investment they were pushed to make was wrong. Old systems never die. They accumulate parallel replacements until the original is a legacy system that everyone maintains and nobody mentions.
A design system that nobody planned to retire does not end. It rots in place. Quietly. The way all neglected things do.
Why Old Systems Never Die
The persistence of a deprecated design system is not irrational. It is entirely rational from the perspective of the people who are keeping it alive.
Reason 1 — The Investment Argument
Someone was pushed to implement the system. It cost time, political capital, and engineering hours. The people who absorbed that cost do not want to repeat it for a replacement they were not consulted about. Their resistance to the sunset is not stubbornness. It is a legitimate grievance about not being heard the first time. Retiring the system without addressing that grievance confirms their original concern: their input was never the point.
The system persists not because it is good. Because its abandonment would confirm that the original implementation decision was wrong. And nobody wants to be the person who signed off on something that is now being replaced.
Reason 2 — The Parallel System Problem
When one division builds a parallel system — as the VP did — the org system does not disappear. It bifurcates. Two systems now claim legitimacy. The people maintaining the original have no incentive to sunset it because doing so would validate the parallel system's existence. The people running the parallel system have no incentive to consolidate because that would mean giving up the autonomy they built. Both systems continue. Neither is fully resourced. Both accumulate technical debt. The organization maintains two half-systems instead of one whole one.
Reason 3 — The Absence of a Sunset Protocol
No design system was designed to end. The charter, the governance model, the contribution process — all of it was built for operation, not for conclusion. There is no defined trigger for retirement. No defined process for transition. No defined moment at which the organization formally acknowledges that the system has served its purpose and a managed handoff is beginning. Without that protocol, the system’s end is always improvised. Improvised endings are always chaotic.
A design system without a sunset protocol is not a permanent solution. It is a temporary solution with no defined expiry date. Those always outlast their usefulness by years.
What a Managed Sunset Looks Like
A design system that ends on its own terms is a design system that succeeded all the way to the end. The managed sunset is not an admission of failure. It is the final act of a governance model that worked.
It has four stages.
Stage 1 — The Trigger
A defined condition that initiates the sunset process. Not a feeling. Not a leadership decision made in a quarterly review. A measurable trigger: adoption drops below a defined threshold, a parallel system reaches production parity, a platform shift makes the existing architecture unmaintainable. The trigger was agreed upon when the system launched. When it is met, the sunset process begins automatically — not as a surprise, but as a planned response to a condition that was always possible.
Stage 2 — The Consultation
Before any sunset is announced, the people who have been using the system are consulted. Not informed. Consulted. The same distinction that mattered at governance design applies at governance conclusion. What do they need from the transition? What would make the handoff viable within their existing workload? What concerns do they have about the replacement that have not been addressed?
The consultation is not a vote. The sunset may proceed regardless of the outcome. But the people absorbing the transition cost deserve to be asked before the decision is finalized. Every time they are not asked, the next transition becomes harder — because the investment argument grows stronger with each cycle of being ignored.
Stage 3 — The Freeze and the Handoff
The system enters maintenance-only mode. No new components. No new features. Security and accessibility patches only. The codebase is frozen at a stable version. The documentation is archived. The migration path to the replacement is documented, scoped, and supported for a defined period.
Stage 4 — The Retirement
A defined date. Announced at the start of Stage 3, not at the end of it. Every team using the system knows when support ends. Every team has the migration path. The retirement date is not a surprise. It is the conclusion of a communicated process that began when the trigger condition was met.
The system that ends on a defined date, with a migration path, after a consultation, is not a failure. It is a governance model that ran its full lifecycle. That is worth naming. Most design systems never get there.
Three Rules for a Sunset That Holds
Rule 1 — Name the End Before It Arrives
Add a sunset trigger to the design system charter. One sentence: the condition under which the sunset protocol initiates. It does not have to be precise. It has to exist. A charter that defines how the system starts but not how it ends has only done half the governance work.
Document the trigger in Notion or Confluence alongside the charter. Not in a separate governance document that nobody reads. In the same place the charter lives. When someone opens the charter to understand how the system works — they also see how it ends. That is what a complete governance model looks like.
A governance model without a sunset clause is a governance model that assumes the system will last forever. No system lasts forever. The assumption is always wrong. The only question is whether the end is planned or improvised.
Rule 2 — Freeze the Codebase, Not the Knowledge
When the system enters Stage 3, the codebase freezes. The knowledge does not. Every decision that was made — why a component was built the way it was, what alternatives were considered, what edge cases the implementation accounts for — gets documented before the people who hold that knowledge move to the next project.
GitHub handles this natively for teams already using it for component versioning — a decision log in the repository, free for public repositories and standard for most engineering organizations. The frozen codebase at a stable version. The decision history in the commit log. The migration notes in the README. The knowledge is preserved even when the system is not.
Rule 3 — Consult Before You Sunset
Before the sunset is announced — run one session with the teams most affected. The question is not whether the sunset will happen. The question is what they need from the transition. Two things come out of that session: concerns that can be addressed before the announcement, and concerns that cannot be addressed but deserve to be acknowledged.
Loom makes this asynchronous for distributed teams — a recording that explains the sunset trigger, the proposed timeline, and the three specific questions you need answered. Teams respond on their own time. The responses surface the real concerns before the announcement, not after. Free tier covers twenty-five videos.
The team that was consulted before the sunset will help with the transition. The team that was informed after the decision will resist it. Not out of irrationality. Out of pattern recognition. They have seen this before. They know how it ends when they are not consulted. They are not wrong.
The Quick Win: Write the Sunset Clause
This week: open your design system charter. Find the section that defines success. Add one sentence directly below it.
The sentence is: the condition under which this system enters sunset protocol. It does not have to be final. It does not have to be precise. It has to exist.
Example: "This system enters sunset protocol when adoption drops below 30% across active squads for two consecutive quarters, or when a replacement system reaches production parity and a migration path is documented."
Share it with your engineering lead. Ask them one question: does this feel like a fair trigger, or would you push back on it? Their answer tells you whether the governance model is shared or whether it is still just yours.
The Argument
The VP who built a parallel system was not wrong that his division had different needs. He was wrong that the answer was a separate system built without consultation, accountability, or a plan for what happens when his division and the org eventually have to reconcile. The implementers who kept the old system alive were not wrong that their investment deserved to be heard. They were operating rationally inside a governance model that had never been designed to end. Both failures are the same failure. A governance model that excluded the people it governed at every stage — at design, at enforcement, and at conclusion. Build the sunset clause before the system launches. Consult before you sunset. The end of a design system is governance work. Treat it like it is.
Disagree loudly. Inspire boldly.
And remind me — falsely if needed — that somewhere a design system was retired on a defined date, after a consultation, with a migration path, and nobody had to discover three years later that the old system was still running in production.
Before you go, entertain this for a second
Does your design system charter have a sunset clause — and if not, what would the trigger be if you wrote one today?
