¿Suite o headless? Cómo elegir una plataforma para servicios públicos

Las dependencias que reemplazan un sitio web o un portal suelen llegar a la misma bifurcación. Un camino es una suite de plataforma de experiencia digital (DXP), como HCL Digital Experience o Liferay DXP: un solo producto para contenido, armado de páginas, personalización, inicio de sesión y aplicaciones integradas. El otro es headless: una plataforma de contenido como Contentful o Payload guarda contenido estructurado y lo entrega por API a un front end que construye tu equipo, muchas veces con Next.js.

Hemos construido en los dos. La mayoría de los portales que hicimos en la última década corría en HCL Digital Experience. Rediseñamos AXESS, el portal de Stanford University, y lo implementamos con un tema accesible en Liferay DXP. En 2025–2026 migramos los sitios del Ohio Department of Job & Family Services de HCL DX a la plataforma del Estado basada en Contentful, y este sitio funciona con Payload. Ningún camino es mejor en general. Así se ve la decisión cuando se trata de servicios públicos.

Lo que realmente pesa

Edición de contenido

Las suites les dan páginas a los editores: colocar componentes, previsualizar en contexto y pasar los cambios por flujos de aprobación, todo incluido. Headless les da entradas estructuradas, como un servicio, una oficina o una alerta, que pueden aparecer en muchas páginas y canales. Eso rinde cuando el mismo contenido aparece en varios lugares, pero la vista previa, el armado de páginas y los flujos son cosas que tienes que diseñar, no cosas que vienen de fábrica.

Personalización e inicio de sesión

Las suites son más fuertes detrás de un inicio de sesión: páginas por rol, inicio de sesión único, muchas aplicaciones en una sola pantalla. Por eso tantos portales de empleados y de estudiantes corren en ellas. La mayoría de los sitios de información pública personaliza muy poco. Antes de pagar por un motor de personalización, anota qué cambiarías de verdad, y para quién.

Integración

Una suite te da un marco para llevar los sistemas internos al portal. Headless lleva la integración al front end y a tus API: más libertad y más responsabilidad. Los formularios, la búsqueda y los chatbots no vienen con la plataforma de contenido, y cada uno necesita un lugar.

Control de la accesibilidad

Con headless, tu equipo es dueño de cada línea de código de la interfaz, así que puede cumplir WCAG y demostrarlo con revisiones automáticas en cada cambio. Con una suite, dependes de los componentes del proveedor y de tu tema. Se puede lograr, y el tema accesible que entregamos en Liferay para AXESS es un ejemplo, pero es en el tema donde se va el trabajo, y las actualizaciones pueden cambiarte el código sin avisar.

El costo de cambiar

Las actualizaciones de una suite suelen ser proyectos, las licencias se renuevan uses o no todas las funciones, y el talento especializado escasea. Los front ends headless usan las tecnologías web más comunes, así que es más fácil formar equipo, pero tú armas y mantienes más piezas: búsqueda, formularios, vista previa y analítica.

Hospedaje y seguridad

Una suite en tu propia infraestructura es mucho que parchar. Una plataforma SaaS como Contentful le pasa ese trabajo al proveedor, y tu revisión de seguridad se enfoca en sus términos, en dónde guarda tus datos y en cómo maneja el inicio de sesión único. Una plataforma de código abierto como Payload corre en tu infraestructura y con tu base de datos: el mayor control, y lo más que operar.

Lo que aprendimos al migrar jfs.ohio.gov

El Estado de Ohio está migrando sus sitios web de HCL Digital Experience a una plataforma basada en Contentful. Nuestra parte fue el Ohio Department of Job & Family Services: cuatro sitios, entre ellos jfs.ohio.gov y data.jfs.ohio.gov, llevados de la investigación a la salida en vivo en 2025–2026. Estas cinco lecciones sirven para cualquier migración.

1. Haz inventario de funciones, no solo de páginas. Los sitios tenían que conservar sus formularios, su búsqueda y sus chatbots. Cada uno necesitó su propio plan en la nueva plataforma, y ninguno fue lo fácil.
2. Trata la migración como un proyecto de contenido. Un inventario y una estrategia de contenido, una nueva arquitectura de información y prototipos navegables llegaron antes de construir.
3. Construye para la plataforma, no para la página. El mapa de ubicaciones, el carrusel y un tipo de página para visualizaciones de Tableau se hicieron como componentes del Ohio Design System, no como código suelto de una página.
4. Prueba contra criterios de salida. Las pruebas de sistema y las de aceptación de usuarios cerraron cada una con un reporte de salida antes de salir en vivo.
5. Capacita a los editores antes del lanzamiento. El contenido estructurado cambia la forma de editar. Capacitamos al equipo del departamento en Contentful y Piwik PRO antes de salir en vivo, y seguimos con ellos durante un periodo de hypercare.

Por qué este sitio funciona con Payload

Para base22.com elegimos Payload, un CMS headless de código abierto construido sobre Next.js. El panel de administración, la API y el sitio público son una sola aplicación, el contenido vive en nuestra propia base de datos, y el inglés y el español son dos idiomas del mismo documento, no dos copias que se van desfasando. Cada cambio al sitio pasa por una revisión automática de WCAG 2.2 AA, y un cambio que no la pasa no se publica.

Cambiamos el roadmap de un proveedor por nuestra propia operación: nosotros lo hospedamos, lo parchamos y lo respaldamos. Para un sitio pequeño y bilingüe donde la accesibilidad es el punto, el intercambio tenía sentido. Para un portal grande con inicio de sesión y decenas de aplicaciones integradas, quizá elegiríamos distinto.

Preguntas que debes resolver antes de elegir

• ¿La mayor parte de la experiencia está detrás de un inicio de sesión, o es información pública?
• ¿Cuánto vas a personalizar de verdad, y para quién?
• ¿Dónde van a vivir los formularios, la búsqueda y los chatbots?
• ¿Quién es responsable de la accesibilidad: los componentes del proveedor o el código de tu equipo?
• ¿Quién va a operar la plataforma, y quién pagará la actualización dentro de cinco años?
• ¿Dónde deben estar hospedados tu contenido y tus datos?

Si respondes con honestidad, la decisión casi siempre se toma sola. Muchas organizaciones terminan con las dos: un sitio público headless al frente y un portal detrás del inicio de sesión.