Migración de TYPO3 a Drupal: Guía Práctica para Desarrolladores
Si alguna vez has mirado un backend de TYPO3 y pensaste, "tiene que haber una mejor manera", créeme, estás lejos de ser el único. TYPO3 tiene su poder – no voy a discutirlo. Ha sido el favorito de los CMS para innumerables empresas europeas y sitios gubernamentales durante más de veinte años. Pero, seamos honestos, el panorama de desarrolladores ha cambiado una barbaridad. Muchas organizaciones están descubriendo que Drupal ofrece una configuración más moderna, una comunidad más fuerte, y un camino más fácil hacia arquitecturas headless/desacopladas.
He estado metido en un par de migraciones de TYPO3 a Drupal en los últimos años, y ha sido todo un viaje desenredando modelos de contenido del mundo real. Suelen ser un lío enredado. Esta guía es lo que desearía que alguien me hubiera entregado antes de mi primera migración. Cubriré todos los detalles técnicos complicados, los imprescindibles de planificación, y esas minas terrestres traviesas 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
- Manejo de TypoScript de TYPO3 y Extensiones
- Estructura de URLs y Preservación de 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 claros: TYPO3 no es un mal CMS. Es tremendamente flexible, maneja sitios múltiples y configuraciones multilingües de forma nativa, contando con una base de fans incondicionales especialmente en la región DACH. Entonces, ¿por qué la gente se va?
Escucho las mismas razones prácticamente cada vez:
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 globales, según el informe de la comunidad 2024 de Drupal.org. ¿TYPO3? No tanto. Si tus desarrolladores TYPO3 senior deciden irse, llenar esos puestos podría tardar una eternidad.
Impulso del ecosistema. Con el lanzamiento de Drupal 11 a finales de 2024, hubo enormes avances en la UI de admin, un nuevo sistema de recetas, y capacidades increíbles enfocadas en API. Claro, TYPO3 v13 es sólido, pero la tasa de innovación en Drupal, particularmente en torno a configuraciones headless, es notablemente más rápida.
Arquitectura headless/desacoplada. ¿Planeando servir contenido a un elegante frontend Next.js o Astro? El JSON:API de Drupal y los complementos GraphQL son profesionales experimentados. TYPO3 tiene su propia extensión headless, pero es menos madura con un respaldo más pequeño.
Costo total de propiedad. Alojar TYPO3 típicamente golpea la cartera más fuerte. Su infraestructura especializada significa que podrías acabar gastando más. Drupal es feliz prácticamente en cualquier lugar desde Pantheon hasta Acquia, incluso un stack LAMP básico la mantiene ronroneando.
TYPO3 vs Drupal: Una Comparación Honesta
Antes de lanzarte de cabeza a un cambio, asegúrate de que Drupal genuinamente va a resolver tus puntos de dolor. Aquí está la información a partir de 2025:
| Característica | TYPO3 v13 | Drupal 11 |
|---|---|---|
| Modelado de Contenido | Flexible pero se inclina por 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 |
| Templating | Cuenta con plantillas Fluid + TypoScript | Se ejecuta en plantillas Twig |
| Extensión/Ecosistema de Módulos | ~1,800 extensiones en TER | ~50,000+ módulos en Drupal.org |
| Admin UI | Fuerte, pero anticuado (recibiendo un cambio de imagen en v13) | Elegante y moderno en Drupal 11 |
| Comunidad de Desarrolladores | ~500 contribuidores activos | 8,000+ contribuidores activos |
| Opciones de Hosting | Auto-alojado o especialista | Auto-alojado, Pantheon, Acquia, Platform.sh, Lagoon |
| Requisito de PHP | PHP 8.2+ | PHP 8.3+ |
| Tarifa Típica de Agencia | €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 gestionar jerarquías de páginas elaboradas 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 capacitación de 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 las 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 tienes en juego. - Elementos de contenido: Cada
CType(tipo de contenido) necesita atención—sea texto, texto con imagen, HTML, o cosas personalizadas a través demaskocontent_defender. - Extensiones: Anota cada extensión que tengas. Averigua si hay un equivalente en Drupal.
- Referencias de archivo: El FAL de TYPO3 (File Abstraction Layer) trata con medios. Mapea estos a los espacios de medios de Drupal.
- Usuarios backend y permisos: Los grupos intrincados de usuarios backend de TYPO3 con acceso a nivel de página y campo deben ser traduzidos correctamente a roles y permisos de Drupal.
Aquí hay una consulta SQL práctica para un resumen de elementos 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 40+ tipos de elementos de contenido personalizados, donde solo una docena se usaba activamente. No arrastres peso muerto.
Qué Mantener, Qué Eliminar
Aquí está tu oportunidad para limpiar la casa. Usa una herramienta de auditoría de contenido como Screaming Frog o Sitebulb para descubrir:
- Páginas sin tráfico en el año pasado
- Contenido duplicado o casi idéntico
- Enlaces internos rotos
- Archivos multimedia huérfanos
Típicamente, hay un corte de contenido del 30-50% en grandes migraciones de TYPO3. Menos páginas significa migraciones más rápidas.

Modelado de Contenido: Mapeando TYPO3 a Drupal
Arremángate. Este es el levantamiento intelectual pesado. TYPO3 y Drupal manejan contenido de formas muy diferentes.
Modelo de TYPO3
TYPO3 gira en torno a páginas. Todo está metido en un árbol de páginas. Los elementos de contenido (registros en tt_content) se ajustan 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 se trata de entidades. Creas tipos de contenido (bundles de nodos), 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 |
|---|---|
| Página (doktype: estándar) | Nodo (tipo de contenido: Página) |
| Página (doktype: atajo) | Redirección de URL |
| Página (doktype: enlace) | Nodo con campo de enlace o redirección |
| Elemento de contenido (CType: texto) | Tipo de párrafo o campo Body |
| Elemento de contenido (CType: imagen) | Referencia de entidad de medios |
| Elemento de contenido (CType: textpic) | Tipo de párrafo con texto + medios |
| Elemento de contenido (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 Drupal |
| be_users | Entidad de usuario Drupal con rol admin |
| Plantilla TypoScript | Plantilla Twig |
| Complemento Extbase | Módulo Drupal personalizado |
| Elementos de contenido Mask/DCE | Tipos de párrafo |
¿El cambio más grande? Mover elementos de contenido a Párrafos. 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 transparente.
Herramientas de Migración y Enfoque Técnico
La API Migrate de Drupal es increíble. Pero atención, carece de un complemento de fuente TYPO3 nativo. Tendrás que elaborar algunos complementos de fuente personalizados para extraer de la base de datos de TYPO3.
Enfoque 1: Migración Directa de Base de Datos
Enchufa la API Migrate de Drupal directamente en tu base de datos MySQL/MariaDB de TYPO3:
// Ejemplo de complemento de fuente migrate para páginas 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('ID de Página'),
'title' => $this->t('Título de página'),
'slug' => $this->t('Slug de URL'),
'abstract' => $this->t('Resumen/sumario'),
];
}
public function getIds() {
return ['uid' => ['type' => 'integer']];
}
public function prepareRow(Row $row) {
// Carga elementos de contenido asociados
$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 permite manejar las peculiaridades de TYPO3 (como soft-deletes y superposiciones de espacios de trabajo) en tu código.
Enfoque 2: Exportación/Importación a través de JSON o XML
Algunos equipos eligen exportar contenido de TYPO3 a formatos estructurados (digamos, a través de extensiones TYPO3 personalizadas o comandos CLI) y luego importarlos en Drupal. Claro, añade otra capa pero es útil si eres cauteloso sobre mantener conexiones directas de base de datos durante la migración.
Enfoque 3: Híbrido con Revisión Manual
¿Un sitio más pequeño (menos de 500 páginas)? ¿Hacer una migración automática de datos estructurados mientras se crean manualmente páginas de destino clave puede funcionar de maravilla? Podría parecer rudimentario, pero cuando el contenido está entrelazado con lógica de renderizado específica de TYPO3, la migración automatizada a menudo resulta en sinsentidos.
Manejo de TypoScript de TYPO3 y Extensiones
TypoScript
Vayamos al grano: TypoScript no se migra. Es un lenguaje de configuración específico de TYPO3, sin un verdadero contraparte en otro lugar. Tu trabajo es documentar qué hace cada plantilla de TypoScript en términos sencillos y luego reconstruirlo como plantillas Twig y configuración de Drupal. Es tedioso pero necesario.
Extensiones
Aquí hay una comparación práctica de extensiones comunes de TYPO3 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 presupuestar para ello.
Estructura de URLs y Preservación de SEO
Lía esto, y pierdes tráfico orgánico. He visto organizaciones perder hasta el 40% de su tráfico de búsqueda post-migración debido a redirecciones mal manejadas.
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, manteniéndote lo más cercano posible a las URLs existentes.
- Crea redirecciones para todo lo que cambie. Implementa el módulo Redirect en Drupal. Para montañas de redirecciones, importa a través de CSV.
- Maneja prefijos de idioma. TYPO3 usa
/de/,/en/,/fr/- asegúrate de que la configuración de idioma de Drupal refleje esto. - Envía sitemaps actualizados a Google Search Console inmediatamente.
# Formato de importación CSV de ejemplo 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 profesional: Mantén la instancia TYPO3 antigua en vivo, aunque sea de solo lectura, por un mínimo de tres meses post-migración. Desenterrarás URLs que faltaron.
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 de Drupal headless está prosperando.
Si estás rumiando un enfoque headless—y en 2025, para la mayoría de sitios basados en contenido, vale la pena considerarlo—hemos profundizado esto a fondo en /solutions/headless-cms-development.
Emparejando frontends populares con Drupal:
- Next.js — El favorito.
next-drupalpor 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 terreno de juego.
La belleza de migrar primero a Drupal es lanzar con el frontend Twig predeterminado de Drupal. Más tarde, 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 estado involucrado, o tengo datos precisos de (2024-2025):
| Tamaño de Sitio | Páginas | Cronograma | Rango de Presupuesto | Equipo |
|---|---|---|---|---|
| Pequeño | <500 páginas | 2-3 meses | $30,000-60,000 | 2-3 desarrolladores |
| Medio | 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 |
| Empresa | 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, teasing de frontend, QA, y capacitación de editores. El mantenimiento continuo no se cubre 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 y 4 idiomas costará más que un sitio simple de 10,000 páginas.
¿Considerando especificidades para tu caso? Consulta /pricing o ponte en contacto directamente.
Lista de Verificación Post-Migración
No saltes esta lista de verificación. Créeme.
- Verifica todas las redirecciones. 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 alt y metadatos.
- Verifica permisos de editor para cada rol.
- Captura métricas de rendimiento (Core Web Vitals).
- Verifica el seguimiento de análisis (eventos GA4, objetivos).
- Configura y prueba CDN/caché.
- Habilita encabezados de seguridad (CSP, HSTS).
- Prueba sistemas de copia de seguridad y recuperación ante desastres.
- Completa la capacitación de editores y proporciona documentación.
- Mantén disponible la instancia TYPO3 antigua 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), es aproximadamente 4-6 meses desde el inicio hasta el lanzamiento. ¿El primer mes? Puramente descubrimiento y modelado de contenido. Los scripts de migración generalmente significan 6-8 semanas de trabajo. ¿QA y capacitación de editores? Cuenta con otro mes. Si es una configuración multilingüe compleja, multi-sitio con extensiones personalizadas, estás buscando 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 la API Migrate de Drupal. Pero el contenido de lógica de renderizado compleja de TYPO3 podría necesitar algo de cuidado 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 redirecciones. Establece esos 301s para cualquier cambio de URL, cíñete a tu estructura de URL lo mejor que puedas, envía esos sitemaps actualizados rápido. Probablemente verás una caída, digamos 2-6 semanas. Pero un rebote es típico—los sitios generalmente rebotan a niveles pre-migración en 4-8 semanas y a menudo ven mejoras en tres meses debido a un 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 del tipo de contenido y flujo de trabajo.
¿Qué sucede con mis extensiones de TYPO3 durante la migración?
Cada extensión merece una 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 cuando migro de TYPO3 a Drupal?
Depende de tus objetivos y cronograma. Si tu movimiento está motivado por preocupaciones de desarrollador o mantenibilidad, comienza simple con teasing Twig de Drupal, apunta a headless más tarde. Pero si tu equipo de frontend ama React o una configuración similar, y deseas arquitectura de entrega moderna, considera planificar para headless desde el día uno. Solo recuerda: ¿hacer ambas migraciones y 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 el fallback coincida con tus expectativas. Ten cuidado con el contenido parcialmente traducido—los modos de superposición de idioma de TYPO3 (libre, conectado, estricto) no tienen equivalentes precisos en 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 de recortar gastos de desarrollador y acelerar el lanzamiento de características. Históricamente, los equipos que he guiado ven alrededor de un corte del 20-40% en costos de desarrollo en el primer año, gracias principalmente a la reclutación más fácil de talento y tener un pool de módulos más grande que reduce la necesidad de desarrollo personalizado. Los costos iniciales de migración pueden ser elevados, pero la mayoría debería equilibrarse en 18-24 meses.