Por qué los equipos abandonan TYPO3

Seré claro: TYPO3 no es mal software. Es maduro, bien mantenido y cuenta con una comunidad dedicada, especialmente en Alemania, Austria y Suiza. Pero tiene ciertas restricciones arquitectónicas que se vuelven dolorosas a escala.

Fricción en la experiencia del desarrollador

El sistema de plantillas de TYPO3 (Fluid) es potente pero de nicho. Encontrar desarrolladores que conozcan Fluid, TypoScript y el framework de extensiones Extbase/TYPO3 es cada vez más difícil. La curva de aprendizaje es pronunciada, y los desarrolladores más jóvenes prefieren abrumadoramente trabajar con frameworks de JavaScript. He visto cómo los plazos de contratación se duplican porque los equipos no podían encontrar desarrolladores con dominio de TYPO3.

Limitaciones de rendimiento

TYPO3 renderiza páginas en el servidor mediante PHP. Aunque el caché ayuda, estás fundamentalmente limitado por el ciclo de solicitud monolítico. La generación de sitios estáticos y el renderizado en el edge —lo que los frameworks modernos hacen bien— no son nativos en la arquitectura de TYPO3. Existe la extensión TYPO3 Headless (EXT:headless) que convierte TYPO3 en una API, pero en ese punto estás manteniendo un backend PHP que hace cada vez menos del trabajo real.

Dificultades para reutilizar contenido

El modelo de contenido de TYPO3 está centrado en páginas. Los elementos de contenido viven en páginas. Si necesitas distribuir contenido a una aplicación móvil, un quiosco digital, un sistema de correo electrónico y un sitio web simultáneamente, el modelo de TYPO3 te pone trabas a cada paso. Las plataformas CMS headless tratan el contenido como datos estructurados desde el principio, lo que hace que la distribución multicanal sea natural en lugar de algo añadido a posteriori.

Coste total de propiedad

Ejecutar TYPO3 implica mantener servidores PHP, gestionar las actualizaciones del núcleo de TYPO3 (que pueden ser complejas entre versiones principales) y mantener la compatibilidad de las extensiones. Un CMS headless SaaS elimina la mayor parte de la sobrecarga de infraestructura. Incluso las opciones headless autoalojadas como Strapi o Directus suelen requerir menos esfuerzo operativo.

Cuándo tiene sentido realmente la migración

No todos los sitios TYPO3 necesitan volverse headless. Esta es mi evaluación honesta:

Escenario ¿Migrar? Por qué
Sitio de presentación simple, 50 páginas, un idioma Probablemente no Innecesario. TYPO3 funciona bien aquí.
Sitio empresarial multiidioma con apps móviles Sí Headless brilla en la distribución omnicanal
E-commerce con datos de producto complejos Sí Mayor flexibilidad frontend, integraciones API-first
Sitio con extensiones TYPO3 intensivas (noticias, eventos, formularios) Quizás Audita primero las dependencias de extensiones
Portal interno con flujos de trabajo en el backend de TYPO3 Con cuidado Puedes perder funciones de flujo de trabajo difíciles de reemplazar
El equipo no puede contratar desarrolladores TYPO3 Sí La sostenibilidad importa más que las características

La migración tiene más sentido cuando ya estás planeando un rediseño o una actualización de plataforma. Migrar puramente por razones técnicas —sin un detonante de negocio— a menudo tiene dificultades para obtener aprobación presupuestaria.

Elegir tu CMS headless

Aquí es donde los equipos se atascan. Hay docenas de opciones de CMS headless, y la elección correcta depende en gran medida de tu situación específica.

Opciones de nivel empresarial

Contentful sigue siendo el líder del mercado en CMS headless empresarial. El precio comienza en torno a $300/mes para el plan Team y escala hasta precios empresariales personalizados (típicamente $2,000–$10,000+/mes según el uso). Es maduro, bien documentado y tiene excelentes SDKs. El modelado de contenido es flexible, y la función Compose gestiona los casos de uso de construcción de páginas a los que están acostumbrados los editores de TYPO3.

Sanity es mi favorito personal por la experiencia del desarrollador. El modelo de precios es generoso —el nivel gratuito cubre muchos proyectos pequeños, y el plan Team a $15/usuario/mes es razonable. Sanity Studio es completamente personalizable con React, por lo que puedes crear experiencias editoriales que igualen o superen lo que ofrece el backend de TYPO3. El lenguaje de consulta GROQ requiere algo de adaptación, pero es increíblemente potente una vez que te acostumbras.

Storyblok merece especial atención para las migraciones desde TYPO3 porque ofrece un editor visual que resulta familiar a los usuarios del backend de TYPO3. El precio comienza en €99/mes para el plan Entry. Es especialmente popular en la región DACH, que se superpone considerablemente con la base de usuarios de TYPO3.

Alternativas de código abierto

Strapi (v5 lanzada en 2024) es la opción de código abierto líder. Puedes autoalojarlo o usar Strapi Cloud (a partir de $29/mes por usuario). Está basado en Node.js, utiliza una base de datos PostgreSQL o MySQL, y ofrece un ecosistema de plugins en rápido crecimiento.

Directus envuelve cualquier base de datos SQL con una API y un panel de administración. Es una excelente opción si quieres mantener tu estructura de base de datos existente y migrar gradualmente. La versión de código abierto tiene todas las funciones; la versión en la nube comienza en $99/mes.

Tabla comparativa: opciones de CMS headless para migración desde TYPO3

Característica Contentful Sanity Storyblok Strapi Directus
Modelo de alojamiento SaaS SaaS + Autoalojado SaaS Autoalojado + Cloud Autoalojado + Cloud
Editor visual Compose (complemento) Personalizable Integrado Plugin Limitado
Multiidioma Excelente Bueno Excelente Bueno Bueno
Precio inicial $300/mes Nivel gratuito €99/mes Gratis (OSS) Gratis (OSS)
Familiaridad para editores de TYPO3 Media Baja Alta Media Media
Modelado de contenido Flexible Muy flexible Basado en componentes Flexible Basado en base de datos
Webhooks/Flujos de trabajo Sí Sí Sí Sí Sí

Trabajamos con la mayoría de estas plataformas a través de nuestros servicios de desarrollo de CMS headless. La elección a menudo se reduce a si tus editores necesitan una experiencia de edición visual (Storyblok, Contentful Compose) o si la flexibilidad del desarrollador es la prioridad (Sanity, Strapi).

TYPO3 to Headless CMS Migration: A Practical Developer Guide - architecture

Modelado de contenido: la parte difícil

Aquí es donde la mayoría de las migraciones se tuercen. El modelo de contenido de TYPO3 es fundamentalmente diferente al de los CMS headless, y no puedes simplemente mapear uno con el otro.

Entender la estructura de contenido de TYPO3

En TYPO3, el contenido se organiza como:

  • Páginas (el árbol de páginas) con propiedades y metadatos
  • Elementos de contenido (tt_content) posicionados en columnas dentro de las páginas
  • Extensiones que añaden tipos de registros personalizados (noticias, eventos, etc.)
  • Categorías y referencias de archivos vinculadas a través de la tabla sys_file_reference
  • Configuración TypoScript que afecta al renderizado y al flujo de datos

Este es un modelo centrado en páginas. El contenido existe en el contexto de una página.

Modelado de contenido headless

Las plataformas CMS headless utilizan un modelo centrado en el contenido. Defines tipos de contenido (como Artículo, Autor, Producto) con campos, y luego compones páginas a partir de referencias a esos elementos de contenido. La propia página es a menudo solo otro tipo de contenido.

El trabajo de traducción se parece a algo así:

Árbol de páginas TYPO3        →  Tipo de contenido Page con campos slug/jerarquía
tt_content (text)             →  Componente/bloque de texto enriquecido
tt_content (image)            →  Componente multimedia con referencias de activos
tx_news_domain_model_news     →  Tipo de contenido Article/News
Categorías (sys_category)     →  Tipo de contenido Tags/Categorías
Referencias de archivos       →  Gestión de activos (DAM)

Consejos prácticos

No intentes replicar el modelo de contenido de TYPO3 en tu CMS headless. Esta es una oportunidad para repensar y mejorar tu arquitectura de contenido. Comienza por auditar:

  1. ¿Qué tipos de contenido existen? Exporta los CTypes de tt_content y lista todos los tipos de registros de extensiones.
  2. ¿Qué campos se usan realmente? Las tablas de TYPO3 tienen docenas de campos. La mayoría del contenido solo usa unos pocos.
  3. ¿Cuáles son las relaciones? Mapea cómo el contenido hace referencia a otro contenido.
  4. ¿Cuál es la configuración de traducción? TYPO3 admite modos de traducción conectado y libre —tu CMS headless necesita gestionar el que uses.
-- Consultas de auditoría útiles en TYPO3
-- Contar elementos de contenido por tipo
SELECT CType, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 AND hidden = 0 
GROUP BY CType 
ORDER BY count DESC;

-- Contar páginas por doktype
SELECT doktype, COUNT(*) as count 
FROM pages 
WHERE deleted = 0 AND hidden = 0 
GROUP BY doktype 
ORDER BY count DESC;

-- Encontrar todos los idiomas en uso
SELECT sys_language_uid, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 
GROUP BY sys_language_uid;

Estrategias de migración de datos

Una vez definido tu modelo de contenido en el CMS de destino, necesitas mover los datos realmente. Existen tres enfoques principales.

Enfoque 1: exportación/importación basada en scripts

Escribe scripts que consulten directamente la base de datos de TYPO3, transformen los datos y los envíen al CMS headless a través de su API de gestión. Este es el enfoque más común y te da el mayor control.

// Ejemplo: Migrar registros de noticias de TYPO3 a Contentful
const contentful = require('contentful-management');
const mysql = require('mysql2/promise');

async function migrateNews() {
  const db = await mysql.createConnection({
    host: 'localhost',
    database: 'typo3_db',
    user: 'root',
    password: 'password'
  });

  const client = contentful.createClient({
    accessToken: 'your-management-token'
  });

  const space = await client.getSpace('your-space-id');
  const env = await space.getEnvironment('master');

  const [rows] = await db.execute(`
    SELECT n.uid, n.title, n.teaser, n.bodytext, n.datetime,
           n.path_segment, p.slug as category_slug
    FROM tx_news_domain_model_news n
    LEFT JOIN sys_category_record_mm mm ON mm.uid_foreign = n.uid
    LEFT JOIN sys_category c ON c.uid = mm.uid_local
    WHERE n.deleted = 0 AND n.hidden = 0
  `);

  for (const row of rows) {
    const entry = await env.createEntry('article', {
      fields: {
        title: { 'en-US': row.title },
        teaser: { 'en-US': row.teaser },
        body: { 'en-US': convertRteToRichText(row.bodytext) },
        publishDate: { 'en-US': new Date(row.datetime * 1000).toISOString() },
        slug: { 'en-US': row.path_segment }
      }
    });
    await entry.publish();
    console.log(`Migrado: ${row.title}`);
  }
}

La función convertRteToRichText es donde las cosas se complican. La salida RTE de TYPO3 es HTML (a menudo con etiquetas personalizadas como <link> para enlaces internos). Convertir esto a formatos de texto enriquecido estructurado varía según el CMS —Contentful usa su propio JSON de texto enriquecido, Sanity usa Portable Text, etc.

Enfoque 2: extensión TYPO3 Headless como puente

Instala la extensión EXT:headless en tu instancia TYPO3 existente. Esto convierte TYPO3 en una API JSON, que luego puedes consumir desde scripts de migración o incluso usar temporalmente como backend headless mientras construyes el nuevo frontend.

Este enfoque tiene una ventaja interesante: puedes ejecutar el nuevo frontend contra la API headless de TYPO3 primero, y luego cambiar el backend a un CMS headless adecuado más tarde. Divide la migración en dos fases.

Enfoque 3: recreación manual

Para sitios más pequeños (menos de 100 páginas), a veces es más rápido simplemente recrear el contenido manualmente en el nuevo CMS. Especialmente si también estás reestructurando y reescribiendo contenido —lo cual probablemente deberías hacer.

Decisiones de arquitectura frontend

Con un CMS headless, necesitas un frontend separado. Aquí es donde se producen las verdaderas ganancias de rendimiento.

Next.js

La opción más popular. Renderizado en el servidor, generación estática, regeneración estática incremental —Next.js gestiona todas las estrategias de renderizado que puedas necesitar. El App Router (estable desde Next.js 13.4) con React Server Components es especialmente adecuado para sitios con mucho contenido. Hacemos mucho de este trabajo a través de nuestra práctica de desarrollo Next.js.

Astro

Para sitios con mucho contenido que no necesitan mucha interactividad, Astro es fenomenal. No envía JavaScript por defecto y admite hidratación parcial a través de su Islands Architecture. Hemos visto puntuaciones de Lighthouse que alcanzan consistentemente 95+ con builds de Astro, lo cual es una mejora drástica sobre el rendimiento frontend típico de TYPO3. Consulta nuestros servicios de desarrollo Astro si esto te interesa.

Nuxt

Si tu equipo prefiere Vue sobre React, Nuxt 3 es el equivalente de Next.js. Una elección sólida, gran DX, buen ecosistema.

Framework Mejor para JS enviado Curva de aprendizaje Integraciones con CMS
Next.js Apps dinámicas, e-commerce, dashboards Medio-Alto Media Excelente
Astro Sitios de contenido, blogs, marketing Mínimo Baja Excelente
Nuxt 3 Equipos Vue, contenido + apps Medio Media Buena
SvelteKit Equipos pequeños que buscan simplicidad Bajo Baja-Media Creciente

Gestionar características específicas de TYPO3

Algunas características de TYPO3 no tienen equivalentes directos en el mundo headless. Aquí te explicamos cómo gestionar las más comunes.

Espacios de trabajo y versionado

El sistema de espacios de trabajo de TYPO3 permite a los editores preparar cambios en múltiples páginas antes de publicarlos. La mayoría de las plataformas CMS headless ofrecen entornos o programación de publicaciones que replican parcialmente esto. Contentful tiene Environments y Scheduled Publishing. Sanity tiene Releases (lanzado recientemente). Ninguno es tan sofisticado como los Workspaces de TYPO3 de forma nativa, así que si tus editores dependen mucho de los espacios de trabajo, planifica ajustes en el flujo de trabajo.

Permisos de usuarios del backend

El sistema de permisos de TYPO3 es extremadamente granular: controles de acceso a nivel de página, elemento de contenido y campo. Las plataformas CMS headless varían mucho en este aspecto. El sistema de roles de Contentful es decente pero menos granular. El de Sanity es más flexible pero requiere configuración personalizada. El acceso basado en roles de Strapi es bueno. Audita tu matriz de permisos actual y valida que el CMS de destino pueda gestionarla antes de comprometerte.

Gestión de formularios

El Framework de Formularios de TYPO3 (EXT:form) genera formularios a partir de configuración YAML. En una configuración headless, necesitarás un servicio de formularios. Las opciones incluyen Formspree, Basin, o construir el tuyo propio con funciones serverless. Si usas Next.js, las Server Actions hacen que la gestión de formularios sea sencilla.

Multiidioma y localización

Esto es crítico y a menudo subestimado. La gestión de traducciones de TYPO3 —con su concepto de superposiciones de idioma, modo conectado/libre y cadenas de reserva— es sofisticada. Mapea tus requisitos exactos de traducción antes de elegir un CMS. Storyblok y Contentful gestionan bien la administración de locales. Sanity requiere una configuración más personalizada para escenarios multiidioma complejos.

Preservar el SEO durante la migración

Esta sección podría ser la más importante. Una migración mal ejecutada puede desplomar tu tráfico orgánico.

Mapeo de URLs

Exporta cada URL de tu sitio TYPO3. Cada. Una. De. Ellas. Usa un rastreador como Screaming Frog o wget --spider para construir una lista completa de URLs. Luego crea un mapa de redirecciones:

/ruta-antigua-typo3/pagina.html → /nueva-ruta-limpia
/index.php?id=42 → /sobre-nosotros
/fileadmin/documentos/informe.pdf → /assets/informe.pdf

Implementa redirecciones 301 para cada URL que cambie. En Next.js, esto va en next.config.js:

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/ruta-antigua/:slug*',
        destination: '/nueva-ruta/:slug*',
        permanent: true,
      },
      // ... cientos más, cargados desde un archivo JSON idealmente
    ];
  },
};

Para listas de redirecciones grandes (500+), considera gestionar las redirecciones en el edge (Vercel Edge Middleware, Cloudflare Workers o nginx) en lugar de en la configuración de tu aplicación.

Migración de metadatos

TYPO3 almacena metadatos SEO en la tabla pages (seo_title, description, og_image, etc.) y potencialmente en extensiones como EXT:cs_seo o EXT:seo_basics. Extrae todo esto y migralo al modelo de contenido de tu CMS headless. No olvides:

  • Títulos de página y meta descripciones
  • Datos de Open Graph y Twitter Card
  • URLs canónicas
  • Etiquetas hreflang para sitios multilingües
  • Datos estructurados / esquemas JSON-LD
  • Generación de sitemaps XML

Monitorización

Configura Google Search Console para el nuevo dominio/subdominio antes de la migración. Después del lanzamiento, monitoriza el informe de Cobertura diariamente durante las primeras dos semanas. Observa los errores de rastreo, las páginas eliminadas y los problemas de indexación. Ten un plan de retroceso.

Estrategia de pruebas y lanzamiento

Recomiendo un enfoque por fases en lugar de un cambio completo de golpe.

Fase 1: ejecución en paralelo (2-4 semanas)

Ejecuta el nuevo sitio headless en un dominio de staging. Compara la paridad de contenido con el sitio TYPO3. Haz que los editores prueben los flujos de trabajo de contenido. Ejecuta pruebas automatizadas de regresión visual con herramientas como Percy o Playwright.

Fase 2: lanzamiento suave

Dirige un pequeño porcentaje del tráfico al nuevo sitio usando feature flags o pruebas A/B a nivel de CDN. Monitoriza Core Web Vitals, tasas de error y comportamiento del usuario.

Fase 3: cambio completo

Cambia la configuración de DNS o del proxy inverso. Activa todas las redirecciones. Monitoriza intensamente durante 48 horas. Mantén la instancia de TYPO3 en funcionamiento (solo lectura) durante al menos 30 días como referencia.

Fase 4: desmantelamiento

Una vez que estés seguro de que la migración es estable, apaga la infraestructura de TYPO3. Archiva la base de datos y el directorio fileadmin. Te lo agradecerás más tarde cuando alguien pregunte sobre contenido antiguo.

Cronograma y costes reales de la migración

Seamos honestos sobre lo que cuesta esto. He visto a demasiados equipos subestimar los proyectos de migración.

Tamaño del proyecto Páginas Cronograma Coste estimado
Pequeño 50-200 6-10 semanas $15,000-$35,000
Mediano 200-1,000 12-20 semanas $40,000-$90,000
Grande 1,000-5,000 20-36 semanas $80,000-$200,000
Empresarial 5,000+ 6-12 meses $150,000-$500,000+

Estas cifras incluyen el modelado de contenido, los scripts de migración, el desarrollo frontend, las pruebas y el soporte de lanzamiento. No incluyen los costes de licencia del CMS, que varían según la plataforma.

Los principales factores que incrementan el coste son:

  1. Número de tipos de contenido y complejidad —no el recuento bruto de páginas
  2. Extensiones personalizadas de TYPO3 que necesitan funcionalidad equivalente construida
  3. Complejidad de la configuración multiidioma
  4. Requisitos de integración (búsqueda, e-commerce, autenticación)
  5. Formación editorial y gestión del cambio

Si quieres hablar sobre cómo podría ser una migración para tu configuración específica, contáctanos o consulta nuestra página de precios para conocer los modelos de colaboración.

FAQ

¿Puedo usar TYPO3 como CMS headless en lugar de migrar a uno nuevo?

Sí, la extensión EXT:headless (anteriormente "headless") convierte TYPO3 en una API JSON. Esto puede ser un buen paso intermedio. Sin embargo, sigues manteniendo un backend TYPO3 con toda su sobrecarga operativa. Tiene sentido como estrategia puente, pero generalmente no es la respuesta a largo plazo si tu objetivo es reducir la dependencia de TYPO3.

¿Cuánto tiempo tarda una migración típica de TYPO3 a CMS headless?

Para un sitio de tamaño mediano (200-1,000 páginas), espera entre 3 y 5 meses desde el inicio hasta el lanzamiento. Las fases de modelado de contenido y escritura de scripts de migración suelen llevar más tiempo del que los equipos anticipan. El desarrollo frontend a menudo puede ejecutarse en paralelo una vez definido el modelo de contenido. Las migraciones empresariales con múltiples idiomas e integraciones complejas pueden llevar entre 6 y 12 meses.

¿Perderé posiciones SEO durante la migración?

No deberías si lo haces correctamente. Los factores críticos son: implementar redirecciones 301 adecuadas para todas las URLs modificadas, migrar todos los metadatos, mantener la estructura de tu sitio y los enlaces internos, y enviar sitemaps actualizados a Google. Una caída temporal en las posiciones durante 2-4 semanas después de la migración es normal y suele recuperarse. Las pérdidas permanentes suelen indicar redirecciones omitidas o contenido perdido.

¿Qué CMS headless es mejor para reemplazar TYPO3?

Depende de tus prioridades. Storyblok suele ser la transición más fluida para los editores de TYPO3 debido a sus capacidades de edición visual. Contentful es la opción empresarial más segura con el ecosistema más maduro. Sanity ofrece la mayor flexibilidad para el desarrollador. Strapi es la mejor opción si necesitas código abierto y autoalojamiento. No hay una respuesta única —depende de tu equipo, presupuesto y requisitos.

¿Qué ocurre con mis extensiones de TYPO3 después de la migración?

Cada extensión debe evaluarse individualmente. Las extensiones comunes como EXT:news, EXT:cal y EXT:powermail necesitan funcionalidad equivalente en tu nueva pila. La funcionalidad de noticias/blog es sencilla de replicar con cualquier CMS headless. Las características de calendario y eventos pueden necesitar servicios de terceros. Los formularios requieren una nueva solución (constructores de formularios, funciones serverless o servicios como Formspree). Las extensiones personalizadas necesitan el análisis más exhaustivo.

¿Cómo gestiono los activos de fileadmin de TYPO3 durante la migración?

Necesitarás migrar todos los activos (imágenes, PDFs, vídeos) al sistema de gestión de activos de tu nuevo CMS o a un DAM/CDN separado. Escribe un script que descargue desde fileadmin, suba a la nueva plataforma a través de su API y mapee las referencias de archivos antiguas a los nuevos IDs de activos. No olvides gestionar las imágenes procesadas/redimensionadas —la mayoría de las plataformas CMS headless gestionan la transformación de imágenes automáticamente, por lo que normalmente solo necesitas migrar los originales.

¿Puedo migrar de forma incremental o tiene que ser todo a la vez?

La migración incremental es posible y a veces aconsejable para sitios grandes. Puedes usar un proxy inverso para dirigir ciertas rutas de URL al nuevo frontend headless mientras mantienes otras en TYPO3. Esto te permite migrar sección por sección. La contrapartida es una mayor complejidad al gestionar dos sistemas simultáneamente y mantener una navegación y diseño coherentes en ambos.

¿Qué debo hacer con los usuarios del backend de TYPO3 que son reacios al cambio?

La gestión del cambio es genuinamente la mitad de la batalla. Empieza por involucrar a los editores desde el principio —muéstrales el nuevo CMS durante la fase de modelado de contenido, no después de que todo esté construido. Elige un CMS con una buena experiencia de edición (Storyblok y Contentful suelen obtener la mejor valoración de los editores). Crea documentación y materiales de formación específicos para tu configuración. Y sé honesto sobre qué cambia y por qué —los editores suelen adaptarse cuando ven la experiencia de previsualización mejorada y los flujos de publicación más rápidos.

Conclusión clave:

El CMS headless separa el contenido del renderizado, lo que permite una distribución verdaderamente multicanal.