Tu equipo de Drupal acaba de renunciar. ¿Y ahora qué?

Tu equipo de Drupal acaba de renunciar y necesitas seguir entregando. El paso de Drupal a headless no es un ejercicio de rebranding — es una decisión estructural sobre cómo tu organización crea, almacena y distribuye contenido durante los próximos cinco años. Hemos acompañado a más de una docena de organizaciones en esta transición exacta, y la respuesta casi nunca es «simplemente cambia la capa de presentación». Depende de cuánto Drupal necesitas conservar realmente.

¿Qué significa realmente «Drupal a headless»?

Existen tres caminos distintos, y confundirlos es el error más costoso que vemos cometer a los product leads.

• Drupal headless híbrido. Conservas Drupal como backend, expones el contenido mediante su módulo JSON:API o GraphQL, y construyes un nuevo frontend en Next.js, Astro o SvelteKit. Los editores mantienen sus flujos de trabajo existentes. Los desarrolladores obtienen una capa de presentación moderna. Drupal sigue necesitando PHP 8.3+, parches de seguridad, actualizaciones de módulos y alojamiento. Acquia, el host empresarial de Drupal más común, aplica un sobrecosto de plataforma que las organizaciones suelen reportar entre un 200 y un 300 por ciento sobre los costos brutos de infraestructura AWS.
• Migración completa de CMS. Extraes cada tipo de contenido, párrafo, referencia de medios y taxonomía de Drupal, y los trasladas a un CMS headless creado específicamente para ello, como Sanity o Contentful. El frontend se reconstruye desde cero. Más trabajo inicial — normalmente de 8 a 14 semanas para un sitio de complejidad media — pero terminas con una pila que un grupo más amplio de desarrolladores JavaScript puede mantener.
• Híbrido progresivo. Ejecutas Drupal en modo tradicional para las páginas que gestionan los editores y entregas contenido headless vía API para los canales que necesitan experiencias personalizadas. Acquia describe esto como «el nuevo headless» y, para organizaciones con grandes equipos editoriales que no pueden asumir una migración total, es un paso intermedio legítimo.

Tenemos una posición clara al respecto: a menos que cuentes con ingenieros de infraestructura PHP dedicados en tu equipo, la opción dos — migración completa — se amortiza en 12 meses gracias a la reducción de costos de alojamiento, parcheo y contratación.

¿Cuánto cuesta una migración de Drupal a headless?

Los precios varían enormemente según el volumen de contenido, la complejidad de las integraciones y la plataforma de destino. Estos son los números reales que manejamos en 2026.

• Sanity parte de $99/mes en planes de pago, con un nivel gratuito funcional para proyectos más pequeños. La configuración es un proyecto de desarrollo en sí mismo debido a la carga de configuración y la curva de aprendizaje de GROQ. Presupuesta entre 60 y 120 horas de ingeniería para el modelado de contenido y la personalización de Studio. Si quieres el panorama completo de cómo se ve esa migración, escribimos un desglose detallado en Tu deadline de actualización de Drupal se convirtió en tu deadline de migración.
• Contentful tiene planes de equipo desde aproximadamente $300/mes, y el precio enterprise requiere una llamada con ventas. La plataforma es madura y está ampliamente desplegada, pero muchos equipos terminan pagando por funcionalidades que nunca usan. El costo a escala es notoriamente elevado.
• Strapi es open-source y gratuito para autoalojar, pero tú asumes el alojamiento, el escalado y el parcheo de seguridad — la misma carga operativa que estás intentando dejar atrás.

Los costos de reconstrucción del frontend dependen de la elección del framework. Next.js es el objetivo más común en nuestros despliegues. Un sitio completo basado en contenido con 20 a 40 tipos de contenido, localización y modo de vista previa suele oscilar entre $30,000 y $80,000 en desarrollo. Si tu equipo está evaluando la economía de los frameworks, lee Tu equipo eligió Nuxt. Tu factura de despliegue acaba de llegar a $4,200. ¿Y ahora qué? antes de comprometerte.

¿Cuándo deberías conservar Drupal como backend?

Drupal representa aproximadamente el 1,1 por ciento del mercado general de CMS, pero supone entre el 6 y el 7 por ciento entre los 10,000 sitios web con mayor tráfico. Esa concentración no es casual. Organismos gubernamentales, sistemas de salud y grandes universidades usan Drupal porque su modelo de permisos y su arquitectura de seguridad están diseñados para entornos donde una brecha tiene consecuencias reales.

Conserva Drupal como backend headless cuando:

• Tienes requisitos estrictos de cumplimiento normativo (FedRAMP, HIPAA, SOC 2) y tu instancia de Drupal ya los satisface
• Tu equipo editorial ha invertido años en los flujos de trabajo de Drupal y la reformación no es viable en tu cronograma
• Cuentas con ingenieros PHP internos que pueden gestionar el mayor nivel de rendimiento de Drupal 11 — PHP 8.3+ con compilación JIT, caché avanzada y gestión de múltiples entornos

Si ninguno de esos puntos aplica, estás manteniendo un sistema complejo por razones históricas. Eso es una elección, no una estrategia. Hemos visto el mismo patrón en equipos con TYPO3 — Tu equipo de TYPO3 acaba de perder otro desarrollador. Esto es lo que Drupal tampoco puede resolver. explica por qué el problema del grupo de desarrolladores es estructural en todas las plataformas CMS PHP heredadas.

¿Cómo se mapean los tipos de contenido de Drupal a un CMS headless?

Esta es la parte que parece sencilla sobre el papel y falla en la práctica. Los tipos de contenido de Drupal se mapean a colecciones en Sanity o tipos de contenido en Contentful. El mapeo en sí es mecánico. La complejidad reside en tres lugares:

1. Paragraphs. El módulo Paragraphs de Drupal crea estructuras de contenido profundamente anidadas y polimórficas. Estas se mapean a contenido basado en bloques en Portable Text de Sanity o rich text estructurado en Contentful, pero la transformación no es uno a uno. Cada tipo de Paragraph necesita su propio gestor de migración.
2. Referencias de entidades y taxonomía. Los campos de referencia de Drupal crean una red de relaciones entre nodos. En un CMS headless, estas se convierten en referencias explícitas entre documentos. Las referencias rotas o faltantes son la causa número uno de errores de contenido tras la migración.
3. Gestión de medios y archivos. La biblioteca de medios de Drupal almacena archivos con metadatos que no se transfieren automáticamente. Escribimos scripts de migración que vuelven a subir los recursos al pipeline de activos del CMS de destino, preservan el texto alternativo y los puntos focales, y actualizan cada referencia de contenido.

Normalmente presupuestamos entre el 30 y el 50 por ciento del total de horas de migración solo en la transformación de contenido. Si estás ejecutando Drupal 7 específicamente, la urgencia es mayor — Tu sitio de Drupal 7 llegó a fin de vida el mes pasado. ¿Y ahora qué? detalla la presión del cronograma.

¿Qué framework de frontend encaja mejor con un CMS headless?

Optamos por Next.js para sitios con mucho contenido y por Astro para sitios de documentación o marketing que se benefician de los valores predeterminados de cero JS. Ambos funcionan bien dentro del patrón de arquitectura Jamstack — prerenderizando el contenido en tiempo de compilación e hidratando los componentes interactivos en el cliente.

La elección del framework importa menos que la arquitectura de despliegue. Un CMS headless con un frontend generado estáticamente en Vercel o Cloudflare Pages ofrece tiempos de respuesta inferiores a 100 ms a nivel global sin las acrobacias de caché que exige Drupal. Dejas de pagar por el ajuste de Varnish y la configuración de CDN porque la arquitectura lo gestiona por defecto.

Para equipos que evalúan Next.js frente al renderizado tradicional de Drupal, comparamos las implicaciones completas de la pila en Tu pila de Drupal acaba de chocar contra su muro de cumplimiento. Aquí está tu salida..

¿Qué ocurre con el SEO durante una migración de Drupal a headless?

Aquí es donde las organizaciones entran en pánico, y el pánico está mayormente justificado si la migración se gestiona con descuido. Drupal incluye renderizado integrado, funcionalidades de accesibilidad y módulos SEO como Pathauto y Metatag. Cuando pasas a un frontend headless, todo eso pasa a ser tu responsabilidad.

Lo que aplicamos en cada migración:

• Mapa de redirecciones completo. Cada alias de ruta de Drupal obtiene una redirección 301 a su nueva URL. Sin excepciones, sin «lo hacemos después».
• Paridad de metadatos. Cada meta título, descripción, URL canónica y etiqueta Open Graph de Drupal se mapea al nuevo esquema del CMS y el frontend los renderiza.
• Datos estructurados. La salida del módulo RDF de Drupal se reemplaza con JSON-LD explícito en el nuevo frontend. Es una oportunidad para mejorar, no solo para conservar.
• Presupuesto de rastreo. Enviamos sitemaps actualizados a Google Search Console en las primeras 24 horas tras el lanzamiento y monitorizamos la indexación diariamente durante las dos primeras semanas.

Bien ejecutado, la mayoría de los sitios ven tráfico orgánico estable o mejorado en los primeros 30 días. Mal ejecutado, pierdes meses de tiempo de recuperación.

El riesgo real no es la migración — es el retraso

Se proyecta que el mercado de CMS headless crecerá desde aproximadamente $3,94 mil millones en 2026 hasta $22,28 mil millones en 2034. Ese crecimiento refleja un cambio estructural en cómo las organizaciones distribuyen contenido a través de la web, el móvil y los canales emergentes de IA. Cada trimestre que pasas parcheando módulos de Drupal en lugar de lanzar funcionalidades es un trimestre que tus competidores pasan construyendo sobre una pila más rápida.

Tu equipo de Drupal renunció porque vio el techo. La pregunta no es si migrar — sino qué tan deliberadamente haces la transición para no cambiar un conjunto de problemas por otro.