Migrando de Drupal 6 a Drupal 7

En este post intento recopilar tanto la experiencia en grandes migraciones que se han realizado desde La Drupalera, como la recopilación de información interna y externa de expertos como Mike Ryan (desarrollador desde 2003 y primer autor del módulo migrate) o grandes empresas Drupal como Acquia o Phase2. No existe mucha información recopilada en castellano y espero que al menos sea útil de cara a la toma de decisiones desde un plan algo menos técnico y respondiendo a varias preguntas que entendemos clave. En la siguiente figura vemos la tendencia clara de uso del Core por versión con datos actualizados hasta el pasado 7 de Diciembre. Claramente D7 crece en oposición a D6. 

¿Está en riesgo nuestro portal si está basado en Drupal 6?

Evidentemente Drupal 8 está a punto de hacerse oficial (lleva ya meses haciéndolo) y eso hará que se deje de dar soporte oficial a dos versiones anteriores a la última release. En este caso Drupal 6. Esto significa que no se recibirán updates e importantes parches de seguridad por lo que el sitio puede quedar vulnerable a hackers. Por ejemplo, ante un problema tan crítico como el que ocurrió el 15 de Octubre de este mismo año, los sitios con Drupal 6 quedarían desprotegidos del soporte oficial. El cliente sería totalmente dependiente de proveedores concretos y de la pericia de los mismos para resolver el problema en el mejor de los casos. 

Lo anterior es una realidad pero no la única.  Existen casi 200.000 sitios web (20% del total) en Drupal 6, incluyendo algunos de especial relevancia. Por tanto,  la comunidad de forma coherente, está planteando seguir ofreciendo soporte unos meses más pasada la fecha de lanzamiento de la versión 8.0.0. release. Algunos enlaces relacionados con este tema: 

• Drupal 6 extended support announcement

• Looking for Drupal 6 security maintainers

Desde La Drupalera, estaremos atentos, sin duda, a la metodología y el tiempo que ofrezca el Equipo de Seguridad Drupal para que empresas como la nuestra puedan compartir parches de seguridad aplicados a nuestros propios clientes. Sin embargo y desgraciadamente, no tendrán el rigor (review, test) de otros parches de D7 y D8. Como conclusión, si se posee un sitio web de cierta criticidad, nuestra respuesta sería que sí se corre cierto riesgo al seguir un RoadMap con Drupal 6. No obstante, existen muchas medidas y hay tiempo para tomarlas. Nuestra recomendación en este punto: 

1. Atar contractualmente con el proveedor un mecanismo de mantenimiento y soporte especializado sobre algo que la comunidad no cubre.

2. Estudiar el impacto que tendría una migración a Drupal 7 de mi sitio web. Siempre desde el rigor que requiere este tipo de estudios.

¿Las razones que tengo para migrar justifican los costes?

Se trata de una pregunta que hay que desgranar. Migrar es dinero y el no hacerlo puede hacer que exista un problema de seguridad. Sin embargo, con un buen equipo de mantenimiento/soporte experto se puede seguir cierto tiempo o simplemente el necesario para cumplir con los objetivos de negocio del site. Pero cuidado,  este equipo también tiene un coste evidentemente. Es recomendable, por tanto, plantearse en un momento como éste otras preguntas que si no hablan explícitamente de una migración, si están relacionadas y pueden aumentar las razones que justifiquen los costes de la migración. Por ejemplo: 

• ¿Tengo otros evolutivos o cambios en la cabeza para mi sitio?
• Voy a cambiar el diseño porque quiero que sea Responsivo.
• Quiero cambiar mi sitio a multilenguaje (mucho mejor tratado en Drupal 7).
• Hay secciones que quiero eliminar porque no funcionan o no generan negocio.

Son preguntas ejemplo pero algunas de estas cuestiones sí puede acelerar la opción de migrar, ya que Drupal 7 ofrece  muchas ventajas  a nivel de seguridad, usabilidad, multilenguaje, movilidad y performance entre otras. Es decir, la primera razón de peso puede ser cazar las propias ventajas de Drupal 7 en un momento donde la migración es una recomendación por motivos de base como seguridad, actualizaciones, etc. 

Por otro lado, aunque creamos que estamos bien con nuestra funcionalidad actual y no queremos muchos cambios, migrar es casi una necesidad si nuestro plan para el site va algo más allá del corto plazo. ¿Por qué migramos nuestro escritorio Ubuntu aunque nos funcione el actual?  ¿Por qué actualizamos el navegador? La razones son las mismas que en el caso de Drupal. El esfuerzo de fuerza/desarrollo/capacidad/etc. está entre la release X y la X-1. La X-2 apenas recibe nada. Hay una gráfica muy explícita para ello: 

La fuente de la imagen es de un artículo de gran interés, donde también existe un argumentario y recomendaciones que complementan este post. 

Es decir, no sólo Drupal 6 dejará de tener soporte, dejará de haber soporte para los módulos de terceros, themes, etc. Además cualquier servicio que aparezca en el mapa de Internet y sea crítico para un sitio web (autenticación, social media, etc.) no estará en casi ningún caso integrado en Drupal 6. Por último, si tenemos módulos en Drupal 6 que utilicen o integren servicios externos (como servicios REST) no habrá comunidad que lleve los cambios al módulo y este dejará previsiblmente de funcionar. A nivel económico por tanto, si el Roadmap de nuestro site tiene algo de recorrido, el mantenimiento será mucho más costoso.  

Por tanto la sostenibilidad a nivel funcional y económico es una segunda gran razón si nuestro sitio tiene algo de recorrido en el tiempo. 

¿Por qué no plantear migrar a Drupal 8 ya?

Sería una de las alternativas pasar directamente a Drupal 8 desde Drupal 6, aspecto en el que la comunidad está trabajando fuerte. Pero a día de hoy, no tenemos una versión estable y cuando la tengamos muchos de los módulos más populares no estarán todavía soportados. Bajo mi punto de vista, no veo todavía que sea la mejor opción. 

¿Cuánto cuesta migrar de Drupal 6 a Drupal 7?

Si nos hacemos esa pregunta ya hemos decidido, al menos, estudiar la viabilidad de la migración (coste/esfuerzo/prestaciones). Ya hemos evaluado el RoadMap del sitio actualmente en Drupal 6, y decidido el paso a migrar a Drupal 7.  ¿Cuánto cuesta?.

Ya hemos dicho que no hay respuesta directa. Lo más importante es saber dónde está el valor actual de lo que el cliente quiere migrar. En esta línea, tiene importancia incluso si se estaba planteando un gran evolutivo, o cambiar todo el frontend a Responsive Design. Es decir, en este punto todavía ni siquiera sabemos si es mejor migrar o plantear un upgrade, y ni tan siquiera si son viables. Quizás el valor esté en el contenido y es mejor partir de cero aprovechando todo lo que ofrece de base Drupal 7.

El plan de migración a planificar no será más que un plan de transición de éxito de un escenario origen a uno destino. Esto lo aprendimos bien en la organización en los más de 10 años migrando escritorios Windows a Linux donde hay que atender los problemas técnicos, pero por encima de todo, el soporte, la formación o la gestión del cambio. En un entorno online no se puede aplicar la misma metodología, pero nos ha servido para plantear muchas de las migraciones que hemos ido haciendo.

Primera incógnita a trabajar: Escenario origen 

No se puede plantear una migración, averiguar su viabilidad o su coste, sin preguntarnos dónde está nuestro sitio. Para ello utilizaremos plantillas de auditoría cuya salida nos dará realmente la respuesta parcial o algo más aproximada a la complejidad, precio y estrategia de migración.

Auditoría negocio	Áreas involucradas: Negocio/Marketing/CEO
Auditoría funcional	Áreas involucradas: Usuario (Áreas funcionales)
Auditoría técnica	Departamento TI, proveedor anterior.

A continuación vemos únicamente una muestra de estas tablas a trabajar de forma sencilla con el cliente o de forma autónoma accediendo al sistema.

Auditoría de negocio

¿El sitio cumple los objetivos de negocio? ¿Se mide?
¿Qué contenidos son críticos?
¿Qué secciones son críticas?
¿El diseño representa realmente nuestro branding o está defasado?
¿El sitio cubre los dispositivos target del negocio (mobile, tablet por ejemplo)?

Auditoría funcional

¿Que satisfacción existen en la creación de contenidos, workflows, publicación?
Experiencia del uso
Taxonomías
Uso de fuentes externas de información
Matriz de permisos
Reglas y disparadores
AI
Contenido multimedia

Auditoría técnica

Proveedor desarrollo
Número de nodos, vistas
Número de usuarios, roles
Número de Módulos contribuidos y estado
¿Existe código PHP en BD?
Estado del core
Calidad y customización de los Themes
Número Módulos custom
LIbrerías JS
Arquitectura, performance (varnish, PressFlow, memcache, etc.)
Código PHP custom
Búsquedas (Solr?, Interna?)
Sistema de ficheros y BBDD

Son sólo alguna cuestiones ejemplo. Con esta información de auditoría, que se obtendría de manera ágil con pocas reuniones, la colaboración del proveedor y/o con un análisis rápido, se puede tener una primera idea sobre dos preguntas:

Segunda incógnita a trabajar: Escenario destino

Efectivamente, si vamos a realizar una migración, el escenario destino para el cliente suele abrirse a los requisitos clásicos de un proyecto nuevo, pero cuidado: el presupuesto y el tiempo no son infinitos y ahora debemos tener en cuenta la migración. Cuando hablamos de migrar, hablamos de mover los datos y contenidos de un sitio a otro, donde otro significa un nuevo sitio. Tenemos tres grandes participantes:

1. Cliente que define el contenido, datos, ficheros, configuraciones a migrar.
2. El equipo de desarrollo que crea la funcionalidad, diseño y temas del nuevo sitio.
3. El equipo de migración que desarrolla el proceso de migración de un sitio a otro.

Es importante saber que el proceso de migración debe hacerse en paralelo al de desarrollo. El diseño de los tipos de contenido, el diseño de la gestión de usuarios, los ficheros o incluso el front-end, no deben constituir una secuencia y debe haber una relación directa entre ambos equipos desde el principio del proyecto. La migración en si misma será el penúltimo proceso antes del paso a producción, siendo el último los preparativos finales de pruebas de carga funcionales y de carga,

Por tanto, los requisitos del Escenario Destino se verán afectados por la migración exigida al proyecto. De cara a este escenario se recomienda, además:

• Volver a la auditoría anterior y repasar las preguntas funcionales y de negocio sobre el site actual para tenerlo en cuenta en el diseño del nuevo.

• Potenciar los puntos fuertes y mejoras de Drupal 7 a nivel de prestaciones y funcionalidad. Muchas veces no se aprovecha el CMS porque no se enseña al cliente antes de empezar a desarrollar. Otras veces es porque no nos paramos a pensar lo que necesita el cliente sino lo que está pidiendo.

De esta forma, se establecerá un escenario destino coherente económicamente, adaptado a un proceso de migración y no a un desarrollo desde cero y fundamentalmente que cumpla las expectativas del cliente. Que para eso estamos haciendo una migración ;).

Por último: Plan de migración

Con el escenario origen claro se puede hacer una estimación muy certera de un plan de migración. Con el escenario destino también cerrado evidentemente lo tendríamos completo. Ahora sólo queda definir los pasos del plan de migración de contenidos que básicamente se basan en analizar, mapear (módulo migrate), iterar (testear, refinar, repetir) y lanzar.

El proceso de análisis es un proceso completo y bottom-up (el diseño por ejemplo es top-down trabajando desde el front-end). Aquí nosotros debemos partir de un trabajo minucioso de cada tabla de la base de datos, desde abajo. Por el ejemplo, el workflow no se ve en el diseño.

En el proceso de mapeo es importante el módulo migrate que nos ayuda sin duda a no ir de origen a destino a base de scripts.

• https://www.drupal.org/project/migrate (APIs, UI, Ejemplo, documentación)

• https://www.drupal.org/project/backup_migrate (incluye las utilidades para migración de ficheros).

Sin duda, esto ya es materia de un post más técnico y existe, además, mucha documentación en drupal.org sobre herramientas y utilidades. Con Escenario origen y destino claros, son el medio perfecto para un plan de migración de éxito.

Para terminar, un ejemplo muy concreto accesible desde Internet es el caso de Idealista, que en la DrupalCamp Spain de Valencia 2014 nos explicaron realmente como hacer un nuevo portal de noticias en Drupal 7 migrando y adaptando 14 años de contenidos y comentarios en Drupal 6: http://2014.drupalcamp.es/reconstruir-y-migrar-un-medio-digital-idealistanews