Introduction

If you’ve been following Liferay’s recent messaging, you’ve probably heard a strong emphasis on avoiding customizations and building with client extensions instead. That’s not an accident. There are very good reasons why client extensions have become the centerpiece of our story.

Client extensions live outside of Liferay. That means they don’t alter the core platform or depend on internal implementation details. When you upgrade Liferay, client extensions are far less likely to break, and that translates directly into reduced upgrade effort, lower maintenance costs, and fewer sleepless nights.

On top of that, client extensions are built on top of our Headless APIs, which are far more stable and versioned than Liferay’s internal APIs. This API-first approach ensures that your integrations and extensions continue to work even as the platform evolves. In other words: when you build with client extensions, you’re building on solid ground.

It’s a cleaner, safer, and more upgrade-friendly approach, and that’s why we’ve been shouting “Use client extensions!” from the rooftops.

But... sometimes that message gets misunderstood. Somewhere along the way, “Use client extensions” has been interpreted by some as “Don’t customize Liferay anymore.” And that’s a misunderstanding that needs to be cleared up, because customization has always been, and still is, one of Liferay’s greatest strengths.

Misinterpreting the Message

Let’s be clear: if “Use client extensions” sounds like “You shouldn't customize Liferay,” then something has been lost in translation.

Liferay has always supported deep customization, and that hasn’t changed. Everything that’s been possible since Liferay 7.0 is still there: OSGi modules, portlet WARs, service wrappers, custom portlets, JSP overrides, ... You can still extend, override, or supplement Liferay’s built-in components using the same powerful OSGi-based mechanisms that made the platform famous for flexibility.

You can still build Java-based portlets using JSF or Spring MVC. You can still deploy your own Service Builder modules that define entities, services, and persistence layers integrated directly with Liferay’s frameworks. The asset framework, workflow framework, permission framework, and all of the surrounding APIs that Service Builder has traditionally worked with are still fully supported.

And if you want to take a modern hybrid approach, you can use REST Builder to expose those same Service Builder entities and services through custom Headless APIs. That means you can continue implementing complex backend logic in Java (leveraging everything you know about Liferay’s backend frameworks) and still make that functionality available for consumption by your React, Vue, or custom element frontends.

Liferay’s heritage as a highly extensible, full-stack platform hasn’t gone anywhere. What has changed is our emphasis; because we’ve learned, through many years and many upgrades, that customizations come with a cost.

The Real Cost of Customization

When you customize Liferay by touching internal APIs, you’re tying your code to the internal structure of the platform. Those APIs are not guaranteed to remain stable between releases; in fact, they often change as we improve or refactor the platform. That means that every upgrade becomes an exercise in testing, debugging, and refactoring your custom code.

The cost isn’t just technical; it’s organizational. Time, budget, and resources get consumed by the upgrade process. That’s why many Liferay customers historically dreaded upgrades: not because of the platform itself, but because of the customizations built on top of it.

There are ways to manage that risk.

• Work with experienced partners who know the internal API changes and can help streamline your upgrade path.

• Use LTS (Long-Term Support) versions of Liferay, which can give you up to five years of supported stability.

These approaches can significantly reduce upgrade pain, but they don’t eliminate it entirely.

And that’s exactly why we emphasize client extensions, because they do eliminate those upgrade costs. When your solution lives outside the platform and talks to it through versioned, stable APIs, upgrades stop being a major project and become routine.

The Pragmatic Balance

That said, we’re realists. We know you can’t do everything through client extensions. Some features (especially those that need to modify deep platform behavior or extend a service that doesn’t have a public API yet) still require traditional customization. And sometimes, your organization already has a deep investment in Java-based portlets, JSPs, or Service Builder modules. You’ve built that muscle over the years, and it still delivers value.

So yes, you can absolutely still customize Liferay. The difference now is that we want you to do so with full awareness of what that means: the trade-offs, the maintenance costs, and the long-term implications.

In short:

• Client extensions are the first choice for extensibility and upgrade safety.

• Customizations are still available and supported, but come with a maintenance price tag.

Knowing which tool to use (and when) is the key to being successful on the platform.

Conclusion

So when you hear us say “Use client extensions,” don’t hear “Stop customizing.” Hear “Customize smartly.”

Customization isn’t dead; it’s evolved. Client extensions are simply the next evolution of Liferay’s customization story: one that embraces stability, scalability, and long-term maintainability. But for those times when deep customization is the right choice, the platform still has your back, just as it always has.

And that’s something that truly sets Liferay apart. Many digital experience platforms today either lock you out of customizing the system or make it so costly and unsupported that it’s effectively impossible. Liferay has never taken that route, and we don’t plan to. The ability to tailor the platform to your organization’s needs, to extend it deeply when it makes sense, remains one of our core differentiators.

So yes, you’ll keep hearing us repeat the “use client extensions” message loud and clear. But remember: that message isn’t about shutting down innovation. It’s about making sure you understand the cost of customizations before you choose that path, and empowering you to make the choice that’s right for your organization.

Customization is dead? Not quite. Long live customization.