Planificar una migración a la nube: preguntas que responder primero

Mapeo del parque de aplicaciones actual

El punto de partida de cualquier migración es un inventario preciso de lo que la organización ejecuta hoy. Incluye aplicaciones, bases de datos, integraciones, tareas programadas y la infraestructura que las sostiene. Muchos parques han crecido durante años, y algunos componentes están mal documentados o ya no se utilizan. Registrar cada sistema con su responsable, su finalidad, su ubicación de alojamiento y un perfil aproximado de recursos crea la base contra la que se pueden contrastar todas las decisiones posteriores.

El descubrimiento resulta más útil cuando combina herramientas y conversaciones. Los análisis automatizados pueden revelar servidores en funcionamiento y conexiones de red, mientras que las entrevistas con quienes mantienen cada sistema dejan al descubierto acuerdos informales y comportamientos no documentados. Comparar ambas fuentes suele poner de manifiesto lagunas en las dos. El inventario resultante debe tratarse como un documento vivo, porque el parque de sistemas sigue cambiando mientras se planifica la migración.

Un resultado útil de este paso es un catálogo sencillo que clasifica cada sistema según su función y su estado. Las aplicaciones obsoletas pueden identificarse para su retirada en lugar de migrarlas. Los sistemas muy personalizados o vinculados a plataformas antiguas pueden marcarse para una revisión más detallada. Esta clasificación todavía no decide el enfoque de ningún sistema, pero acota el campo para que los análisis posteriores se concentren en los componentes que realmente lo necesitan.

Decidir qué cargas de trabajo se trasladan primero

No todas las cargas de trabajo deben moverse al mismo tiempo ni en el mismo orden. Los primeros candidatos suelen ser sistemas con menos dependencias externas, volúmenes de datos moderados y un comportamiento operativo bien conocido. Trasladar estos sistemas en primer lugar da al equipo de migración experiencia práctica con las herramientas, la red y la gobernanza antes de abordar cargas más complejas. La selección debe reflejar tanto las prioridades del negocio como la preparación técnica.

La secuenciación depende también del calendario de la empresa. Los sistemas que dan soporte a actividades estacionales, a informes regulatorios o a operaciones críticas pueden necesitar programarse en periodos en los que el cambio conlleve menos riesgo. Por el contrario, algunas cargas de trabajo pueden obtener un beneficio inmediato al reubicarse, como aquellas cuyas necesidades de capacidad son variables. Documentar las razones de cada posición en el orden ayuda a las partes interesadas a entender las compensaciones y reduce desacuerdos posteriores.

La planificación por oleadas es una forma habitual de agrupar las cargas de trabajo. Cada oleada reúne sistemas que comparten dependencias o que pueden trasladarse con un método similar, y cada una tiene condiciones explícitas de entrada y salida. Agrupar de este modo limita el número de cambios simultáneos y facilita aislar los problemas cuando aparecen. El orden de las oleadas debe revisarse a medida que se conocen los resultados anteriores.

• Criticidad para el negocio y tolerancia a las interrupciones
• Número y fortaleza de las dependencias con otros sistemas
• Volumen de datos y esfuerzo necesario para transferirlos
• Antigüedad de la plataforma actual y estado de su soporte
• Disponibilidad de personal cualificado que comprenda el sistema

Evaluación de dependencias y sensibilidad de los datos

Las aplicaciones rara vez funcionan de forma aislada. Invocan otros servicios, leen bases de datos compartidas, dependen de sistemas de directorio y utilizan rutas de red que pueden no ser evidentes en su configuración. Mapear estas dependencias antes de la migración revela qué sistemas deben trasladarse juntos y cuáles pueden separarse sin riesgo. Olvidar una dependencia es una de las causas más comunes de fallos inesperados tras un traslado, por lo que este mapeo merece una atención cuidadosa.

La sensibilidad de los datos determina tanto el destino como los controles que deben acompañarlo. La información puede estar sujeta a obligaciones contractuales, normas sobre datos personales, regulación sectorial o políticas internas de clasificación. Estos requisitos pueden determinar qué regiones pueden alojar los datos, qué cifrado y controles de acceso son necesarios y cómo se conservan los registros de auditoría. Identificar pronto la sensibilidad de cada conjunto de datos evita rediseños costosos una vez iniciada la migración.

La evaluación debe considerar también la residencia de los datos, los periodos de conservación y, cuando proceda, la base jurídica del tratamiento. Los equipos descubren a menudo que existen copias de datos sensibles en lugares no previstos, como entornos de prueba o informes exportados. Registrar dónde se almacenan los datos, quién puede acceder a ellos y durante cuánto tiempo deben conservarse proporciona a la migración una base sólida y defendible. Revisar estos hallazgos con los colegas de legal y seguridad suele ser más eficaz que resolverlos después del traslado.

Elegir un enfoque de migración para cada sistema

Una vez mapeado el parque de sistemas y establecidas las prioridades, la siguiente cuestión es cómo debe llegar cada sistema a la nube. El rehospedaje, conocido como lift and shift, traslada una carga de trabajo con cambios mínimos y suele ser la vía más rápida, aunque rara vez aprovecha todas las ventajas de los servicios nativos de la nube. La replataformización introduce ajustes limitados, como trasladar una base de datos a un servicio gestionado, manteniendo intacta la aplicación principal. La refactorización o la rearquitectura exigen cambios más profundos, pero pueden mejorar la escalabilidad y el coste operativo a largo plazo.

Retirar o reemplazar también son resultados válidos. Algunos sistemas ya no justifican su coste de funcionamiento, y una aplicación SaaS puede cumplir la misma función con menos esfuerzo de mantenimiento. Mantener un sistema on premises por el momento puede ser una decisión deliberada, por ejemplo cuando una dependencia o una restricción regulatoria aún está pendiente de resolver. Cada elección debe registrarse con su justificación para que las revisiones posteriores puedan reconsiderarla.

El enfoque elegido para un sistema suele afectar a sus vecinos, por lo que las decisiones deben contrastarse con el mapa de dependencias de la planificación previa. Una aplicación reubicada que depende de una base de datos que se conserva puede sufrir nuevas latencias, y ese efecto debe entenderse antes del traspaso y no descubrirse después. Tratar el enfoque como una decisión por sistema, respaldada por una justificación clara, mantiene la coherencia de la migración en su conjunto.

• Reubicar (rehost): trasladar con cambios mínimos, la vía más rápida
• Replataformar (replatform): realizar ajustes limitados para usar servicios gestionados
• Refactorizar (refactor): rediseñar para lograr escalabilidad y eficiencia nativas de la nube
• Sustituir (replace): adoptar una aplicación SaaS en lugar del sistema
• Retirar (retire): dar de baja los sistemas que ya no tienen un propósito claro
• Conservar (retain): mantener en las instalaciones propias durante un periodo definido y con un motivo expuesto

Definir los criterios de reversión y de pruebas

Antes de cambiar cualquier carga de trabajo, el equipo necesita criterios acordados para dos resultados: cuándo revertir el traslado y cuándo se considera aceptado el sistema migrado. Los criterios de reversión deben nombrar condiciones medibles, como las tasas de error, los tiempos de respuesta o los resultados de conciliación de datos, junto con la persona autorizada para activar la reversión. Sin estos umbrales acordados de antemano, las decisiones tomadas bajo presión durante el traspaso tienden a ser incoherentes y lentas.

Los criterios de prueba deben cubrir el comportamiento funcional, el rendimiento bajo una carga realista, los controles de seguridad y los procedimientos de recuperación. La validación de datos merece especial atención, ya que una migración puede tener éxito en cuanto a disponibilidad mientras altera o pierde registros sin que nadie lo note. Las pruebas en un entorno de no producción permiten al equipo medir los tiempos, incluido cuánto tardaría una reversión, algo que a menudo se subestima.

Documentar estos criterios junto con el plan de traspaso hace que la migración sea auditable y repetible. Cada criterio debe tener un responsable, un método de verificación y un momento del calendario en el que se comprueba. Este registro también sirve de referencia para cambios posteriores, de modo que las versiones futuras puedan evaluarse con los mismos estándares.

Definir la responsabilidad tras el traslado

La migración no termina con el traspaso, y es fácil dejar sin resolver quién opera cada servicio después. Las responsabilidades de parcheo, monitorización, gestión de accesos, revisión de costes y respuesta a incidentes deben asignarse a funciones concretas y no a un equipo genérico. Cuando la organización utiliza el modelo de responsabilidad compartida de un proveedor de nube, la división de tareas entre proveedor y cliente debe quedar por escrito para cada servicio.

La responsabilidad también abarca las decisiones que continúan después del traslado, como los umbrales de escalado, las programaciones de copias de seguridad y las políticas de retención. Una titularidad clara de estos elementos evita huecos en los que cada parte supone que otra es la responsable. Las revisiones periódicas, programadas a intervalos acordados por el equipo, ayudan a confirmar que las asignaciones siguen correspondiendo al uso real de los sistemas.

El traspaso es más fiable cuando se planifica como un proceso y no como un hecho puntual. Los manuales operativos, las vías de contacto y las rutas de escalado deben probarse con las personas que los van a utilizar, y cualquier cuestión de responsabilidad pendiente debe cerrarse antes de declarar completada la migración. Un sistema con un responsable conocido es mucho más fácil de mejorar, asegurar y retirar cuando llegue el momento.