Migración de TYPO3 a Drupal: Tu Contenido, Usuarios y URLs Intactos
Tu servidor de staging termina la reconstrucción del caché de TYPO3 — cuarenta y tres segundos para un cambio de contenido que debería tomar dos. Tu desarrollador frontend refresca el navegador, ve la actualización, y murmura algo sobre TypoScript que probablemente no deberías repetir en standup. Esta escena se reproduce diariamente en empresas de toda Europa, donde TYPO3 ha alimentado portales gubernamentales y sitios corporativos durante dos décadas. El CMS sigue funcionando, técnicamente. Pero la arquitectura basada en componentes de Drupal, su kit de herramientas headless, y una base de colaboradores diez veces más grande hacen que la conversación sobre migración sea inevitable. La pregunta no es si cambiar — es cómo mover 8,000 páginas, preservar veinte años de equidad de URL, y mantener cuerda a tu editorial durante la transición. Hemos ejecutado este plan seis veces en los últimos dieciocho meses, y la diferencia entre una migración limpia y un desastre se reduce a cuatro decisiones que tomarás en la primera semana.
He estado inmerso en algunos proyectos de migración de TYPO3 a Drupal durante los últimos años, y ha sido toda una aventura desenredar modelos de contenido del mundo real. Suelen ser un lío enredado. Esta guía es lo que hubiera deseado que alguien me entregara antes de mi primera migración. Cubriremos todos los detalles técnicos importantes, los obligatorios de planificación, y esos molestos escollos que pueden torpedear tu cronograma si no estás atento.
Tabla de Contenidos
- Por qué las Organizaciones Abandonan TYPO3
- TYPO3 vs Drupal: Una Comparación Honesta
- Auditoría y Planificación Previa a la Migración
- Modelado de Contenido: Mapeando TYPO3 a Drupal
- Herramientas de Migración y Enfoque Técnico
- Manejando TypoScript y Extensiones de TYPO3
- Estructura de URL y Preservación SEO
- Volviéndose Headless Después de la Migración
- Estimaciones de Cronograma, Costo y Personal
- Lista de Verificación Post-Migración
- Preguntas Frecuentes

Por qué las Organizaciones Abandonan TYPO3
Seamos francos: TYPO3 no es un CMS malo. Es tremendamente flexible, maneja configuraciones multi-sitio y multilingües de forma nativa, contando con una base de aficionados dedicada especialmente en la región DACH. Entonces, ¿por qué la gente salta el barco?
Escucho casi siempamente las mismas razones:
Disponibilidad de desarrolladores. Fuera de Europa Central, encontrar desarrolladores de TYPO3 es tan difícil como encontrar una aguja en un pajar. Drupal, por otro lado, cuenta con aproximadamente 1.3 millones de desarrolladores en todo el mundo, según el informe de comunidad 2024 de Drupal.org. ¿TYPO3? No tanto. Si tus desarrolladores senior de TYPO3 deciden empacar y marcharse, llenar esos puestos podría tomar una eternidad.
Impulso del ecosistema. Con el lanzamiento de Drupal 11 a finales de 2024, hubo avances enormes en la UI de administración, un nuevo sistema de recetas y capacidades API-first de clase mundial. Claro, TYPO3 v13 es sólido, pero la tasa de innovación en Drupal, particularmente alrededor de configuraciones headless, es notablemente más rápida.
Arquitectura headless/desacoplada. ¿Planeas servir contenido a un frontend Next.js o Astro elegante? Los complementos JSON:API y GraphQL de Drupal son profesionales experimentados. TYPO3 tiene su propia extensión headless, pero es menos madura con respaldo más pequeño.
Costo total de propiedad. Alojar TYPO3 generalmente golpea la billetera con más fuerza. Su infraestructura especializada significa que podrías terminar gastando más. Drupal se comporta contenidamente en prácticamente cualquier lugar desde Pantheon hasta Acquia, incluso un simple stack LAMP lo mantiene funcionando.
TYPO3 vs Drupal: Una Comparación Honesta
Antes de lanzarte de cabeza a un cambio, asegúrate de que Drupal realmente va a resolver tus puntos de dolor. Aquí está el resumen al 2026:
| Característica | TYPO3 v13 | Drupal 11 |
|---|---|---|
| Modelado de Contenido | Flexible pero se inclina hacia TCA | Sistema Entity/Field con UI de gestión de campos |
| Multilingüe | Soporte nativo estelar | Soporte nativo igualmente estelar |
| Multi-sitio | Multi-sitio estándar con árboles de contenido | Posible, a menudo mejor con Domain Access o instalaciones separadas |
| Headless/API | Tiene una extensión headless | JSON:API core, GraphQL contrib |
| Plantillas | Características plantillas Fluid + TypoScript | Se ejecuta en plantillas Twig |
| Ecosistema de Extensión/Módulo | ~1,800 extensiones en TER | ~50,000+ módulos en Drupal.org |
| UI de Administración | Fuerte, pero fechada (recibiendo un lavado de cara en v13) | Elegante y moderna en Drupal 11 |
| Comunidad de Desarrolladores | ~500 colaboradores activos | 8,000+ colaboradores activos |
| Opciones de Hosting | Auto-alojado o especializado | Auto-alojado, Pantheon, Acquia, Platform.sh, Lagoon |
| Requisito de PHP | PHP 8.2+ | PHP 8.3+ |
| Tarifa de Agencia Típica | €100-180/hr (región DACH) | $80-200/hr (global) |
El modelo de árbol de páginas de TYPO3 es una joya rara. Los editores enganchados en administrar jerarquías complejas de páginas en TYPO3 podrían encontrar el estilo de Drupal — la combinación de tipos de contenido y taxonomía — requiere un poco de ajuste. Programa algo de capacitación para editores para facilitar esa transición.
Auditoría y Planificación Previa a la Migración
Esta etapa determina el destino de la mayoría de migraciones. Todo está en la planificación, no en los tiempos técnicos.
Inventario de Contenido
Comienza auditando todo en tu configuración de TYPO3:
- Páginas: Extrae ese árbol de páginas, documentando cada
doktype(tipo de página) que tengas en juego. - Elementos de contenido: Cada
CType(tipo de contenido) necesita atención — sea texto, texto con imagen, HTML, o cosas personalizadas víamaskocontent_defender. - Extensiones: Anota cada extensión que tengas. Descubre si hay un equivalente en Drupal.
- Referencias de archivo: El FAL de TYPO3 (File Abstraction Layer) lidia con medios. Mapea estos a los espacios de medios de Drupal.
- Usuarios de backend y permisos: Los intrincados grupos de usuarios de backend de TYPO3 con acceso a nivel de página y campo deben traducirse cuidadosamente a roles y permisos de Drupal.
Aquí hay una consulta SQL útil para un resumen de elemento de contenido desde tu base de datos TYPO3:
SELECT CType, COUNT(*) as count
FROM tt_content
WHERE deleted = 0 AND hidden = 0
GROUP BY CType
ORDER BY count DESC;
Con esto, obtienes un vistazo rápido de los tipos de contenido con los que estás enredado. En un caso, descubrí una instancia de TYPO3 que contaba con más de 40 tipos de elemento de contenido personalizados, donde solo una docena estaba activamente en uso. No arrastres peso muerto encima.
Qué Mantener, Qué Eliminar
Aquí es tu oportunidad de limpiar. Usa una herramienta de auditoría de contenido como Screaming Frog o Sitebulb para hurgar en:
- Páginas sin tráfico en el año pasado
- Contenido duplicado o casi idéntico
- Enlaces internos rotos
- Archivos de medios huérfanos
Típicamente, hay un corte de contenido del 30-50% en grandes migraciones de TYPO3. Menos páginas significan migraciones más rápidas.

Modelado de Contenido: Mapeando TYPO3 a Drupal
Sube tus mangas. Este es el levantamiento intelectual pesado. TYPO3 y Drupal manejan el contenido de formas muy diferentes.
Modelo de TYPO3
TYPO3 gira en torno a páginas. Todo está guardado en un árbol de páginas. Los elementos de contenido (registros en tt_content) se colocan en páginas en columnas (colPos). Los registros personalizados definidos a través de modelos Extbase o TCA se sientan en tablas separadas pero generalmente están vinculados desde páginas.
Modelo de Drupal
Drupal trata todo como entidades. Creas tipos de contenido (bundles de nodo), cada uno con campos dedicados. Las páginas son solo una entre muchos tipos de contenido. Taxonomía, párrafos (usando el módulo Paragraphs), y Layout Builder dominan la composición de contenido estructurado.
El Mapeo
Aquí hay una tabla de mapeo típica que uso como mi brújula:
| Concepto de TYPO3 | Equivalente de Drupal |
|---|---|
| Page (doktype: standard) | Node (content type: Page) |
| Page (doktype: shortcut) | URL redirect |
| Page (doktype: link) | Node con campo de enlace o redirect |
| Content element (CType: text) | Tipo de párrafo o campo Body |
| Content element (CType: image) | Referencia de entidad de medios |
| Content element (CType: textpic) | Tipo de párrafo con texto + medios |
| Content element (CType: gridelements) | Sección de Layout Builder |
| Referencia de archivo FAL | Entidad de medios |
| sys_category | Término de taxonomía |
| fe_users | Entidad de usuario de Drupal |
| be_users | Entidad de usuario de Drupal con rol de admin |
| Plantilla de TypoScript | Plantilla de Twig |
| Plugin de Extbase | Módulo personalizado de Drupal |
| Elementos de contenido Mask/DCE | Tipos de párrafo |
¿El cambio más grande? Mover elementos de contenido a Paragraphs. TYPO3 apila elementos de contenido en columnas de página, que se mapean bien al módulo Paragraphs de Drupal. Los editores apilan páginas desde tipos de párrafo reutilizables — es sorprendentemente fluido.
Herramientas de Migración y Enfoque Técnico
El API de Migración de Drupal es excelente. Pero aviso, carece de un complemento de fuente nativo de TYPO3. Tendrás que crear algunos complementos de fuente personalizados para extraer de la base de datos de TYPO3.
Enfoque 1: Migración Directa de Base de Datos
Conecta el API de Migración de Drupal directamente a tu base de datos MySQL/MariaDB de TYPO3:
// Ejemplo de complemento de fuente de migración para páginas de TYPO3
namespace Drupal\typo3_migrate\Plugin\migrate\source;
use Drupal\migrate\Plugin\migrate\source\SqlBase;
use Drupal\migrate\Row;
/**
* @MigrateSource(id = "typo3_pages")
*/
class Typo3Pages extends SqlBase {
public function query() {
return $this->select('pages', 'p')
->fields('p', ['uid', 'title', 'slug', 'abstract', 'doktype', 'crdate', 'tstamp'])
->condition('p.deleted', 0)
->condition('p.hidden', 0)
->condition('p.doktype', [1, 4], 'IN');
}
public function fields() {
return [
'uid' => $this->t('Page ID'),
'title' => $this->t('Page title'),
'slug' => $this->t('URL slug'),
'abstract' => $this->t('Abstract/summary'),
];
}
public function getIds() {
return ['uid' => ['type' => 'integer']];
}
public function prepareRow(Row $row) {
// Load associated content elements
$pid = $row->getSourceProperty('uid');
$content = $this->select('tt_content', 'tt')
->fields('tt')
->condition('tt.pid', $pid)
->condition('tt.deleted', 0)
->orderBy('tt.sorting')
->execute()
->fetchAll();
$row->setSourceProperty('content_elements', $content);
return parent::prepareRow($row);
}
}
Me gusta este enfoque. Se trata de tener control total y te deja manejar las peculiaridades de TYPO3 (como eliminaciones suaves y overlays de espacio de trabajo) en tu base de código.
Enfoque 2: Exportar/Importar vía JSON o XML
Algunos equipos eligen exportar contenido de TYPO3 a formatos estructurados (digamos, a través de extensiones TYPO3 personalizadas o comandos CLI) e importarlos luego a Drupal. Claro, agrega otra capa pero resulta útil si te preocupa mantener conexiones directas a bases de datos durante la migración.
Enfoque 3: Híbrido con Revisión Manual
¿Tienes un sitio más pequeño (menos de 500 páginas)? Hacer una migración de datos estructurados automáticamente mientras creas páginas de destino clave a mano puede funcionar como un encanto. Podría parecer rudimentario, pero cuando el contenido está entrelazado con la lógica de renderizado específica de TYPO3, la migración automatizada a menudo resulta en tonterías.
Manejando TypoScript y Extensiones de TYPO3
TypoScript
Vamos al grano: TypoScript no se migra. Es un lenguaje de configuración específico de TYPO3, sin un homólogo real en otro lugar. Tu trabajo es documentar lo que cada plantilla de TypoScript hace en términos llanos y luego reconstruirlo como plantillas Twig y configuración de Drupal. Es agotador pero necesario.
Extensiones
Aquí hay una comparación útil de extensiones TYPO3 comunes y sus contrapartes de Drupal:
| Extensión de TYPO3 | Equivalente de Drupal |
|---|---|
| news | Tipo de Contenido Core + Views |
| powermail | Módulo Webform |
| solr (ext:solr) | Search API + Solr |
| realurl / routing | Pathauto + enrutamiento core |
| gridelements | Layout Builder o Paragraphs |
| mask | Paragraphs |
| tt_address | Tipo de contenido personalizado o CiviCRM |
| ke_search | Search API |
| femanager | Módulo User + personalizado |
| cal/events | Tipo de contenido personalizado + Views |
Las extensiones Extbase personalizadas necesitan ser reescritas como módulos de Drupal. No hay atajos — asegúrate de presupuestarlo.
Estructura de URL y Preservación SEO
Mete la pata aquí, y pierdes tráfico orgánico. He visto organizaciones perder hasta un 40% de su tráfico de búsqueda post-migración debido a redireccionamientos mal manejados.
Pasos
- Exporta todas las URLs desde TYPO3. Usa una herramienta CLI o un rastreador para cada URL indexada.
- Mapea estas a URLs de Drupal. Usa Pathauto de Drupal para la generación de alias de URL, adhiriéndote de cerca a URLs existentes.
- Crea redireccionamientos para todo lo que cambia. Despliega el módulo Redirect en Drupal. Para montañas de redireccionamientos, importa vía CSV.
- Maneja prefijos de idioma. TYPO3 usa
/de/,/en/,/fr/- asegúrate de que las configuraciones de idioma de Drupal reflejen esto. - Envía mapas del sitio actualizados a Google Search Console de inmediato.
# Ejemplo de formato CSV de importación de redirección para el módulo Redirect de Drupal
source,redirect,status_code,language
/alte-seite,/new-page,301,de
/old-page/subpage,/new-page/subpage,301,en
/kontakt,/contact,301,de
Consejo de profesional: Mantén la instancia antigua de TYPO3 en vivo, aunque sea de solo lectura, durante un mínimo de tres meses post-migración. Descubrirás URLs que pasaste por alto.
Volviéndose Headless Después de la Migración
Drupal brilla con su camino hacia un frontend desacoplado. Con Drupal 11, el módulo JSON:API es sólido como una roca, y el ecosistema Drupal headless es próspero.
Si estás rumiando un enfoque headless — y en 2026, para la mayoría de sitios orientados al contenido, merece la pena considerarlo — hemos profundizado en esto completamente en /solutions/headless-cms-development.
Emparejando frontends populares con Drupal:
- Next.js — El líder.
next-drupalde Chapter Three facilita las cosas. Lo discutimos extensamente en /capabilities/nextjs-development. - Astro — Perfecto para sitios cargados de contenido que no son demasiado pesados en cliente. Ver /capabilities/astro-development.
- Nuxt — Si Vue es tu área de juegos.
La belleza de migrar primero a Drupal es lanzar con el frontend predeterminado Twig de Drupal. Más adelante, puedes cambiar a uno desacoplado. No intentes ambos movimientos a la vez — eso es pedir caos de proyecto.
Estimaciones de Cronograma, Costo y Personal
Números reales de proyectos en los que he sido parte, o tengo datos precisos de (años recientes):
| Tamaño del Sitio | Páginas | Cronograma | Rango de Presupuesto | Equipo |
|---|---|---|---|---|
| Pequeño | <500 páginas | 2-3 meses | $30,000-60,000 | 2-3 desarrolladores |
| Mediano | 500-5,000 páginas | 4-6 meses | $60,000-150,000 | 3-5 desarrolladores |
| Grande | 5,000-50,000 páginas | 6-12 meses | $150,000-400,000 | 5-8 desarrolladores |
| Empresarial | 50,000+ páginas | 12-18 meses | $400,000-1,000,000+ | 8-15 desarrolladores |
Estos incluyen todo desde descubrimiento, modelado de contenido, migración, temática de frontend, QA y capacitación editorial. El mantenimiento continuo no está cubierto aquí.
El gran factor de costo no es solo el recuento de páginas — es la complejidad. Un sitio de 2,000 páginas con 30 tipos de contenido personalizados e 4 idiomas costará más que un sitio simple de 10,000 páginas.
¿Considerando especificidades para tu caso? Revisa /pricing o ponte en contacto directamente.
Lista de Verificación Post-Migración
No saltes esta lista de verificación. Confía en mí.
- Verifica todos los redireccionamientos. Asegúrate de que sean 301s.
- Actualiza Google Search Console con tu nuevo sitemap.
- Prueba todos los formularios: contacto, boletín, inicio de sesión.
- Asegura la precisión del contenido multilingüe para cada idioma.
- Migra archivos de medios con precisión con texto alternativo y metadatos.
- Verifica permisos de editor para cada rol.
- Captura métricas de rendimiento (Core Web Vitals).
- Verifica seguimiento de análisis (eventos GA4, objetivos).
- Configura y prueba CDN/almacenamiento en caché.
- Habilita encabezados de seguridad (CSP, HSTS).
- Prueba sistemas de copia de seguridad y recuperación ante desastres.
- Completa capacitación editorial y entrega documentación.
- Mantén la instancia antigua de TYPO3 disponible en modo de solo lectura.
Preguntas Frecuentes
¿Cuánto tiempo suele tomar una migración de TYPO3 a Drupal?
Para sitios de tamaño medio (500-5,000 páginas), son alrededor de 4-6 meses de inicio a lanzamiento. ¿El primer mes? Puramente descubrimiento y modelado de contenido. El scripting de migración generalmente significa 6-8 semanas de trabajo. QA y capacitación editorial? Cuenta con otro mes. Si es una configuración compleja multilingüe, multi-sitio con extensiones personalizadas, estás mirando 9-12 meses.
¿Puedo migrar contenido de TYPO3 automáticamente, o es manual?
¿Contenido estructurado como páginas, registros de noticias o categorías? Absolutamente un trabajo automatizado con el API de Migración de Drupal. Pero la lógica de renderizado compleja de contenido de TYPO3 podría necesitar algo de TLC manual. ¿La mayoría de migraciones? Alrededor del 70-80% automático, 20-30% manual.
¿Perderé mis clasificaciones de Google durante la migración?
No si eres diligente con tus redireccionamientos. Establece esos 301s para cualquier cambio de URL, adhiérete a tu estructura de URL lo mejor que puedas, envía esos mapas del sitio actualizados de inmediato. Probablemente verás una caída, digamos 2-6 semanas. Pero una recuperación es típica — los sitios generalmente rebotan a niveles pre-migración en 4-8 semanas y a menudo ven mejoras en tres meses debido al mejor rendimiento.
¿Es Drupal más difícil de aprender que TYPO3 para editores de contenido?
Diferente, no más difícil. Los acostumbrados al modelo de árbol de páginas de TYPO3 pueden necesitar tiempo con el enfoque centrado en entidades de Drupal. El módulo Paragraphs ofrece una experiencia de construcción de contenido algo similar. Recuerda presupuestar alrededor de 2-3 días de capacitación para editores y proporcionarles documentación específica de tipo de contenido y flujo de trabajo.
¿Qué sucede con mis extensiones de TYPO3 durante la migración?
Cada extensión merece evaluación individual. Muchas tienen equivalentes directos de Drupal (por ejemplo, powermail → Webform, ext:news → tipo de contenido personalizado + Views, ext:solr → Search API + Solr). ¿Extensiones Extbase personalizadas? Necesitarán una reescritura completa como módulos de Drupal. No hay convertidor — necesitarás personalizar.
¿Debería volverme headless al migrar de TYPO3 a Drupal?
Depende de tus objetivos y cronograma. Si tu movimiento está motivado por preocupaciones de desarrollador o mantenibilidad, comienza simple con la temática Twig de Drupal, apunta a headless después. Pero si tu equipo de frontend ama React o una configuración similar, y ansías arquitectura de entrega moderna, considera planificar headless desde el primer día. Solo recuerda: ¿haciendo tanto migración de sitio como cambios de frontend a la vez? Ese es territorio de alto riesgo.
¿Cómo manejo contenido multilingüe en la migración?
La configuración de idioma de TYPO3 (sys_language_uid, l10n_parent) se alinea bien con el módulo Content Translation de Drupal. ¿El truco? Clavar el mapeo de idioma a idioma en tus scripts y asegurar que los fallbacks coincidan con tus expectativas. Ten cuidado con contenido parcialmente traducido — los modos de overlay de idioma de TYPO3 (libre, conectado, estricto) no tienen paralelos precisos de Drupal. Las decisiones editoriales sobre traducciones incompletas podrían ser necesarias.
¿Cuál es el ROI de migrar de TYPO3 a Drupal?
¿Dónde está el ROI? Principalmente en reducir gastos de desarrollador y acelerar el lanzamiento de características. Históricamente, los equipos que he guiado ven alrededor de un 20-40% de corte en costos de desarrollo en el año uno, gracias principalmente a reclutamiento de talento más fácil y tener un grupo de módulos más grande que reduce la necesidad de desarrollo personalizado. Los costos iniciales de migración pueden ser considerables, pero la mayoría debería equilibrarse dentro de 18-24 meses.