Cómo migrar un sitio web de Drupal a WordPress: una guía técnica completa

Migrar de Drupal a WordPress implica transferir el contenido de la base de datos, los archivos multimedia, la estructura de URL y las cuentas de usuario desde la arquitectura CMS basada en entidades de Drupal al modelo de tipos de publicación de WordPress, sin perder valor SEO, romper enlaces internos ni causar tiempo de inactividad. El proceso implica una importación de contenido a nivel de base de datos mediante el plugin FG Drupal to WordPress, seguida de la asignación de permalinks, la configuración de redirecciones 301 y la reconstrucción del tema.

Esta guía cubre cada fase de esa migración con detalle técnico preciso: estrategia de copia de seguridad previa a la migración, configuración del entorno, extracción de credenciales de base de datos, importación mediante plugin, reconciliación de la estructura de URL y validación posterior al lanzamiento. Ya sea que esté ejecutando Drupal 7, 9 o 10, el flujo de trabajo a continuación es aplicable.

Por qué migrar de Drupal a WordPress

Drupal es un framework potente, pero su complejidad conlleva un coste operativo real. Las actualizaciones de módulos frecuentemente introducen cambios disruptivos, la creación de temas requiere experiencia en plantillas Twig, y las ediciones de contenido rutinarias exigen la intervención de un desarrollador. WordPress, en cambio, ofrece una curva de aprendizaje más suave, un ecosistema de plugins mucho más amplio y un coste total de propiedad menor para sitios con mucho contenido que no requieren el control de acceso granular o el modelado de contenido complejo de Drupal.

El argumento del rendimiento también importa. Una instalación de WordPress en un entorno de Hosting VPS correctamente configurado con LiteSpeed, caché de objetos y almacenamiento NVMe superará consistentemente en rendimiento a una infraestructura Drupal sobrecargada en un entorno compartido.

Principales motivaciones de migración según el caso de uso:

• Equipos editoriales frustrados por la UX de administración de Drupal y los lentos flujos de trabajo de publicación
• Agencias que consolidan sitios de clientes en un único CMS manejable
• Desarrolladores que reducen la carga de mantenimiento derivada de las cadenas de dependencias de módulos de Drupal
• Equipos SEO que buscan una integración más estrecha con herramientas nativas de WordPress como Yoast o Rank Math

Drupal vs. WordPress: Comparación de arquitecturas

Comprender las diferencias estructurales entre ambas plataformas es esencial antes de comenzar. Las suposiciones erróneas sobre cómo se almacena el contenido son la principal causa de migraciones fallidas o incompletas.

La brecha arquitectónica más crítica es el modelo de entidades de contenido. Drupal almacena párrafos, campos personalizados y referencias de taxonomía en múltiples tablas unidas. El plugin FG Drupal to WordPress los asigna a metadatos de publicación y términos de taxonomía de WordPress, pero los diseños complejos basados en párrafos requerirán reconstrucción manual.

Lista de verificación previa a la migración

Antes de tocar cualquiera de los dos entornos, complete cada elemento de esta lista. Omitir pasos aquí es la principal causa de pérdida de datos y tiempo de inactividad prolongado.

• Audite el inventario de contenido de Drupal: tipos de nodos, vocabularios de taxonomía, número de usuarios, número de archivos y tamaño total de la base de datos
• Identifique los módulos de Drupal sin equivalente en WordPress (p. ej., Rules, lógica compleja de Webform, Commerce)
• Confirme que su servidor WordPress cumple los requisitos mínimos: PHP 8.1+, MySQL 8.0+ o MariaDB 10.6+, límite de memoria PHP de 256 MB
• Decida una ventana de migración, idealmente en un período de bajo tráfico
• Active el modo de mantenimiento en Drupal durante el paso de importación final para evitar la deriva de contenido
• Verifique que el servidor WordPress pueda acceder al host de la base de datos de Drupal (mismo servidor, host remoto o túnel SSH)

Paso 1: Haga una copia de seguridad de su sitio web Drupal

Una copia de seguridad completa y verificada es innegociable. Necesita tanto el volcado de la base de datos como el directorio de archivos.

Copia de seguridad de la base de datos mediante Drush

Si tiene Drush instalado (estándar para Drupal 9/10), este es el método más rápido:

drush sql-dump --result-file=/var/backups/drupal_backup_$(date +%Y%m%d).sql --gzip

Copia de seguridad de la base de datos mediante mysqldump

mysqldump -u drupal_user -p drupal_database_name | gzip > /var/backups/drupal_backup_$(date +%Y%m%d).sql.gz

Copia de seguridad del directorio de archivos

tar -czf /var/backups/drupal_files_$(date +%Y%m%d).tar.gz /var/www/html/drupal/sites/default/files/

Copia de seguridad con phpMyAdmin (método GUI)

1. Inicie sesión en phpMyAdmin a través del panel de control de su alojamiento
2. Seleccione la base de datos de Drupal en la barra lateral izquierda
3. Haga clic en Exportar, elija el método de exportación Rápida, formato SQL
4. Haga clic en Continuar para descargar el archivo .sql

Almacene todos los archivos de copia de seguridad fuera del servidor: súbalos a almacenamiento remoto o descárguelos localmente mediante SFTP. Una copia de seguridad que solo existe en el mismo servidor que el sitio que se está migrando no es una copia de seguridad real.

Paso 2: Configure WordPress en su servidor de destino

Instale una instancia limpia de WordPress en su entorno de destino. No importe contenido de Drupal en un sitio WordPress existente a menos que haya planificado explícitamente la fusión de contenido; el importador no eliminará duplicados.

Requisitos del servidor

Para sitios Drupal grandes (más de 10.000 nodos, bibliotecas de medios de varios GB), un VPS con cPanel le da acceso directo a la configuración de PHP, los parámetros de ajuste de MySQL y la gestión de tareas cron, todo lo cual necesitará durante una migración intensiva.

Instalación de WordPress mediante WP-CLI

cd /var/www/html/wordpress
wp core download
wp config create --dbname=wp_database --dbuser=wp_user --dbpass=secure_password --dbhost=localhost
wp core install --url="https://yourdomain.com" --title="Site Title" --admin_user=admin --admin_password=strongpassword --admin_email=admin@yourdomain.com

Instalación con un clic mediante cPanel

Si su proveedor de alojamiento ofrece cPanel, navegue a Softaculous Apps Installer, seleccione WordPress, complete las credenciales de la base de datos y del administrador, y haga clic en Instalar. El proceso tarda menos de dos minutos.

Tras la instalación, configure inmediatamente estos ajustes de PHP en php.ini o mediante .htaccess:

php_value max_execution_time 300
php_value memory_limit 256M
php_value post_max_size 128M
php_value upload_max_filesize 128M

Paso 3: Instale y configure el plugin FG Drupal to WordPress

El plugin FG Drupal to WordPress (versión gratuita disponible; Premium recomendada para sitios grandes) gestiona la migración a nivel de base de datos de nodos, términos de taxonomía, usuarios y archivos multimedia.

Instalación

1. En el panel de administración de WordPress, vaya a Plugins > Añadir nuevo
2. Busque FG Drupal to WordPress
3. Haga clic en Instalar ahora y luego en Activar

Alternativamente, instale mediante WP-CLI:

wp plugin install fg-drupal-to-wp --activate

Comparación de características gratuitas vs. Premium

Para cualquier sitio en producción que ejecute Drupal 8 o posterior, la versión Premium vale la pena. Intentar reconstruir manualmente el contenido basado en párrafos es mucho más costoso en tiempo de desarrollo.

Paso 4: Obtenga las credenciales de la base de datos de Drupal

El plugin FG Drupal to WordPress se conecta directamente a su base de datos de Drupal. Necesita cuatro valores: nombre de la base de datos, nombre de usuario, contraseña y host.

Búsqueda de credenciales en settings.php de Drupal

grep -A 20 "'database'" /var/www/html/drupal/sites/default/settings.php

La salida contendrá un bloque como este:

$databases['default']['default'] = [
  'database' => 'drupal_db_name',
  'username' => 'drupal_db_user',
  'password' => 'drupal_db_password',
  'host' => 'localhost',
  'port' => '3306',
  'driver' => 'mysql',
];

Consideraciones sobre el acceso remoto a la base de datos

Si WordPress y Drupal están en servidores diferentes, la base de datos de Drupal debe aceptar conexiones remotas. En el servidor de base de datos de Drupal:

GRANT SELECT ON drupal_database.* TO 'drupal_user'@'wordpress_server_ip' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

Asegúrese también de que el puerto 3306 esté abierto en el firewall únicamente para la IP del servidor WordPress; nunca exponga MySQL a 0.0.0.0.

Si no puede abrir un puerto MySQL directo, use un túnel SSH:

ssh -L 3307:localhost:3306 user@drupal_server_ip -N -f

Luego configure el host de base de datos del plugin como 127.0.0.1 y el puerto como 3307.

Paso 5: Ejecute la importación de contenido

Navegue a Herramientas > Importar en su panel de WordPress, desplácese hasta la sección de Drupal y haga clic en Ejecutar importador.

Configuración de los ajustes del importador

Pestaña de conexión a la base de datos:

• Host de la base de datos: localhost (o IP remota / dirección del túnel SSH)
• Puerto: 3306 (o su puerto personalizado)
• Nombre de la base de datos: valor de settings.php
• Usuario / Contraseña: valores de settings.php
• URL de archivos de Drupal: la URL pública de su directorio sites/default/files/ de Drupal, necesaria para la descarga de medios

Haga clic en Probar la conexión antes de continuar. Un fallo de conexión en esta etapa casi siempre se debe a una de tres causas: credenciales incorrectas, un firewall que bloquea el puerto MySQL, o que el usuario de la base de datos de Drupal carece de privilegios SELECT sobre la base de datos de destino.

Pestaña de comportamiento: ajustes recomendados para la mayoría de las migraciones:

• Importar publicaciones: Sí
• Importar páginas: Sí
• Importar categorías y etiquetas: Sí
• Descargar imágenes y adjuntos: Sí (necesario para copiar los medios al directorio de subidas de WordPress)
• Eliminar datos de WordPress antes de importar: Sí (solo en una instalación nueva; esto trunca wp_posts y las tablas relacionadas)

Inicio de la importación

Haga clic en Iniciar / Reanudar el importador. El plugin procesa el contenido en lotes. Para sitios grandes, la importación puede agotar el tiempo de espera y requerir múltiples ciclos de reanudación; este es el comportamiento esperado, no un error. Simplemente haga clic en Reanudar cada vez.

Monitorice el registro de importación que se muestra en pantalla. Esté atento a:

Error downloading file — indica que la URL de archivos de Drupal es incorrecta o que el directorio de archivos no es accesible públicamente
Errores Duplicate entry — generalmente inofensivos, indican que el plugin está omitiendo registros ya importados durante una reanudación
MySQL server has gone away — indica que wait_timeout es demasiado bajo en el servidor MySQL; auméntelo a al menos 600 segundos

SET GLOBAL wait_timeout = 600;
SET GLOBAL interactive_timeout = 600;
Paso 6: Reconcilie la estructura de URL y configure las redirecciones
Este es el paso que la mayoría de las guías subestima. Las discrepancias en la estructura de URL entre Drupal y WordPress son la principal causa de caídas en el posicionamiento SEO tras la migración.
Patrones de URL de Drupal (comunes)




Patrón de URL de Drupal
Descripción




/node/123
Ruta de nodo predeterminada (sin alias)


/about-us
Alias de ruta (el más común)


/taxonomy/term/5
Página de término de taxonomía


/user/1
Perfil de usuario


/content/article-title
Alias con prefijo de tipo de contenido




Configuración de permalinks en WordPress
Vaya a Ajustes > Enlaces permanentes y seleccione una estructura que coincida lo más posible con los alias de ruta de Drupal. Para la mayoría de los sitios Drupal que usan alias limpios, /%postname%/ es la opción correcta.
/%postname%/
Si su sitio Drupal usaba URLs con prefijo de categoría como /blog/article-title, utilice:
/%category%/%postname%/
Implementación de redirecciones 301
Instale el plugin Redirection (de John Godley) para gestionar las reglas de redirección. Para redirecciones masivas, exporte los alias de ruta de Drupal desde la base de datos:
SELECT source, alias FROM path_alias WHERE langcode = 'en';
Luego importe el CSV resultante en el plugin Redirection, asignando cada alias de Drupal a su equivalente en WordPress. Para URLs con formato /node/123 que nunca tuvieron alias, cree redirecciones basadas en expresiones regulares:
/node/([0-9]+)$ → /?p=$1
Esto asigna los IDs de nodo de Drupal a los IDs de publicación de WordPress, pero solo funciona si el plugin FG conservó los IDs de nodo originales como IDs de publicación, lo cual hace por defecto.
Importante: Pruebe cada redirección con curl -I antes de publicar:
curl -I https://yourdomain.com/old-drupal-path
Verifique que la respuesta sea HTTP/2 301 con la cabecera Location correcta, no un 302 ni un 200 con una redirección suave.
Paso 7: Migre los temas y reconstruya el diseño
Los temas de Drupal (basados en Twig) no tienen equivalente directo en WordPress. Debe reconstruir el diseño visual usando un tema de WordPress como base.
Estrategia de selección de tema

Temas basados en bloques (FSE): Use el Editor de sitio de WordPress para un control total del diseño sin constructores de páginas. Ideal para desarrolladores familiarizados con el marcado de bloques.
Temas clásicos con constructor de páginas: Temas como Astra o GeneratePress combinados con Elementor o Bricks Builder ofrecen el equivalente más cercano al Layout Builder de Drupal.
Tema hijo personalizado: Si su sitio Drupal tenía un diseño muy personalizado, cree un tema hijo basado en un tema padre minimalista (Underscores, Blocksy) y replique el CSS.

Reconstrucción de menús de navegación
Los menús de Drupal no se migran automáticamente. Reconstruyalos en Apariencia > Menús (temas clásicos) o en el bloque de Navegación del Editor de sitio (temas FSE). Consulte la estructura de menús de Drupal:
drush eval "print_r(menu_tree_all_data('main', NULL));"
O consulte la base de datos directamente:
SELECT ml.link_path, ml.link_title, ml.weight, ml.depth
FROM menu_links ml
WHERE ml.menu_name = 'main-menu' AND ml.hidden = 0
ORDER BY ml.weight;
Widgets y bloques
Los bloques de Drupal se corresponden aproximadamente con los widgets y bloques de Gutenberg de WordPress. Reconstruya las regiones de barra lateral y pie de página en Apariencia > Widgets o directamente en el Editor de sitio. Los tipos de bloque personalizados de Drupal con lógica PHP deberán reconstruirse como shortcodes o bloques personalizados de WordPress.
Paso 8: Auditoría de contenido posterior a la migración
No omita esta fase. Las herramientas de migración automatizada gestionan bien el contenido estructurado, pero fallan silenciosamente en casos extremos.
Verificaciones de integridad del contenido

Medios incrustados: Las referencias de archivos en línea de Drupal usan un formato de token personalizado ([file:123] o <drupal-media uuid="..."/>). Estos no se renderizarán en WordPress. Busque estos tokens en la base de datos:

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%drupal-media%' OR post_content LIKE '%[file:%';

Shortcodes y Views: Las Views de Drupal no tienen equivalente en WordPress. Cualquier página que renderizara una View (p. ej., un listado de contenido filtrado) quedará en blanco. Reconstruyalas usando WP_Query, archivos de tipos de publicación personalizados o un plugin como Posts Table Pro.


Campos personalizados: Los datos de campos de Drupal migrados mediante el plugin Premium se almacenan en wp_postmeta. Verifique que los valores de los campos estén presentes:

SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_key LIKE 'field_%' LIMIT 50;

Cuentas de usuario: Si migró usuarios, verifique la asignación de roles. El rol authenticated user de Drupal se asigna al rol Subscriber de WordPress. El rol editor de Drupal se asigna al rol Editor de WordPress. El rol administrator de Drupal se asigna al rol Administrator de WordPress. Audite la asignación y ajústela según sea necesario.

Detección de enlaces rotos
Instale Broken Link Checker o realice un rastreo con Screaming Frog en su entorno de pruebas antes del cambio de DNS. Corrija todos los errores 404 internos antes de publicar; no confíe en la monitorización posterior al lanzamiento para detectarlos.
Paso 9: Optimización del rendimiento y seguridad
Un sitio WordPress recién migrado necesita ser reforzado antes de estar listo para producción.
Configuración de caché
Instale LiteSpeed Cache (si está en un servidor LiteSpeed) o W3 Total Cache / WP Rocket para entornos Apache/Nginx. Configure:

Caché de página con un TTL de al menos 3600 segundos para páginas estáticas
Caché de objetos respaldada por Redis o Memcached
Cabeceras de caché del navegador mediante .htaccess o configuración del servidor

SSL/HTTPS
Asegúrese de que su sitio WordPress se sirva exclusivamente mediante HTTPS. Si aún no tiene un certificado, los Certificados SSL pueden aprovisionarse rápidamente y configurarse para renovarse automáticamente. Actualice los ajustes de URL del sitio en WordPress:
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'
Fuerce HTTPS en .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Lista de verificación de seguridad

Deshabilite XML-RPC si no es necesario: añada add_filter('xmlrpc_enabled', '__return_false'); a functions.php

find /var/www/html/wordpress -type d -exec chmod 755 {} ;
find /var/www/html/wordpress -type f -exec chmod 644 {} ;
chmod 600 /var/www/html/wordpress/wp-config.php

Paso 10: Cambio de DNS y lanzamiento

Realice el cambio de DNS durante su ventana de menor tráfico. El proceso debería llevar menos de 15 minutos de trabajo real, con una ventana de propagación de hasta 48 horas (normalmente entre 1 y 4 horas para la mayoría de los resolvers).

Verificaciones finales antes del cambio

• Realice un rastreo completo de la URL de pruebas y confirme que no hay errores 404
• Verifique que todas las redirecciones 301 devuelvan las cabeceras Location correctas
• Pruebe los formularios de contacto, la funcionalidad de búsqueda y cualquier flujo de comercio electrónico
• Confirme que Google Search Console está verificado en el nuevo sitio
• Genere y envíe un nuevo sitemap XML mediante Yoast SEO o Rank Math

Proceso de actualización de DNS

Si registró su dominio a través de Registro de dominios, actualice el registro A directamente en el panel de gestión de DNS. Reduzca el TTL a 300 segundos al menos 24 horas antes del cambio para minimizar el retraso de propagación.

A record: yourdomain.com → [new WordPress server IP]
TTL: 300 (pre-cutover), restore to 3600 post-cutover

Monitorización posterior al lanzamiento

• Active la herramienta de cambio de dirección de Google Search Console si el propio dominio ha cambiado
• Monitorice los Core Web Vitals en Search Console durante los primeros 30 días; espere una fluctuación temporal en el posicionamiento mientras Google vuelve a rastrear e indexar
• Configure UptimeRobot o equivalente para la monitorización de disponibilidad
• Revise los registros de errores del servidor diariamente durante la primera semana:

tail -f /var/log/apache2/error.log
# or for Nginx:
tail -f /var/log/nginx/error.log

Reenvío a motores de búsqueda

Envíe su sitemap actualizado en Google Search Console:

1. Vaya a Search Console > Sitemaps
2. Introduzca sitemap.xml (o sitemap_index.xml para sitios grandes)
3. Haga clic en Enviar

Envíe también a Bing Webmaster Tools y verifique el sitio de forma independiente allí; el índice de Bing es utilizado por varios motores de búsqueda de IA, incluido Copilot.

Recomendaciones de infraestructura de alojamiento

El rendimiento de su sitio WordPress migrado depende en gran medida de la infraestructura subyacente. Una migración de Drupal a WordPress es el momento ideal para modernizar también su stack de alojamiento.

Para sitios con tráfico moderado (entre 10.000 y 100.000 visitas mensuales), un plan de Hosting VPS con al menos 2 vCPUs, 4 GB RAM y almacenamiento NVMe proporciona margen suficiente para WordPress con caché de página completa. Para sitios de alto tráfico o con uso intensivo de recursos, los Servidores dedicados eliminan por completo el problema del vecino ruidoso y le dan control total sobre los parámetros del kernel, la configuración de MySQL y el ajuste de la pila de red.

Si gestiona múltiples sitios de clientes o prefiere una experiencia de gestión de servidor basada en GUI, los Paneles de control VPS ofrecen una variedad de opciones que incluyen cPanel, Plesk y DirectAdmin, cada uno con soporte para la gestión de WordPress multisitio, copias de seguridad automatizadas y aprovisionamiento de SSL desde una única interfaz.

Matriz de decisión técnica: cuándo usar cada enfoque de migración

Conclusiones técnicas clave

• Haga una copia de seguridad antes que nada. Un volcado SQL comprimido y un tarball de sites/default/files/ son su red de seguridad. Verifique que ambos estén completos y sean restaurables antes de comenzar.
• Pruebe la conectividad de la base de datos antes de ejecutar el importador. La mayoría de las migraciones fallidas se detienen en la prueba de conexión debido a reglas de firewall o permisos SELECT faltantes.
• El contenido de Drupal basado en párrafos requiere el plugin Premium. La versión gratuita omitirá silenciosamente los campos de párrafos, dejando el contenido incompleto sin ningún mensaje de error.
• Las redirecciones 301 no son opcionales. Cada URL de Drupal que tenga enlaces externos o indexación en motores de búsqueda debe redirigir a su equivalente en WordPress con un 301 permanente. Una redirección faltante es una señal de posicionamiento perdida.
• Reduzca el TTL de DNS 24 horas antes del cambio. Configúrelo a 300 segundos para que la propagación se complete en minutos, no en horas, cuando cambie el registro A.
• Audite wp_postmeta para detectar campos de Drupal sin asignar. Los datos de campos personalizados se almacenan allí tras la importación; verifique que estén presentes y correctamente identificados antes de desmantelar la instancia de Drupal.
• No desmantle Drupal inmediatamente. Mantenga el entorno Drupal en funcionamiento (en modo de mantenimiento, no accesible públicamente) durante al menos 30 días tras el lanzamiento como referencia y opción de reversión.
• Reenvíe su sitemap el mismo día que publique. No espere a que Googlebot descubra la nueva estructura de forma orgánica; el envío activo acelera el nuevo rastreo.

Preguntas frecuentes

¿Puedo migrar una instalación multisitio de Drupal a WordPress?

Sí, pero cada subsitio de Drupal debe migrarse individualmente. El plugin FG Drupal to WordPress no gestiona de forma nativa el multisitio de Drupal en un solo proceso. Ejecute una importación separada para cada subsitio, apuntando a una red WordPress Multisite o a instalaciones independientes de WordPress según su arquitectura.

¿Se transferirán las contraseñas de los usuarios de Drupal a WordPress?

No. Drupal usa un hash SHA-512 con sal (o bcrypt en versiones más recientes) que es incompatible con el hash basado en phpass de WordPress. El plugin FG Premium migra las cuentas de usuario pero restablece las contraseñas, enviando un correo electrónico de restablecimiento a cada usuario. Planifique la comunicación con los usuarios en consecuencia.

¿Cómo gestiono los tipos de contenido de Drupal sin equivalente en WordPress?

Registre los Tipos de Publicación Personalizados (CPTs) equivalentes en WordPress antes de ejecutar la importación. El plugin FG Premium le permite asignar tipos de contenido de Drupal a CPTs de WordPress. Sin esta asignación, todos los nodos se asignan por defecto al tipo de publicación post, colapsando su taxonomía de contenido.

¿Qué ocurre con los términos de taxonomía de Drupal durante la migración?

Los vocabularios de Drupal se asignan a las taxonomías de WordPress. La asignación predeterminada convierte las tags de Drupal en etiquetas de WordPress y las categories de Drupal en categorías de WordPress. Los vocabularios personalizados requieren el registro manual de la taxonomía en WordPress antes de la importación, o serán descartados.

¿Cuánto tiempo lleva la migración de un sitio Drupal grande?

Para un sitio con 5.000 nodos y 2 GB de medios, espere entre 2 y 4 horas de tiempo de importación en un servidor bien equipado, más entre 4 y 8 horas de auditoría de contenido posterior a la migración y configuración de redirecciones. El cambio de DNS real lleva menos de 15 minutos. El tiempo total transcurrido desde el inicio hasta la publicación es normalmente de uno a dos días laborables para una migración exhaustiva y de calidad para producción.