Migrar tu web a Drupal desde WordPress: ventajas y proceso paso a paso

Llevo quince años haciendo Drupal y diez peleándome con WordPress, así que voy a decirlo claro desde el principio: WordPress no es malo, es el equivocado para según qué proyectos. Si tienes un blog, una web corporativa de veinte páginas o una tienda con un catálogo pequeño, WordPress hace su trabajo y lo hace barato. El problema empieza cuando intentas estirarlo más allá de su zona de confort. Y ahí es donde aparece la conversación sobre migrar tu web a Drupal desde WordPress, con las ventajas y el proceso paso a paso que conlleva.

Lo primero que aviso a cualquier cliente: esto no es un fin de semana. No es "instalo Drupal, exporto el contenido y listo". Una migración seria, de las que no rompen producción ni hunden el SEO, lleva semanas o meses dependiendo del tamaño del sitio. Lo digo desde la experiencia de haber roto producción una vez por confiarme con un plugin que parecía inocente. Aquí va lo que he aprendido haciendo este trabajo en serio.

Cuándo Drupal te resuelve el problema (y cuándo no)

Antes de meterte en faena, párate a pensar si de verdad necesitas migrar. He visto proyectos pequeños que se han pasado a Drupal por moda y han acabado pagando una factura de mantenimiento desproporcionada. Drupal tiene sentido cuando se cumple alguna de estas condiciones.

Tu volumen y tu modelo de datos se han disparado

WordPress lleva bien unos miles de entradas con estructura sencilla. Cuando empiezas a hablar de decenas de miles de contenidos, taxonomías profundas, relaciones entre tipos de contenido y campos personalizados con validaciones de verdad, WordPress empieza a sostenerse a base de plugins encadenados. Drupal trae todo eso de serie. Sus Content Types son nativos, no una capa pegada con celo encima.

Necesitas multiidioma en serio

Aquí WordPress depende de WPML o Polylang. Funcionan, pero suman complejidad y cada actualización del núcleo es un pequeño examen de fe. Drupal incluye traducción de contenidos, interfaz, configuración y URLs en su arquitectura. Lo notas el día que un editor tiene que sacar la misma noticia en cinco idiomas y nadie tiene que llamarte de madrugada.

Te juegas algo serio en seguridad

Drupal es la plataforma de gobiernos, universidades y organizaciones que manejan datos sensibles por una razón. El equipo de seguridad publica advisories con disciplina y el núcleo tiene protecciones de fábrica frente a las vulnerabilidades habituales. WordPress paga el precio de su popularidad: cada plugin de terceros añade superficie de ataque, y mantener un sitio grande limpio es un trabajo a tiempo parcial.

Necesitas integraciones empresariales de verdad

API REST y JSON:API nativas, GraphQL bien soportado, arquitectura modular pensada para conectar con ERPs, CRMs, LDAP, SAML, OAuth. Si encima quieres usar Drupal como backend headless de un frontend en React o Vue, lo hace sin retorcerse. WordPress también lo intenta, pero el ecosistema está pensado para otra cosa.

El rendimiento bajo carga te aprieta

Caché multinivel, integración con Varnish y CDN, escalado horizontal predecible. Para un portal con picos de tráfico altos, la diferencia se nota en la factura de servidores y en las horas de sueño del equipo de infraestructura.

Lo que ganas técnicamente con Drupal

• Modelo de datos tipado: los Content Types modelan cualquier estructura con campos validados y referencias entre entidades, sin plugins de por medio.
• Permisos granulares de verdad: roles y permisos por tipo de contenido, por campo y por operación. WordPress no llega a ese nivel sin ayuda externa.
• Workflow editorial: borrador, en revisión, publicado, archivado. Está integrado desde Drupal 8 y funciona.
• Arquitectura modular con dependencias explícitas: cada módulo declara de qué depende. Los conflictos se ven antes de que exploten en producción.
• Gobernanza del proyecto: estándares de código, tests y revisión por pares para cada cambio en el núcleo. Eso se traduce en estabilidad a largo plazo.

El proceso, fase por fase

Fase 1: auditar lo que ya tienes

Antes de tocar nada, inventario completo. Sin esto, te garantizo que algo se queda fuera y aparece tres meses después.

• Contenidos: cuántas entradas, páginas, custom post types, taxonomías, medios.
• Plugins activos y la funcionalidad concreta que aportan, con su equivalente en Drupal.
• Tema actual, modificaciones y todo lo que alguien metió en functions.php a las dos de la mañana.
• SEO: estructura de URLs, metadatos, redirecciones, sitemaps y posicionamiento actual.
• Integraciones: formularios, analítica, marketing, pasarelas de pago, APIs externas.
• Usuarios, roles y cuentas activas.

Este inventario no es burocracia. Es la diferencia entre una migración que sale bien y una que descubres a medias.

Fase 2: diseñar la arquitectura en Drupal

Con el inventario en la mano, se diseña la estructura nueva. Aquí está la trampa en la que cae mucha gente: replicar uno a uno lo que tenían en WordPress. Eso es desaprovechar Drupal. La migración es el momento para repensar tipos de contenido, taxonomías y vistas con cabeza.

• Content Types con sus campos, validaciones y relaciones.
• Vocabularios de taxonomía que mapeen categorías y etiquetas existentes.
• Listados y vistas con el módulo Views.
• Selección de módulos contribuidos para cubrir lo que hacían los plugins.
• Tema: replicar el actual o aprovechar para rediseñar.
• Estructura de URLs planificada con Pathauto, para no romper SEO ni dejar URLs feas.

Fase 3: migrar los contenidos

Drupal trae un framework de migración serio. Las piezas que vas a usar.

• Migrate Drupal: en el núcleo, permite importar desde WordPress directamente.
• Migrate Plus y Migrate Tools: contribuidos, amplían fuentes de datos, transformaciones y herramientas de ejecución.

El flujo típico que sigo:

1. Exportar la base de datos de WordPress o conectar directamente.
2. Escribir las configuraciones de migración mapeando cada tipo de contenido, campo y taxonomía.
3. Ejecutar en desarrollo, revisar resultados, ajustar.
4. Iterar hasta que la migración salga limpia de verdad, no "casi bien".
5. Migración final en producción durante una ventana de mantenimiento acordada.

Las imágenes y archivos viajan con sus contenidos manteniendo referencias. Los enlaces internos hay que reescribirlos para que casen con la nueva estructura de URLs. Esto último se olvida más de lo que parece.

Fase 4: SEO sin perder el trabajo de años

Aquí es donde una migración mal hecha hunde un proyecto. El tráfico orgánico se cae y tardas meses en recuperarlo, si es que lo recuperas.

• Redirecciones 301 desde cada URL antigua a su equivalente nueva. El módulo Redirect gestiona esto en masa.
• Metadatos con Metatag y Schema.org Metatag: títulos, descripciones, datos estructurados.
• Sitemap XML con Simple XML Sitemap, enviado a Google Search Console el día del lanzamiento.
• Canonical URLs verificadas contenido por contenido.
• Monitorización durante semanas después del go-live. Search Console te avisa de errores de rastreo, pérdidas de posición y problemas de indexación.

Si te interesa profundizar en el lado técnico, en nuestro artículo sobre cómo optimizar el rendimiento y velocidad de una web en Drupal entramos en detalle.

Fase 5: testing y QA

Antes del lanzamiento, comprobaciones obligatorias.

• Volumen y formato de los contenidos migrados, campo a campo en muestras representativas.
• Funcionalidades operativas: formularios, búsqueda, filtros, login.
• Redirecciones funcionando para una muestra amplia de URLs antiguas.
• Pruebas de carga con cifras realistas, no con un usuario concurrente.
• Comportamiento en móvil.
• Flujos de edición probados por el equipo editorial real, no por el equipo técnico.

Fase 6: go-live y vigilancia

Lanzas en franja de bajo tráfico, ni se te ocurra un viernes a las cinco de la tarde. El día D.

1. Migración final de los contenidos creados o modificados desde la última prueba.
2. Cambio de DNS o de configuración del servidor.
3. Verificación desde varios dispositivos y ubicaciones.
4. Envío del sitemap actualizado a Search Console.
5. Vigilancia activa de errores 404, rendimiento y comportamiento durante las primeras 48 horas.

Los errores que veo una y otra vez

• No inventariar todos los plugins. Cada uno hace algo. Olvidar uno significa perder funcionalidad sin saberlo hasta que un usuario se queja.
• Saltarse las redirecciones 301. Esto te cuesta meses de SEO. No es opinable.
• Subestimar el tiempo de migración de contenidos. Cuando hay campos personalizados, relaciones y adjuntos, esta fase se come el calendario.
• No formar al equipo editorial. Drupal no se gestiona como WordPress. Si el equipo de contenidos no recibe formación, vas a tener una herramienta potente que nadie usa bien.
• Migrar replicando la estructura antigua. Si copias WordPress en Drupal sin repensar nada, has pagado una migración para no aprovechar lo que la nueva plataforma te da.

Cuándo migrar conviene y cuándo no

No migres por moda ni porque alguien te haya contado que Drupal es "más profesional". Migra cuando tu proyecto ha superado lo que WordPress puede sostener: volumen, multiidioma serio, seguridad estricta, integraciones empresariales, rendimiento bajo carga. Si nada de eso aplica, quédate donde estás y dedica el presupuesto a otra cosa.

Si en cambio reconoces tu proyecto en lo que he descrito, Drupal te va a dar tranquilidad durante años. Eso sí, hazlo con un equipo que haya pasado por esto antes. Las migraciones tienen muchas trampas pequeñas y cada una cuesta dinero o posicionamiento. En Tangram Consulting llevamos años trabajando con las dos plataformas y, si quieres, revisamos tu sitio actual antes de tomar la decisión. Mejor dedicar dos horas a evaluar que tres meses a arreglar una migración mal planteada.

La plataforma correcta es la que encaja con tu proyecto. No al revés.