Cómo migrar bien de un CMS a otro

Últimamente no dejo de escuchar historias de auténtico terror, narraciones que pondrían los pelos de punta a cualquiera. Todas ellas giran en torno a la migración de un CMS a otro. Muy pocas tienen final feliz y los lloros y lamentos resuenan por los pasillos de las redacciones de los periódicos digitales a altas horas de la mañana por la caída en audiencia.

En ocasiones, cuando charlo con clientes, hablan de migrar y de volverse al anterior CMS con una alegría y despreocupación que me hiela la sangre. ¿Cómo puede ser que yo me lo piense dos veces para redireccionar una sola página y esta gente haga migraciones como el que baja a comprar leche?

No son pocas las migraciones que han llegado a mi conocimiento y que han acabado con dimisiones. Hablo, por poner dos ejemplos recientes, de la migración de El País a Arc XP con la que se desplomaron en Comscore, o la reciente de Vozpópuli. Lo cierto es que pocas veces han llegado a mis oídos migraciones que hayan resultado en aumento de tráfico.

¿Cómo es esto posible? Pues por muchas razones. En primer lugar, las migraciones son procesos informáticos tediosos y complejos, que a menudo son tan odiados por periodistas como por los ingenieros informáticos (y creedme que pocas veces coinciden estos dos grupos en algo).

Y ojo, porque un error en un solo paso de la migración (preparación, ejecución y verificación) puede conducir al proyecto editorial al abismo.

Una mala migración también puede hacer que cualquier gran CMS parezca el mismo diablo. Lo que en realidad es una migración nefasta a menudo se confunde con un mal CMS; muchos de mis clientes caen en este equívoco con extrema facilidad. Y, por otro lado, una migración bien hecha habitualmente es un proceso largo, complejo, tedioso y no exento de riesgo, algo de lo que habitualmente tampoco son conscientes en líneas generales.

En cualquier caso, siempre hay que migrar por razones positivas, en mi opinión no hay que migrar si nos fuerzan a ello, o para resolver problemas de SEO o por motivos similares. A veces el coste de migrar es tan grande que incluso hay proyectos en los que se decide no migrar. E incluso es recomendable cuando se realiza una migración de un CMS a otro tener un plan de contingencia para volver atrás rápidamente, para abortar la misión si fuera necesario.

Aunque hay migraciones sencillas, porque los CMS de origen y destino son de código libre y bien conocidos, como una migración de Blogger a WordPress, o de WordPress a Drupal, lo cierto es que es muy habitual que los CMS de origen y destino se parezcan muy poco y de ahí la dificultad. Además, es bastante común que además se aproveche para realizar conseguir nuevas características o realizar mejoras incluso en la taxonomía, de forma que esto añade complejidad a la acción de migrar.

La casuística es prácticamente ilimitada, y en muchas ocasiones, el tiempo y los recursos para migrar suelen ser bastante limitados. Puede suceder que se aproveche para desechar contenidos y limpiar el servidor, aunque esto no es muy común en medios de comunicación. A veces hay contenido que se queda huérfano porque no existe en el CMS de destino y entonces redireccionar es complicado, y de ahí pérdidas de tráfico y, por tanto, dinero.

En el caso de medios de comunicación, la migración es especialmente compleja por la cantidad y variedad de contenidos, y que estos a su vez suelen tener gran cantidad de elementos embebidos, y esto hace que la migración deba ser automática

En el caso de medios de comunicación, la migración es especialmente compleja por la cantidad y variedad de contenidos, y que estos a su vez suelen tener gran cantidad de elementos embebidos, y esto hace que la migración deba ser automática. En estas migraciones se suele realizar un script de migración, que debe ser bien afinado, y luego verificar manualmente los resultados, algo que no siempre se hace con la debida presteza y eficacia.

Por si todo esto no fuera suficientemente complicado, puedo añadir a la ecuación a los periodistas. En ocasiones éstos trabajan en el CMS antes de la migración para reducir los errores en origen, pero no es lo habitual; lo más habitual es que éstos sean ignorados incluso en la fase de lanzamiento, cuando hay “freeze” editorial, en el que, si la sincronización no es buena, incluso se pueden perder contenidos. Después del lanzamiento, éstos también deben ser involucrados para afinar los resultados y encontrar errores gracias a su criterio editorial.

Añadamos aún más complejidad al asunto: no solo hay que migrar los artículos, sino los vídeos, metas, autores, tags y un larguísimo etcétera. Esto incluye las redirecciones, ya que incluso podemos volver a publicar contenido que permanecía redireccionado, por poner otro ejemplo que me quita el sueño, sobre todo si se retiró (sin despublicar) por razones legales.

Que el site de origen, el CMS primigenio, colabore es vital para el éxito de la operación. Se puede hacer sin su colaboración, pero esto es casi un billete con destino asegurado al fracaso. Es bastante habitual que la empresa del CMS de origen no colabore o, peor aún, ponga piedras en el camino, o bien tema por su prestigio y colabore, pero realizando el esfuerzo mínimo necesario. Incluso cuando se produce esta ayuda de buena fe, no son infrecuentes los malentendidos…

Son millones las cosas que pueden pasar al realizar una migración, pero si con algo debemos ser lo más finos posibles es con las urls, sobre todo para que Google y sus competidores entiendan bien el paso que hemos decidido dar con valentía. Lo ideal es no cambiar las urls, pero si esto ha de hacerse, hay que realizar redirecciones 310 permanente de todas y cada una de las urls. Y ojo, porque he estado en proyectos que salieron mal y supusieron pérdida de tráfico incluso haciendo todas las redireccione bien, si bien esto pasó hacer algunos años…

Mi experiencia migrando de un CMS a otro

Para concluir, debo confesar que mi experiencia con migraciones ahonda en mi total desafección por este proceso informático que es la migración. En alguna ocasión en Yahoo! los ingenieros de Bangalore se negaron a redireccionar todas y cada una de las urls (solo redireccionaron las 200 con más tráfico), lo que acabó con un proyecto en un nuevo y fantástico CMS global que arrancó con un 75% del tráfico de su predecesor.

En otra ocasión llegué al proyecto cuando la “fiesta” ya había terminado. La migración se había concluido y, como el feedback del cliente fue nulo, se migró dejando en el limbo nada más y nada menos que varios miles de artículos, informaciones que nunca se llegaron a trabajar y categorizar bien, por falta de tiempo y también presión por parte del cliente. Por ésta y otras razones, el proyecto ya no está “online”.

¿Es o no es una migración más aterradora que la película de El Exorcista?

Artículos relacionados: