Antes de firmar con un socio de migración a la nube, pregúntele cómo inventariará lo que usted tiene en funcionamiento, cómo elegirá una estrategia de migración para cada aplicación, cómo diseñará y protegerá el entorno de destino, cómo dará marcha atrás en cada conmutación, cómo le mostrará los costes y cómo preparará a su equipo para operar el resultado. Unas respuestas concretas y por escrito le dicen más sobre la migración que tiene por delante que la tarifa diaria.
Pregunte cómo averiguarán lo que usted tiene realmente en funcionamiento
Un plan de migración vale lo que vale el inventario en el que se basa. Pregunte al socio cómo lo construirá: con entrevistas a los responsables de las aplicaciones, con datos de infraestructura como las métricas de los servidores y las conexiones de red, con el propio código o con las tres cosas. La documentación existente es un punto de partida, no una prueba, porque se va alejando de lo que realmente funciona.
Pregunte qué recogerá el inventario y de quién será después. Una buena respuesta enumera los campos y confirma que el inventario se queda con usted, decida lo que decida a continuación.
- Cada aplicación, su responsable de negocio y su grado de criticidad
- Entornos de ejecución, frameworks y sistemas operativos, señalando todo lo que haya llegado al final de su vida útil
- Bases de datos, recursos compartidos de archivos, tareas programadas y colas de las que depende cada aplicación
- Integraciones en ambos sentidos, incluidas las que nadie documentó
- Licencias ligadas al hardware o al número de procesadores que quizá no se trasladen a la nube
- Indisponibilidad aceptable y calendario del negocio: cierres de mes, temporada alta, plazos regulatorios
Espere una estrategia por aplicación, no una para todo el parque
Las aplicaciones pasan a la nube de formas distintas. Las opciones habituales son realojar una aplicación tal cual (lift and shift), adaptarla a una nueva plataforma con ajustes menores, como una base de datos gestionada, refactorizarla para usar servicios cloud, sustituirla por un producto de software como servicio, mantenerla donde está por ahora o retirarla. Un socio que propone el mismo enfoque para todo no ha mirado con suficiente atención.
Pida los criterios que utilizan para elegir, y pida verlos aplicados a tres o cuatro de sus propias aplicaciones antes de firmar. Su razonamiento sobre sus sistemas reales le dice más que una diapositiva de metodología. Pregunte en particular cómo tratan las aplicaciones con entornos de ejecución sin soporte, porque trasladarlas sin cambios lleva los riesgos antiguos a la nueva plataforma.
Averigüe quién diseña y protege la zona de aterrizaje
La zona de aterrizaje (landing zone) es el entorno de destino preparado: estructura de cuentas, identidad y accesos, red, registros, cifrado y las salvaguardas que hereda cada aplicación. Un error aquí se repite en cada aplicación que aterriza en ella. Pregunte quién la diseña, si está definida como código, por ejemplo con Terraform, y si su equipo de seguridad la revisa antes de que se traslade la primera aplicación.
La seguridad en la nube es compartida. El proveedor protege la infraestructura subyacente, y usted sigue siendo responsable de cómo la configura y la utiliza. Pregunte al socio qué controles pondrá en marcha, cuáles quedan en manos de su equipo y cómo se conceden, se registran y se retiran al final los accesos de sus propios ingenieros.
- Cuentas o proyectos separados por entorno, con la producción aislada
- Inicio de sesión único con usuarios nominativos y roles de mínimo privilegio, sin credenciales de administrador compartidas
- Registros centralizados y pistas de auditoría que los ingenieros del proyecto no puedan desactivar
- Cifrado en reposo y en tránsito por defecto, con los secretos fuera del código
- Regiones elegidas para cumplir sus obligaciones de residencia de datos y del RGPD
Pídales que le expliquen paso a paso una conmutación y una vuelta atrás
La conmutación es el momento en que el tráfico y los datos pasan al nuevo entorno, y es cuando la migración resulta más visible para el negocio. Pida al socio que le explique paso a paso la conmutación de una de sus aplicaciones: cómo se sincronizan los datos, cómo se cambia el tráfico, qué comprobaciones se ejecutan después y quién decide que ha funcionado.
Después, pregunte cómo volverían atrás. Un plan creíble indica las condiciones que activan la vuelta atrás, la persona que toma la decisión y cuánto tiempo sigue disponible el entorno antiguo. Si los usuarios han escrito datos en el nuevo entorno desde el cambio, pregunte cómo vuelven esos datos al antiguo. Los planes débiles se saltan esa pregunta.
Nuestro artículo sobre la migración de cientos de aplicaciones heredadas a AWS muestra cómo estos pasos se convierten en manuales de operaciones para un parque grande.
Exija ver los costes antes de que llegue la primera factura
Los costes de la nube no se comportan como los de un centro de datos. Usted paga por lo que está en funcionamiento, incluidos los entornos de prueba que nadie apagó, el almacenamiento que no deja de crecer y los datos que salen de la red del proveedor. Pida una estimación de costes por aplicación con sus hipótesis por escrito, y pregunte cómo la comparará el socio con el uso real en los primeros meses.
La visibilidad de los costes es una decisión de diseño, no un informe mensual. Pida reglas de etiquetado que vinculen cada recurso a una aplicación y a un responsable, presupuestos y alertas desde el primer día, y una revisión del tamaño de las instancias cuando las aplicaciones hayan funcionado con carga real. Dimensionar los servidores en la nube a imagen del hardware antiguo es una forma segura de pagar capacidad que nadie usa.
Señales de que una propuesta de migración no está lista
Cualquiera de ellas puede tener una explicación. Varias en la misma propuesta suelen indicar que el riesgo se ha dejado para que usted lo descubra.
- Un calendario cerrado antes de que nadie haya visto su inventario
- Una sola estrategia de migración aplicada a todas las aplicaciones
- Ningún plan de vuelta atrás por escrito, o una vuelta atrás que depende de restaurar copias de seguridad bajo presión
- Cuentas cloud, código de infraestructura o pipelines en manos del socio y no en las suyas
- Estimaciones de costes sin hipótesis y sin plan de etiquetado ni de presupuestos
- Una transferencia de conocimiento programada para la última semana
Planifique la transferencia de conocimiento desde la primera semana, no la última
La migración termina; la operación de la plataforma, no. Pregunte cómo aprenderá su equipo a operar lo que se construya: trabajo en pareja sobre tareas reales durante la migración, manuales de operaciones para las tareas recurrentes y un recorrido por la monitorización y las alertas con las personas que estarán de guardia.
Pida que todo esté en sus cuentas y repositorios desde el principio: código de infraestructura, pipelines, manuales de operaciones y diagramas. Después, acuerde cómo se acepta el traspaso: por ejemplo, que su equipo despliegue una aplicación y la haga volver atrás sin ayuda del socio.
Formamos parte del equipo que trasladó 600+ aplicaciones internas de Crédit Agricole de VM heredadas a AWS, y realizamos nosotros mismos 50+ de esas migraciones. Si quiere una segunda opinión sobre una propuesta de migración, o un equipo que ejecute parte del trabajo, nuestros ingenieros de infraestructura cloud pueden repasar estas preguntas con usted.
Puntos clave
- Pregunte cómo se construirá y verificará el inventario, porque de él dependen todas las estimaciones y el plan por oleadas.
- Espere una estrategia de migración elegida para cada aplicación, con criterios que pueda ver aplicados a sus propios sistemas.
- Exija que la zona de aterrizaje esté definida como código, revisada por su equipo de seguridad y alojada en sus cuentas.
- No acepte un plan de conmutación sin un criterio de vuelta atrás con responsable designado y una forma de recuperar los datos escritos después del cambio.
- Acuerde el etiquetado, los presupuestos y cómo se acepta el traspaso antes de que se traslade la primera aplicación.
Preguntas frecuentes
¿Debe migrar nuestro parque el mismo socio que lo evalúa?
Puede hacerlo, y a menudo ahorra tiempo, porque el equipo que construyó el inventario conoce los casos límite. Contrate la evaluación como un entregable independiente que sea suyo, para poder llevarla a otro socio si la propuesta de migración no le convence.
¿Cómo comparar las propuestas de distintos socios de migración?
Dé a todos los socios el mismo extracto del inventario y las mismas preguntas, y pida a cada uno que aplique sus criterios a las mismas pocas aplicaciones. Compare el razonamiento, los planes de vuelta atrás y las hipótesis que sostienen las estimaciones, no solo el precio total.
¿Puede nuestro equipo seguir lanzando funcionalidades durante la migración?
Sí, si el plan dice cómo. Acuerde una ventana de congelación de cambios para cada aplicación, una forma de mantener sincronizados ambos entornos mientras se traslada y quién aprueba las publicaciones mientras una aplicación está en plena migración.