"When our site was built, I recall being told that components like shadcn or Radix were used. I recently saw news that this has changed to something else—does that mean our site needs to be rebuilt too? If there will be additional costs, I'd like to know early." We recently received this inquiry from a project manager who outsources their corporate website. Internal technical shifts often reach project owners as immediate anxiety over whether it will cost money again.
To get straight to the conclusion, in most cases, existing sites do not require any action. However, when project owners understand why nothing needs to be done, they can spot unnecessary rebuild proposals from development companies. In this article, we outline what changed, the impact on existing sites, and how to verify things with your development company so that you can make decisions calmly.
What changed: The creators behind the component internals have switched
First, let us explain the situation with minimal technical jargon. Many websites and applications do not build fine-grained components like buttons, input fields, and menus from scratch; instead, they build upon pre-built component libraries. A leading example is the component collection known as shadcn/ui.
This shadcn/ui has switched the underlying foundation used inside its components from Radix to a new one called Base UI, making Base UI the default for newly created projects. Base UI was rebuilt by the very engineers who originally created Radix, incorporating lessons learned over several years. It does not alter appearance or usability; the reality is simply that the creators behind the structural framework supporting component internals have changed.
Here, there is only one key takeaway for project owners: this change is merely a matter of default settings for newly created projects, and it does not break sites that are already up and running.
Existing sites generally do not require any changes
The most important fact this time is that existing sites do not need to be migrated. The legacy Radix foundation has not been deprecated and will continue to be supported. Future updates and new components will also be provided for both Base UI and Radix. In short, sites currently running on Radix will not suddenly stop working if left as they are.
Therefore, seeing this news is no reason to brace for a rebuild. If a development company presents a large estimate claiming "the foundation has changed, so let's rebuild entirely," that could very well be an excessive proposal using change as an excuse. Deciding whether to rebuild should not be driven by changes to a component library's defaults, but strictly by whether your own site has actual defects or real reasons to be overhauled. General criteria for deciding whether to leave a site as-is or rebuild it are also summarized in our article on legacy site maintenance.
| Project owner's situation | Recommended action |
|---|---|
| Current site is working without issues | No action needed. Radix continues to be supported |
| Building a new site or doing a major overhaul | Using Base UI as the default for new builds is fine |
| Received a proposal to "rebuild completely because the foundation changed" | Verify the reasons. Change itself is not justification for a rebuild |
The benchmark for decision-making is not whether the component library changed, but whether rebuilding provides tangible benefits to your site. Keeping this distinction clear prevents unnecessary expenditures.
The only two points you should still keep an eye on
Even though no action is required, there are two points that will give project owners peace of mind to keep in mind.
The first is the default settings when adding new elements. When adding new pages or features to an existing site, running development tools without specifying configurations will automatically create new components on the Base UI side. While having old and new coexist in a single site rarely causes major issues, if you want consistency, you only need to request: "Please match these additions with our existing setup." The second is how to proceed if you migrate everything together in the future. If you ever want to unify on Base UI down the road, there is no need to do it all at once; you can replace components one by one while keeping the site live. This means gradual migration instead of a total rebuild. How to organize components as design assets is also covered in our article on AI-ready design systems and our article on reusable UI design.
In short, there is no reason to migrate everything in a hurry; you can proceed incrementally whenever the need arises. Knowing just this single point puts you on equal footing when communicating with development companies.
All it takes to check with your development company is this one question
In reality, there is virtually nothing project owners need to do right away. If you are concerned, simply asking your development company this one question is plenty: "Does this shadcn/ui update impact our site or require any action on our part? If so, please explain why and what risks exist if we take no action."
A reputable development company will provide concrete answers, such as "the existing setup is fine as is" or "we only want to align policy for new additions." Conversely, if they recommend a major rebuild without clear justification, consider it a sign to pause and seek a second opinion.
Make it a rule not to rebuild with every shift
A change in the foundation of a UI component library is a common event behind the scenes in tech, yet from a project owner's perspective, it often triggers worries about recurring costs. In this case, existing sites generally require no changes, and the legacy framework remains supported. Decide whether to rebuild based on whether there are real benefits for your site, not on library shifts. Holding to this principle will keep you from being swayed by technological trends.
If you have concerns like "I'm anxious because the technology behind our commissioned site changed again," "I can't tell if our development company's proposal is excessive or reasonable," or "we want to add new features but worry about consistency with the existing setup," please feel free to reach out through GleamHub's web development and renewal consultation. We will stand alongside project owners to pursue approaches that advance only what is necessary without disrupting your current build.
