PrimeNG, one of the bigger component libraries, recently changed their licensing model. This meant overnight the repository was archived and bugfixes are gated behind a community license you have to apply for. Medium to large software development teams now have to decide whether to continue with PrimeNG and pay the price or switch.
I've talked to some colleagues in the field and came across different answers on how they continue. In this post I want to share these insights and my personal take.
Pay the license
One team I've talked to decided to bite the bullet, pay, and move on. If you have the budget and need to keep up the velocity up, you're probably best off with this solution. This way you won't have any overhead from migrating away, and can use your team's existing know-how with the framework. Also, Primetek announced development of more components:
Additional components are in active development and will be released as they become production-ready:
- DataGrid
- Gantt
- Diagram
- PDF Viewer
So if you have such a feature on the roadmap planned, it might be worth sticking around. However, we do not know how these will look and if they will fit your use case.
Manual migration
Another option is to migrate manually, component by component. This gives you full control over the result and lets you fix any inconsistencies with your design system along the way, but it's also the most time-consuming path. Depending on how many PrimeNG components you use and how deeply they're woven into your codebase, this can easily take several weeks. If that timeline sounds too long, there's a way to speed it up.
Migration with AI
Migrate using AI, letting an agent rewrite PrimeNG components into the target library, or drop the dependency completely. This should be faster than doing it by hand, but I wouldn't expect wonders. I have not tried this approach yet, but I'm skeptical that this holds up well in practice. From what I've seen, agents aren't yet great at producing pixel-perfect components or fully respecting an existing design system. It might get you a usable first draft, but I expect several more days of manual fine-tuning afterward.
The gap likely grows if you're also switching frameworks rather than just versions: inputs, Tailwind support, and passthrough don't map cleanly between libraries. Styling that relies on PrimeNG's component inputs might need to become hacky custom CSS in something like Material, and vice versa.
Take it as a hypothesis worth testing rather than a conclusion.
Migrate to the Fork
Meet Optimus UI. The openng collective started a fork and migrated all open issues. Given that they just released their first version and have a migration tool, I decided that I would like to try it out on our project. We know that we have to migrate away in the long run, so there should be nothing to lose when switching to the maintained open-source library.
Migrating to OptimusUI
As mentioned there is a migration tool that you need to run and should do the job easily.
First update to the latest version of PrimeNG
ng update primeng@21
Then you install optimus-ui and run their migration tool
npm install @openng/optimus-ui
ng generate @openng/optimus-ui:migrate-from-primeng
You then get a list of references that might need your review. In our case this looked like this:
The following 10 references in 4 files could not be migrated automatically and need manual review:
/src/app/app.config.ts:91 // TODO https://primeng.org/configuration#csp
/src/app/core/layout/components/navigation/navigation.component.ts:12 PRIMENG_TRANSLATIONS,
/src/app/core/layout/components/navigation/navigation.component.ts:38 private readonly primeNGConfig = inject(Optimus);
/src/app/core/layout/components/navigation/navigation.component.ts:69 this.primeNGConfig.setTranslation(PRIMENG_TRANSLATIONS[lang]);
/src/app/core/translation/translation.model.ts:9 export const PRIMENG_TRANSLATIONS: Record<AppLanguage, object> = {
/src/app/shared/components/field-error/form-field-message.component.ts:14 type PrimeNGMessageSeverity =
/src/app/shared/components/field-error/form-field-message.component.ts:21 const MessageTypeToPrimeNGMessageSeverity: {
/src/app/shared/components/field-error/form-field-message.component.ts:22 [type in MessageType]: PrimeNGMessageSeverity;
/src/app/shared/components/field-error/form-field-message.component.ts:62 protected readonly messageSeverity = computed<PrimeNGMessageSeverity>(
/src/app/shared/components/field-error/form-field-message.component.ts:63 () => MessageTypeToPrimeNGMessageSeverity[this.messageType()],
Migration done, but 10 references in 4 files still need manual review. Scroll up to the list above — the CREATE/UPDATE lines that follow only cover what was migrated for you.
Manual migration tables: https://www.openng.org/migration/primeng
As you can see, the things found are just comments, constants, or components that contain the name "PrimeNG" and need renaming. You could argue that in a project that uses mainly technology-agnostic naming, nothing should have been found.
Resolution
Migration to Optimus UI was fast and done within a few minutes. I also did a visual comparison of the before and after, went through our most important flows, and did not find any problems. Our test suite also ran through without any issues.
From my point of view, whatever your team decides, I'd recommend at least trying out Optimus UI in a branch. The switch is cheap to test and easy to revert if something doesn't fit. And if you already know you want out of PrimeNG's commercial license long-term, doing it now while the fork is fresh might make the transition easier.
Are you also using PrimeNG? What is your team doing? I would be curious to find out more.
