Suite or headless? Choosing a platform for public services

Agencies replacing a website or portal usually reach the same fork. One road is a digital experience platform suite, such as HCL Digital Experience or Liferay DXP: one product for content, page building, personalization, login and integrated applications. The other is headless: a content platform such as Contentful or Payload stores structured content and serves it through an API to a front end your team builds, often with Next.js.

We have built on both. Most of the portals we built over the last decade ran on HCL Digital Experience. We redesigned Stanford University’s AXESS portal and implemented it with an accessible theme on Liferay DXP. In 2025–2026 we moved the Ohio Department of Job & Family Services’ sites from HCL DX to the State’s Contentful-based platform, and this website runs on Payload. Neither road is better in general. Here is how the choice looks for public services.

The tradeoffs that matter

Authoring

Suites give editors pages: place components, preview in place, route changes through approval workflows, all built in. Headless gives editors structured entries, such as a service, an office location or an alert, that can appear on many pages and channels. That pays off when the same content shows up in several places, but preview, page assembly and workflow are things you design, not things you get.

Personalization and login

Suites are strongest behind a login: role-based pages, single sign-on, many applications on one screen. That is why so many employee and student portals run on them. Most public information sites personalize very little. Before paying for a personalization engine, write down what you would actually change, and for whom.

Integration

A suite gives you a framework for bringing back-end systems into the portal. Headless moves integration into the front end and your APIs: more freedom, and more responsibility. Forms, search and chatbots don’t come with the content platform, and each one needs a home.

Accessibility control

With headless, your team owns every line of markup, so it can meet WCAG and prove it with automated checks on every change. With a suite, you depend on the vendor’s components and on your theme. It can be done, and the accessible theme we delivered on Liferay for AXESS is one example, but the theme is where the work goes, and upgrades can change markup under you.

Cost of change

Suite upgrades tend to be projects, licenses renew whether or not you use every feature, and specialist skills are scarce. Headless front ends use the common web stack, which is easier to staff, but you assemble and maintain more pieces yourself: search, forms, preview and analytics.

Hosting and security

A self-hosted suite is a large footprint to patch. A SaaS content platform like Contentful moves that work to the vendor, and your security review moves to its terms, where it keeps your data and how it handles single sign-on. An open-source platform like Payload runs on your own infrastructure with your own database: the most control, and the most to operate.

What moving jfs.ohio.gov taught us

The State of Ohio is moving its websites from HCL Digital Experience to a Contentful-based platform. Our part was the Ohio Department of Job & Family Services: four sites, including jfs.ohio.gov and data.jfs.ohio.gov, taken from research to go-live in 2025–2026. Five lessons carry over to any move.

1. Inventory features, not just pages. The sites had to keep their forms, search and chatbots. Each needed its own plan on the new platform, and none of them was the easy part.
2. Treat the migration as a content project. A content inventory and strategy, a new information architecture and clickable prototypes came before the build.
3. Build for the platform, not the page. The locations map, the slider and a page type for Tableau visualizations were built as Ohio Design System components rather than one-off page code.
4. Test against exit criteria. System testing and user acceptance testing each closed with an exit report before go-live.
5. Train editors before launch. Structured content changes how people author. We trained the department’s team on Contentful and Piwik PRO before go-live, and stayed through a hypercare period after it.

Why this site runs on Payload

For base22.com we chose Payload, an open-source headless CMS built on Next.js. The admin, the API and the public site are one application, the content lives in our own database, and English and Spanish are two locales of the same document rather than two copies that drift apart. Every change to the site runs an automated WCAG 2.2 AA check, and a change that fails it cannot ship.

We traded a vendor’s roadmap for our own operations: we host, patch and back it up ourselves. For a small, bilingual site where accessibility is the point, that trade made sense. For a large authenticated portal with dozens of integrated applications, we might choose differently.

Questions to settle before you choose

• Is most of the experience behind a login, or is it public information?
• How much will you really personalize, and for whom?
• Where will forms, search and chatbots live?
• Who owns accessibility: the vendor’s components or your team’s code?
• Who will run the platform, and who pays for the upgrade five years from now?
• Where must your content and data be hosted?

Answer those honestly and the choice usually makes itself. Many organizations end up with both: a headless public site in front, and a portal behind the login.