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:
- Exportar la base de datos de WordPress o conectar directamente.
- Escribir las configuraciones de migración mapeando cada tipo de contenido, campo y taxonomía.
- Ejecutar en desarrollo, revisar resultados, ajustar.
- Iterar hasta que la migración salga limpia de verdad, no "casi bien".
- 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.
- Migración final de los contenidos creados o modificados desde la última prueba.
- Cambio de DNS o de configuración del servidor.
- Verificación desde varios dispositivos y ubicaciones.
- Envío del sitemap actualizado a Search Console.
- 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.
Artículos relacionados
Preguntas frecuentes
Las dudas más comunes. Si la tuya no está, pregúntanos
En Tangram no queremos que la información pase por una cadena interminable de intermediarios donde se pierden los detalles importantes.
Contarás con un interlocutor que coordinará la comunicación y trasladará las decisiones al equipo responsable de tu proyecto.
Cuando sea necesario profundizar en cuestiones de estrategia, diseño o tecnología, podremos involucrar a los especialistas correspondientes.
Así tendrás una comunicación organizada, sin necesidad de gestionar personalmente a todos los profesionales que intervienen.
Queremos que tengas acceso al conocimiento de un equipo especializado, sin sufrir la complejidad de coordinarlo.
No tendrás que averiguar a quién escribir cada vez que tengas una duda.
En Tangram contemplamos la figura del Account Manager como interlocutor principal, encargado de acompañarte durante el proyecto, coordinar la comunicación y facilitar el seguimiento de las decisiones.
Nuestra metodología incluye reuniones de revisión, canales de comunicación y herramientas para que puedas participar en el trabajo.
La organización concreta, la frecuencia de las reuniones y los canales disponibles se establecerán según el proyecto contratado.
Lo importante es que sepas con quién hablar, en qué punto está tu proyecto y qué decisiones necesitan tu participación.
Sí, podemos valorar una colaboración con los profesionales que ya trabajan en tu empresa.
No siempre tiene sentido sustituir un equipo que conoce bien tu negocio. En muchas situaciones, lo más útil es complementar sus conocimientos con especialistas en determinadas áreas.
Podemos estudiar qué responsabilidades asumiría Tangram, cuáles mantendría tu equipo y cómo coordinar las decisiones para evitar duplicidades.
La forma concreta de colaboración dependerá de la organización, las herramientas y las necesidades del proyecto.
No se trata de reemplazar lo que ya funciona, sino de aportar el conocimiento que necesitas para llegar más lejos.
No tienes por qué cambiar de proveedor para explorar una colaboración con Tangram.
Durante nuestra trayectoria hemos trabajado con agencias y consultoras, participando en proyectos en los que cada empresa asumía una parte diferente del trabajo.
Esa experiencia nos permite comprender la importancia de definir responsabilidades y coordinar a los profesionales implicados.
Podemos valorar una colaboración para cubrir necesidades concretas que tu proveedor actual no ofrece o para reforzar determinadas áreas.
Si tienes una relación profesional que funciona, no queremos que la rompas sin motivo. Queremos encontrar dónde podemos aportar valor.
La confidencialidad es especialmente importante cuando hablamos de nuevas ideas de negocio, información económica, estrategias comerciales o desarrollos tecnológicos.
En Tangram tenemos experiencia trabajando en proyectos sujetos a acuerdos de confidencialidad, motivo por el que no podemos mostrar públicamente muchos de los trabajos en los que hemos participado.
Si tu proyecto requiere un acuerdo de confidencialidad (NDA) antes de compartir información sensible, podemos revisar sus condiciones y acordar cómo proteger esa información antes de entrar en los detalles.
Entendemos que la confianza empieza por respetar lo que todavía no quieres hacer público.