Migrar un sitio de Drupal a WordPress con un profesional

Cómo migrar un sitio web de Drupal a WordPress con un profesional independiente: plan para trasladar el contenido y las funciones

Migrar de Drupal a WordPress no consiste simplemente en transferir páginas. Los sitios de Drupal suelen depender de tipos de contenido, taxonomías, campos, permisos y módulos que no tienen un equivalente directo en WordPress. Si se pasan por alto estos detalles, el nuevo sitio puede parecer terminado mientras fallan los filtros de búsqueda, desaparecen las atribuciones de autoría o los archivos multimedia quedan desvinculados de su contenido.

Un profesional independiente puede encargarse del trabajo, pero el proyecto también requiere que el propietario del sitio tome decisiones claras. Antes de preguntarte cómo migrar un sitio de Drupal a WordPress con un profesional independiente, prepara un inventario del contenido, identifica las funciones que realmente se utilizan y acuerda cómo deberían diferir ambos sistemas después del lanzamiento. Así tendrás un plan verificable para la migración, en lugar de una instrucción imprecisa como «trasládalo todo».

1. Asigna los tipos de contenido de Drupal a las estructuras de WordPress

Empieza por enumerar los tipos de contenido de Drupal y los campos asociados a cada uno. Un artículo de noticias puede incluir título, resumen, cuerpo, autor, fecha de publicación, tema e imagen principal. Una página de producto puede tener campos distintos y estar relacionada con una categoría o un proveedor. El profesional independiente necesita este inventario antes de elegir las estructuras de WordPress, ya que es una parte esencial de la migración de contenido y funciones de Drupal a WordPress.

Los nodos de Drupal pueden corresponder a entradas o páginas estándar de WordPress, pero algunos contenidos merecen un tipo de contenido personalizado. Por ejemplo, suele ser más claro crear un tipo de contenido «Organización» para un directorio de organizaciones con su propio archivo y campos de perfil que usar una colección de páginas comunes. Según cómo se utilicen, las taxonomías pueden convertirse en categorías de WordPress o en taxonomías personalizadas. Una tabla de correspondencias campo por campo permite dejar claras estas decisiones.

No des por hecho que dos campos con el mismo nombre funcionan igual. Un campo de Drupal que permite varios valores puede requerir una configuración distinta en WordPress a la de uno que almacena un único valor. Además, puede ser necesario definir explícitamente cómo convertir una fecha almacenada con zona horaria. Registra ejemplos de valores poco habituales para que el profesional independiente pueda probarlos en vez de hacer suposiciones.

Incluye también las URL en la tabla de correspondencias. Si un artículo de Drupal está en /news/community-update, decide si WordPress conservará esa ruta o la redirigirá a otra nueva. Una hoja de cálculo con el tipo de contenido de origen, la estructura de destino, los campos, las reglas de taxonomía y el tratamiento de las URL servirá de referencia para ambas partes durante las pruebas.

2. Decide qué reconstruir, sustituir o dejar atrás

Los módulos de Drupal suelen respaldar flujos de trabajo específicos, y no basta con copiar la función visible si también importa el proceso que hay detrás. Haz una lista de los módulos y las funciones personalizadas que utiliza actualmente el sitio e indica quién depende de cada uno. El inicio de sesión de los miembros, una cola de aprobación editorial y una búsqueda por facetas pueden requerir tres soluciones distintas en WordPress.

Clasifica cada elemento en uno de estos tres grupos: reconstruir en WordPress, sustituir por una herramienta disponible o dejar atrás. Por ejemplo, quizá no haga falta trasladar un calendario de eventos antiguo si no hay eventos próximos. Un directorio público que todavía se consulta a diario podría necesitar una alternativa con campos de búsqueda. Si la nueva configuración editorial no puede reproducir los pasos necesarios de un proceso de aprobación personalizado, puede que haya que desarrollarlo.

Pide al profesional independiente que describa la solución propuesta y sus limitaciones para cada función que se vaya a conservar. Si una alternativa cambia quién puede editar el contenido o cómo lo encuentra un visitante, documenta ese cambio antes de empezar el desarrollo. «Funciona como Drupal» no es un criterio de aceptación útil; «los editores pueden enviar un artículo a revisión sin publicarlo» sí lo es.

Distingue las funciones imprescindibles de las preferencias. Esto ayuda a controlar el alcance cuando un módulo de Drupal no tiene un equivalente directo y permite al propietario aprobar un proceso más sencillo. Si el proyecto requiere conocimientos especializados, puede ser conveniente contratar un profesional para migrar Drupal a WordPress. Para saber más sobre cómo elegir entre un profesional independiente y un equipo, consulta ¿debería contratar a un profesional independiente?.

3. Prepara una muestra representativa para la migración

Antes de trasladar toda la base de datos, pide al profesional independiente que migre una muestra pequeña que incluya distintos tipos de contenido. Una página básica permite probar los campos sencillos y las URL. Un artículo con muchas taxonomías sirve para comprobar las asignaciones de términos y la jerarquía. Un elemento con mucho contenido multimedia permite verificar los archivos de imagen, los pies de foto y el contenido incrustado. Si el sitio tiene un tipo de contenido especial, incluye al menos un ejemplo.

La muestra debe ser lo bastante amplia para revelar distintos casos, pero lo bastante pequeña como para que el propietario o un editor pueda revisar cada registro. Acordad qué elementos del sitio de origen se utilizarán y qué se considerará «correcto» en cada caso. Por ejemplo, puede que el artículo de muestra deba conservar el autor original, dos términos temáticos, una fecha de actualización y un archivo adjunto descargable.

Compara el resultado en WordPress con el original de Drupal, no solo con una maqueta de diseño. Comprueba si el contenido se puede editar, si los filtros de taxonomía devuelven los elementos esperados y si los archivos multimedia aparecen donde corresponde. Una página puede verse bien aunque falten sus términos en la base de datos. Corregir la asignación después de revisar una muestra cuesta mucho menos que descubrir el mismo error en miles de registros.

Pide al profesional independiente que registre los problemas detectados en la muestra y los cambios correspondientes en la tabla de asignaciones. Ese registro será la primera versión de las notas de migración y evitará que una entrega posterior dependa de la memoria de alguien.

4. Define las reglas para depurar el contenido y coordinar la entrega editorial

La migración no es un buen momento para tomar decisiones editoriales sin documentarlas. Acordad de antemano qué hacer con los borradores obsoletos, las páginas duplicadas, los valores de campos no compatibles y el contenido marcado para revisión. Una regla práctica podría ser migrar por defecto el contenido publicado y mantener los borradores en una lista de revisión aparte; la opción concreta dependerá del proceso de publicación del sitio.

Debe quedar claro quién decide qué hacer con los duplicados. El profesional independiente puede señalar registros con títulos o URL coincidentes, pero un editor debería decidir si se combinan, se eliminan o se conservan. Si dos páginas de Drupal contienen información distinta pese a tener títulos parecidos, una depuración automática podría eliminar contenido útil. Lleva un registro de decisiones con la URL de origen, la acción elegida y el editor responsable.

Define también cómo gestionar el contenido multimedia incrustado. Algunos contenidos de Drupal pueden hacer referencia a archivos almacenados en una ubicación antigua o incluir un vídeo mediante el código de un proveedor que ya no se utiliza. Decide si el profesional independiente debe copiar el archivo, sustituir el contenido incrustado o marcarlo para revisión editorial. Los valores de campos no compatibles deben notificarse, no descartarse silenciosamente: un dato que falte podría afectar a un producto, un perfil o un aviso legal.

Acordad quién revisará el contenido migrado y cómo se gestionarán las excepciones. Por ejemplo, el profesional independiente puede preparar una hoja de cálculo con los registros a los que les faltan imágenes, y el editor aportar los reemplazos antes del lanzamiento. Una entrega bien definida mantiene separado el trabajo técnico de migración de la aprobación editorial.

5. Valida los datos migrados más allá de su apariencia

La revisión visual permite detectar problemas de diseño, pero no confirma que todos los campos y relaciones se hayan trasladado correctamente. Compara los registros de Drupal y WordPress en cuanto a títulos, texto, valores de campos, asignaciones de taxonomía, autoría, marcas de tiempo y asociaciones con archivos multimedia. Elige comprobaciones que reflejen el modelo de contenido del sitio en vez de limitarte a revisar la página de inicio.

Cuando sea posible, usa exportaciones o consultas a la base de datos para comparar el número de registros y algunos campos. Si se van a incluir 240 eventos de Drupal, el informe de migración debe dar cuenta de los registros de destino o enumerar las exclusiones específicas; no des por sentado que las cifras coinciden sin comprobarlo. Si aún no se conoce el total definitivo, déjalo pendiente de verificación en lugar de inventar una cifra objetivo.

Comprueba también las relaciones en la interfaz de WordPress. Abre el archivo de una taxonomía y confirma que aparezca allí un artículo asignado a uno de sus términos. Revisa el archivo de autor si la autoría sirve para navegar por el sitio. Abre varios elementos con mucho contenido multimedia y confirma que las imágenes o los archivos adjuntos estén asociados a los registros correctos, no solo que existan en algún lugar de la biblioteca multimedia.

Documenta las excepciones con suficientes detalles para poder resolverlas: identificador de origen, URL de destino, problema, responsable y estado. Una nota como «algunas imágenes están mal» es difícil de gestionar. En cambio, indicar el artículo afectado y la imagen que falta da al profesional independiente y al editor una tarea concreta.

6. Planifica la puesta en marcha teniendo en cuenta los cambios en el contenido

Es posible que el contenido siga cambiando mientras el profesional independiente desarrolla WordPress. Decide si habrá una pausa en las publicaciones o un proceso para transferir los cambios finales antes de empezar la migración. Si se opta por una pausa, los editores dejarán de publicar en Drupal durante un periodo acordado mientras se realiza la transferencia final y las comprobaciones. Si se elige un proceso de cambios finales, el profesional independiente importará primero el contenido inicial y, después, trasladará los registros creados o modificados desde entonces.

Es más sencillo explicar una pausa, pero puede interrumpir el trabajo de una redacción o una organización con mucha actividad. El proceso de cambios finales permite seguir publicando, aunque requiere una manera fiable de identificar los registros modificados y evitar duplicados. Pregunta quién hará el seguimiento de los cambios, cuándo se realizará la última importación y cómo se comprobarán las actualizaciones durante la puesta en marcha.

Prepara una lista de verificación para el lanzamiento con condiciones concretas: importación final completada, páginas prioritarias revisadas, redirecciones probadas, formularios enviados correctamente y responsables del contenido informados. Si falla un elemento crítico, define si se aplazará el lanzamiento o si hay una solución alternativa aprobada. La decisión debe tomarse antes de que llegue la presión del día del lanzamiento.

7. Cierra los accesos, la documentación y los preparativos para una reversión

Al finalizar el trabajo, confirma que el profesional independiente haya entregado los scripts de migración, la tabla de asignaciones de campos, el registro de excepciones y las instrucciones para ejecutar cualquier importación final. Pide notas sobre los tipos de contenido personalizados, las taxonomías, las tareas programadas y los pasos manuales que pueda necesitar quien se encargue del mantenimiento en el futuro. Sin instrucciones, puede resultar difícil volver a usar un script cuando haya que corregir algo meses después.

Revisa también los accesos a las cuentas. Elimina las cuentas temporales o reduce los permisos que ya no sean necesarios, y cambia las credenciales si se compartieron durante la migración. Designa a una persona responsable de la administración de WordPress para que el sitio no dependa de la cuenta personal de un antiguo contratista.

Estar preparado para revertir los cambios significa conservar una copia de Drupal que se pueda restaurar y saber quién puede hacerlo si el nuevo sitio tiene un problema grave al publicarse. Acordad dónde se guardará la copia de seguridad, quién se encargará de restaurarla y qué situaciones justificarían una reversión. No elimines el sitio antiguo solo porque WordPress ya esté en funcionamiento; consérvalo hasta que se completen las comprobaciones acordadas y el equipo confirme que el contenido y los procesos importantes funcionan como se espera.