archivo

Archivos diarios: febrero 16, 2010

A lo largo de mi todavía corta experiencia profesional he tenido la oportunidad de vivir diversas migraciones, algunas de mayor y otras de menor calado. Entre las migraciones importantes destaco tres, por el impacto que tenían sobre el conjunto de sistemas de información de la casa, la migración de Oracle 8 a 9i, la migración de Oracle 9i a 10g y la subida de versión del sistema de autenticación y firma electrónica que utiliza mi organización.

De estas tres (y en general de todas las demás) puedo extraer las siguientes conclusiones:

1) La migración no es algo que se realiza en un día o en varios, sino que de por sí es un proyecto, por lo que debe tener una planificación, uno o varios responsables y un equipo que participe en ella.

2) Las migraciones afectan a varios departamentos dentro de informática, por lo que la comunicación entre todas las partes resulta esencial, así como la existencia de más de una persona que tenga una visión completa y general sobre lo que se está haciendo.

3) Las migraciones deben haberse simulado previamente en otros entornos y verificar el correcto funcionamiento de los sistemas de información en los mismos, es decir, previamente se deberán haber modificado todos aquellos sistemas de información que requieran un mantenimiento adaptativo al nuevo entorno y comprobar que tanto estos, como aquellos que no requieran cambio funcionan de manera adecuada. Todas las pruebas y modificaciones que se realicen sobre los sistemas deben estar perfectamente documentados.

4) Estos otros entornos deben ser idénticos al entorno de producción. Cuanto menos parecidos sean, más problemas nos encontraremos el día de la migración. La realización de la migración en estos entornos debe documentarse de manera detallada, destancándose todos aquellos problemas que se produjeron en el proceso de migración (ya que podrían aparecer el día de la migración).

5) Durante todo el proyecto de la migración es muy recomendable contar con el soporte de empresas expertas en los productos que se migran. Si ya es importante el soporte a lo largo del proyecto, es esencial que mientras se realice la migración, éste se encuentre presencialmente en la oficina en la que se realice la migración. Además de estos expertos, es importante contar con soporte sobre los sistemas de información más críticos afectados por la migración, valorándose si basta con que estén localizables o si es necesaria su asistencia presencial.

6) El proyecto de migración puede ser un proyecto de muy larga duración y eso es importante tenerlo presente, para evitar en precipitaciones que podrían dar lugar probablemente al fracaso de sucesivas intentonas de migración. Por tanto, sólo es recomendable migrar cuando se tenga muy clara la posibilidad de éxito de la misma.

7) Antes de realizar la migración, hay que tener claro que sistemas de información se van a ver afectados por la misma y por tanto no estarán disponibles una vez realizada la misma, ya que será necesario preparar los equipos de trabajo necesarios, para que una vez realizada la migración se pongan manos a la obra y adapten el sistema al nuevo entorno. Evidentemente dichos sistemas de información no deben ser críticos, y por tanto asumir una perdida de disponibilidad total o parcial sobre un conjunto de funcionalidades durante unos cuantos días. También como es lógico si hay algún sistema crítico que no va a funcionar tras la migración no es recomendable migrar hasta que este sistema se haya adaptado.

8) Si se espera a que todo esté perfectamente adaptado antes de realizar la migración, probablemente esta no se realice nunca. Por tanto, es esencial que los sistemas críticos estén adaptados y que la mayoría de los no críticos también lo estén, pero es necesario establecer un umbral a partir del cual la migración es realizable.

9) Es necesario documentar con detalle los diversos pasos que se van a dar el día o días de la migración y quiénes son las personas encargadas de realizar cada tarea. También es necesario que esté perfectamente documentada la posible vuelta a atrás. Dado que las migraciones cuentan con una ventana de tiempo para poder hacerse, con el objeto de disponer del mayor tiempo posible, es necesario que todas aquellas operaciones relacionadas con la migración que se puedan realizar previamente a la misma, se adelanten (siempre y cuando no afecten a los sistemas actualmente en producción).

10) Por muy bien que se haya realizado el proyecto de migración y se hayan tenido en cuenta buenas prácticas, del estilo de las que estoy comentando en mi artículo, probablemente se producirán imprevistos durante el proceso de migración, por lo que es importante saber de antemano que no va a ser un camino de rosas.

11) Desde mi punto de vista, la vuelta atrás debe ser siempre la última opción y sólo aplicarse cuando se tenga constancia de que la migración no se va a realizar con éxito. Esto no tiene por qué ser necesariamente tras horas y horas de intentar que todo quede perfectamente ajustado, sino incluso puede ser al principio de la misma. Por tanto, si surgen problemas que pueden intentar solventarse o al menos investigarse, hay que esforzarse por corregirlos y sólo volver atrás si dichos problemas son importantes y/o afectan a sistemas críticos y se llega a la conclusión de que no se van a resolver en la ventana del tiempo disponible para la migración.

12) Si hay que volver atrás o interrumpir el proceso de migración, no hay que venirse abajo, son cosas que pasan y por tanto, que no haya salido a la primera o a la segunda, no quiere decir que no salga bien más adelante. Además se habrá ganado en conocimiento que permitirá incrementar la garantía de éxito de los siguientes intentos.

13) Es muy difícil que una migración salga limpia, por lo que además de los flecos previstos, surgirán flecos imprevistos que se tendrán que corregir los días siguientes a la migración.

14) Es en las migraciones cuando uno se da cuenta más de lo importante que resulta que las aplicaciones estén diseñadas con una tecnología y arquitectura homogénea, que estén bien organizadas en los diferentes servidores de aplicaciones y que tengan una documentación de calidad. Cuanto más de estos ingredientes se tengan más sencillo será el proyecto y el proceso de migración y, por tanto, se reducirán las posibilidades de imprevistos.