Pasar a la nube sin volar a ciegas.

Una aplicación puede depender de componentes que no aparecen en el primer listado de sistemas: servicios de directorio, tareas programadas en segundo plano, recursos compartidos de archivos o la interfaz de un socio externo. Estas conexiones se identifican junto con los responsables correspondientes. De ahí surgen grupos de migración cuyos componentes se migran juntos o se mantienen conectados de forma transitoria y deliberada. El volumen de datos, las ventanas de mantenimiento y la disponibilidad de los interlocutores de las áreas de negocio influyen en el orden. De este modo, el plan de oleadas refleja los procesos reales y no es solo una lista de sistemas que pueden trasladarse técnicamente.

Para cada grupo se determina una ruta de migración adecuada. Algunas aplicaciones pueden trasladarse en un primer momento prácticamente sin cambios, mientras que otras necesitan adaptaciones al entorno de destino. Una modernización más amplia puede tener sentido como paso independiente si, de lo contrario, ampliara innecesariamente el alcance de la migración. La decisión tiene en cuenta el riesgo del cambio, la operación posterior y los recursos disponibles. Antes de la transferencia se comprueban el entorno de destino, los accesos y las conexiones necesarias, de modo que las condiciones ya conocidas no tengan que crearse justo durante la ventana de conmutación prevista.

El día de la conmutación, el estado de los datos, los cambios en los accesos y las comprobaciones de negocio deben coincidir. Por eso un procedimiento acordado describe cuándo termina el trabajo en el sistema anterior, qué datos se transfieren y qué pruebas se realizan a continuación. A ello se suman las personas de contacto y las vías de comunicación. Las personas implicadas deben saber quién evalúa un problema y quién decide sobre la continuación. La accesibilidad técnica es solo uno de los pasos de comprobación; la aplicación también debe poder ejecutar los procesos relevantes para la actividad de su negocio.

También se acuerda de antemano en qué condiciones debe interrumpirse o revertirse la conmutación. Una vuelta atrás no es igual de sencilla para todas las aplicaciones, sobre todo cuando ya se han generado datos nuevos en el sistema de destino. Por eso la planificación fija las condiciones y los límites del procedimiento previsto. El piloto y las pruebas sirven para comprobar las hipótesis y mejorar el proceso. Solo con estos resultados puede valorarse conjuntamente si una nueva oleada de migración está lista o si todavía se necesita trabajo adicional.

Tras la puesta en producción pueden surgir nuevas observaciones: cambios de carga, permisos que faltan o procesos que no eran del todo visibles durante las pruebas. Durante la fase de estabilización acordada, estos puntos se registran, se evalúan y se resuelven. El traspaso a la operación incluye la configuración, los accesos, la monitorización y las tareas pendientes conocidas. Los responsables de sus aplicaciones confirman que estas pueden utilizarse desde el punto de vista del negocio; las competencias técnicas y organizativas se documentan de forma que, al finalizar el proyecto, quede claro quién responde a nuevas incidencias.

Después, los sistemas antiguos no deberían seguir funcionando sin haberse revisado. Al mismo tiempo, el desmantelamiento no debe eliminar ninguna dependencia todavía necesaria. Por eso, tras la aceptación, se determina conjuntamente qué recursos se dan de baja, qué datos se conservan y qué contratos deben adaptarse. Un plan de desmantelamiento fija el orden y las aprobaciones necesarias. Así se mantienen visibles los costes duplicados y las tareas pendientes. La migración termina con un traspaso ordenado y trabajos posteriores acordados, y no con la simple constatación de que los datos ahora se encuentran en otro lugar.