La mayoría de los programas de migración a la nube comienzan con un análisis de la infraestructura. Azure Migrate detecta las máquinas virtuales. AWS Application Discovery Service mapea los servidores. Google Migration Center inventaría las cargas de trabajo. En cuestión de días, el equipo dispone de una hoja de cálculo con la información de cada servidor, su uso de CPU, su consumo de memoria y un coste estimado para ejecutar la misma configuración en la nube de destino. La evaluación de la infraestructura está completa. Se puede comenzar con la planificación.
Excepto que no puede. Porque el inventario de infraestructura indica qué hardware ejecuta las aplicaciones, no si estas pueden ejecutarse en la nube, cuánto costará modificarlas para que lo hagan, cuáles tienen dependencias que se romperán durante la migración, cuáles están escritas con API obsoletas que la plataforma en la nube no admite, o cuáles contienen diez años de lógica empresarial no documentada que deberá comprenderse antes de validar cualquier conversión. El análisis de la infraestructura es un requisito previo para la evaluación de la migración a la nube. No es la evaluación en sí misma.
Evalúa tu código antes de moverlo.
SMART TS XL Mapea todas las dependencias, obstáculos y posibles refactorizaciones en todo tu portafolio de aplicaciones.
MÁS INFORMACIÓN¿Qué es una evaluación de migración a la nube?
Una evaluación de migración a la nube es un análisis estructurado que determina si un conjunto de cargas de trabajo puede migrarse a la nube, cómo y a qué costo. Genera la base de evidencia para tres decisiones: qué estrategia de migración aplicar a cada carga de trabajo, cuál será el costo real de la migración en términos de esfuerzo y gasto en la nube, y en qué secuencia deben migrarse las cargas de trabajo para gestionar el riesgo de dependencia.
Una evaluación completa de la migración a la nube abarca cinco dimensiones distintas. Las herramientas de descubrimiento de infraestructura abordan una de ellas. Las otras cuatro requieren herramientas, técnicas y conocimientos especializados diferentes.
| Dimensión de evaluación | Qué responde | Herramientas primarias |
|---|---|---|
| Infraestructura | ¿Qué servidores, máquinas virtuales y servicios existen? ¿Cuáles son sus perfiles de utilización? | Azure Migrate, AWS Application Discovery, Google Migration Center |
| Código de aplicación | ¿El código es compatible con plataformas en la nube? ¿Qué cambios son necesarios? | Resumen del reparto, SMART TS XLModernización de la aplicación CloudPilot y GitHub Copilot |
| Datos | ¿Qué volúmenes de datos existen? ¿Dónde residen los datos? ¿Cuáles son la complejidad de la migración y las restricciones de cumplimiento? | Servicio de migración de bases de datos de AWS, Servicio de migración de bases de datos de Azure, Striim |
| Seguridad y cumplimiento | ¿Qué requisitos normativos se aplican? ¿Qué deficiencias de seguridad existen? ¿Qué cambios en la gestión de identidades y accesos (IAM) y el cifrado son necesarios? | AWS Security Hub, Microsoft Defender para la nube, Prisma Cloud |
| Costo y TCO | ¿Cuál es el coste total de la migración y el coste total de propiedad tras la migración? | Calculadora de precios de AWS, Calculadora de TCO de Azure, Infracost, Apptio Cloudability |
Las organizaciones que se centran únicamente en la infraestructura elaboran planes de migración con un alcance desconocido. Durante la migración, descubren sorpresas en cuanto a aplicaciones, datos, seguridad y costes, justo cuando el coste de solucionarlas es mayor.
Las cinco dimensiones de la evaluación de la migración a la nube
Evaluación de infraestructura
La evaluación de la infraestructura es el punto de partida. Realiza un inventario del entorno de origen: cada servidor, máquina virtual, contenedor y servicio, con su configuración, datos de utilización y conexiones de dependencia con otros componentes de la infraestructura.
Herramientas como Azure Migrate u otros productos automatizan la detección de componentes y configuraciones de cargas de trabajo. Estas herramientas reducen el esfuerzo manual y proporcionan una recopilación de datos coherente en todo el entorno, aunque podrían pasar por alto dependencias no documentadas.
Azure Migrate es el estándar para las organizaciones que migran a Azure. Realiza un descubrimiento sin agentes de entornos de VMware vSphere, Hyper-V y servidores físicos, generando evaluaciones de preparación, recomendaciones de dimensionamiento adecuadas basadas en el rendimiento y estimaciones de costos antes de que se migre una sola carga de trabajo.
AWS Application Migration Service (MGN) y AWS Application Discovery Service cumplen una función equivalente para los destinos de AWS. Discovery Service recopila datos de configuración y rendimiento locales mediante la recopilación sin agente o mediante un agente instalado localmente.
Google Migration Center proporciona un proceso unificado de descubrimiento y evaluación para las migraciones a Google Cloud, combinando el inventario de activos, el análisis de dependencias y el modelado del coste total de propiedad (TCO) en una única consola.
Las herramientas de infraestructura generan: inventario de servidores, líneas base de utilización, mapas de dependencia de red entre componentes de infraestructura y recomendaciones para optimizar el tamaño de la capa de nube objetivo. Lo que no generan: información sobre la compatibilidad de las aplicaciones que se ejecutan en esos servidores con la nube, el costo de modificar el código o cómo se migrarán los datos de dichas aplicaciones.
Evaluación del código de aplicación
Una evaluación del código de la aplicación identifica problemas de compatibilidad y oportunidades de modernización que pueden afectar el éxito de la migración. Esta evaluación es fundamental para garantizar que las aplicaciones se ejecuten de forma fiable en Azure y para planificar las fases de migración de manera eficaz. Es necesario evaluar el código de la aplicación para detectar obstáculos con antelación, reducir el riesgo de fallos en la migración y fundamentar las decisiones sobre la arquitectura de destino.
La evaluación del código de la aplicación encuentra cuatro categorías de problemas que el escaneo de la infraestructura no puede detectar:
Bloqueadores de compatibilidad , API, marcos de trabajo o características de tiempo de ejecución que no existen o se comportan de manera diferente en el entorno de nube de destino. Una aplicación Java creada para un servidor de aplicaciones Java EE que no está disponible en el servicio PaaS de destino requiere cambios en el código antes de poder implementarse. Una aplicación que utiliza una convención de ruta de archivo específica de Windows no puede ejecutarse en una instancia de nube basada en Linux sin modificaciones.
Suposiciones de infraestructura codificadas , direcciones IP, rutas de sistema de archivos, nombres de servidor o números de puerto integrados en el código que ya no serán válidos en el entorno de la nube. Estos son obstáculos para la migración que ningún análisis de infraestructura detectará porque se encuentran dentro del código de la aplicación, no en la configuración de la infraestructura.
Uso de API obsoletas : llamadas a API, bibliotecas o funciones de la plataforma que el entorno de nube de destino no admite o que han sido reemplazadas. Los proveedores de plataformas en la nube suelen dejar de dar soporte a versiones antiguas de sus API, y las aplicaciones que las utilizan fallarán en la nueva plataforma, incluso si funcionan correctamente en la actualidad.
La complejidad de las dependencias , es decir, la estructura interna de la aplicación, determina la dificultad de su migración y si puede dividirse en servicios desplegables de forma independiente. Una aplicación monolítica con un alto acoplamiento interno es más difícil y costosa de migrar que una aplicación con bajo acoplamiento, independientemente de lo que indique el inventario de infraestructura.
CAST Highlight realiza una evaluación automatizada del código de las aplicaciones a nivel de cartera, analizando el código fuente en varios lenguajes para generar puntuaciones de preparación para la nube, identificar obstáculos y analizar los riesgos del código abierto. Se menciona en el Marco de Adopción de la Nube de Azure de Microsoft como una herramienta recomendada para cargas de trabajo que no utilizan .NET ni Java.
CloudPilot se especializa en la evaluación detallada de la preparación para la nube, con puntuación de compatibilidad y generación de hojas de ruta de migración para JavaScript, Python, Node.js y Go.
La modernización de aplicaciones de GitHub Copilot combina las capacidades de evaluación AppCAT de CAST con la corrección de código asistida por IA específicamente para cargas de trabajo .NET y Java.
Para entornos empresariales que abarcan COBOL, JCL, PL/I, RPG y otros lenguajes de mainframe junto con pilas tecnológicas modernas, estas herramientas no ofrecen cobertura. La evaluación del código de las aplicaciones en sistemas heredados requiere una categoría de herramienta completamente diferente.
Evaluación de datos
La evaluación de datos determina la complejidad, el volumen, los requisitos de cumplimiento y el método de migración para cada almacén de datos incluido en el análisis. Con frecuencia se subestima porque parece sencillo (mover la base de datos, mover los datos), hasta que se revela su verdadera complejidad.
Las preguntas clave que debe responder la evaluación de datos:
Volumen y rendimiento : ¿Cuántos datos existen? ¿Cuál es la tasa de cambio? ¿Se pueden migrar con tiempo de inactividad o es necesario utilizar la replicación continua para lograr una transición con un tiempo de inactividad casi nulo?
Compatibilidad de esquemas : ¿El servicio de base de datos de destino admite las mismas características de esquema, tipos de datos y procedimientos almacenados que el origen? Las construcciones PL/SQL específicas de Oracle requieren conversión antes de migrar a PostgreSQL o a una alternativa nativa en la nube.
Soberanía de datos y cumplimiento normativo : ¿Dónde deben residir legalmente los datos? El RGPD, la HIPAA, la PCI-DSS y las normativas sectoriales específicas pueden restringir qué regiones de la nube pueden alojar determinadas categorías de datos.
Acoplamiento de la aplicación : ¿Qué tan estrechamente está acoplado el código de la aplicación al esquema específico de la base de datos? Un cambio de esquema que técnicamente es simple puede requerir cambios extensos en el código de la aplicación para adaptarse.
AWS Database Migration Service y Azure Database Migration Service admiten la replicación continua con un tiempo de inactividad mínimo para migraciones homogéneas (de Oracle a Oracle, de SQL Server a SQL Server) y la conversión de esquemas para migraciones heterogéneas (de Oracle a PostgreSQL, de SQL Server a Aurora).
Striim y Attunity proporcionan transmisión y replicación de datos en tiempo real para escenarios de migración de alta disponibilidad donde el tiempo de inactividad de la base de datos es inaceptable.
Evaluación de seguridad y cumplimiento
La evaluación de seguridad traza un mapa de la postura de seguridad actual de cada carga de trabajo e identifica los cambios necesarios para cumplir con los estándares de seguridad en la nube, los marcos de cumplimiento y los principios de la arquitectura de confianza cero.
La evaluación de seguridad de las dimensiones debe abarcar:
Gestión de identidades y accesos (IAM) : Las aplicaciones locales suelen usar cuentas de servicio con permisos amplios y autenticación mediante contraseña. Los entornos en la nube requieren control de acceso basado en roles, identidades de servicio con privilegios mínimos y autenticación mediante certificados o tokens. La brecha entre la IAM actual y la requerida es un esfuerzo de migración que no tiene nada que ver con el inventario de infraestructura.
Cifrado : Los requisitos de cifrado de datos en reposo y en tránsito difieren entre entornos locales y en la nube. Las aplicaciones que gestionan su propio cifrado en la capa de aplicación deben integrarse con servicios de gestión de claves en la nube. Los almacenes de datos sin cifrar que son aceptables en redes privadas requieren cifrado antes de migrar a servicios alojados en la nube.
Seguridad de la red : Las reglas del firewall, la segmentación de la red y la inspección del tráfico que se implementaron en el hardware de red local deben reconstruirse como grupos de seguridad en la nube, configuraciones de red virtual y reglas de firewall nativas de la nube.
Alineación con el marco de cumplimiento : Cada sector regulado tiene requisitos de cumplimiento específicos que se corresponden con configuraciones de nube específicas. Las cargas de trabajo HIPAA requieren opciones de configuración específicas en cuanto a almacenamiento, registro de acceso y cifrado. PCI-DSS exige una segmentación de red que debe implementarse de forma diferente en una VPC en la nube que en una infraestructura de red física.
Microsoft Defender for Cloud proporciona una evaluación de la postura de seguridad y una evaluación del cumplimiento con respecto a los estándares CIS, NIST, PCI-DSS y otros marcos para cargas de trabajo de Azure.
Prisma Cloud (Palo Alto Networks) y AWS Security Hub ofrecen una evaluación de seguridad y una monitorización del cumplimiento normativo equivalentes para entornos multinube.
Evaluación de costos y TCO
La evaluación de costos es el resultado más visible de la migración para las partes interesadas del negocio y, a la vez, el que con mayor frecuencia se elabora de forma incorrecta. El error común consiste en comparar los costos actuales del hardware local con los costos de computación y almacenamiento en la nube, lo que genera una comparación incompleta y, por lo general, engañosa.
Una evaluación completa del costo total de propiedad incluye:
Costos de infraestructura en la nube : Costos de computación, almacenamiento, redes y servicios administrados en la configuración de nube objetivo. La clave para un dimensionamiento adecuado, basado en datos de utilización reales (no en la capacidad aprovisionada), reside en la diferencia entre estimaciones precisas y estimaciones infladas.
Costos del esfuerzo de migración : Las horas de ingeniería necesarias para completar los cambios en el código de la aplicación, la migración de datos, la reconfiguración de la seguridad y las pruebas. Las evaluaciones que solo consideran la infraestructura subestiman sistemáticamente este costo porque no tienen visibilidad de la complejidad de la aplicación.
Cambios en las licencias : Pasar de licencias perpetuas locales a modelos de licencias basados en la nube, o de software específico del proveedor a alternativas nativas de la nube, cambia fundamentalmente la estructura de costos de las licencias.
Cambios en el modelo operativo : Los equipos de operaciones locales que gestionan el hardware físico son reemplazados por equipos de operaciones en la nube que gestionan los servicios en la nube. Las habilidades, las herramientas y la plantilla cambian.
Costes de formación y transición : Los equipos que aprenden nuevas plataformas en la nube, nuevos modelos de implementación y nuevos procedimientos operativos incurren en costes de productividad durante la transición.
Las calculadoras de precios de AWS , Azure y Google Cloud abordan la dimensión del costo de la infraestructura en la nube. Infracost proporciona estimación de costos integrada en las canalizaciones de IaC, generando estimaciones de costos como parte del proceso de CI/CD. Apptio Cloudability y herramientas FinOps similares brindan visibilidad continua de los costos después de la migración.
Las siete estrategias de migración: cómo la evaluación determina cuál se aplica
El marco de las “7 R” describe las estrategias disponibles para cada migración de carga de trabajo. La evaluación determina qué estrategia es la adecuada, y una evaluación errónea implica aplicar la estrategia incorrecta, que es la causa principal de la mayoría de los sobrecostos de migración.
| Estrategia | Lo que significa | Señal de evaluación que lo sugiere |
|---|---|---|
| Rehospedar (levantar y desplazar) | Migración a la nube sin cambios en el código. | Baja complejidad de la aplicación, sin problemas de compatibilidad, compatible con la infraestructura. |
| Cambiar de plataforma | Cambios menores para aprovechar los servicios en la nube (por ejemplo, migración a una base de datos administrada). | Acoplamiento moderado, oportunidad de actualización de plataforma específica, alcance de cambio de código aceptable |
| Refactorizar | Rediseñar la arquitectura para patrones nativos de la nube (microservicios, contenedores). | Alto acoplamiento monolítico, importantes requisitos de escalabilidad, justificados por el crecimiento previsto del tráfico. |
| rediseñar | Rediseño significativo de la arquitectura de la aplicación. | La aplicación es fundamentalmente incompatible con la nube; la nueva arquitectura proporciona importantes beneficios empresariales. |
| Reconstruir | Reescribir desde cero | La aplicación está más allá de la reparación económica; el reemplazo es más barato que la remediación. |
| Reemplace | Retira la aplicación personalizada y adopta una alternativa SaaS. | La aplicación proporciona una funcionalidad básica que se satisface mejor con un servicio en la nube ya existente. |
| Retirarse | Desactivar, la aplicación ya no es necesaria | Aplicación identificada como inactiva, redundante o reemplazada durante la evaluación. |
El inventario de infraestructura no puede distinguir entre candidatos para Rehost, Replatform, Refactor y Rebuild; todos parecen idénticos en la capa de infraestructura. La evaluación del código de la aplicación es lo que permite hacer esta distinción.
Evaluación de la migración a la nube para sistemas heredados y mainframe.
Las herramientas estándar de evaluación de migración a la nube están diseñadas para infraestructuras modernas: máquinas virtuales, contenedores, microservicios y aplicaciones nativas de la nube. Su rendimiento es deficiente o nulo para cargas de trabajo de mainframe, programas COBOL que se ejecutan en IBM z/OS, flujos de trabajos JCL que gestionan el procesamiento por lotes, aplicaciones PL/I que manejan transacciones financieras y programas RPG integrados en sistemas AS/400.
La evaluación de la migración a la nube de mainframes requiere un enfoque fundamentalmente diferente, ya que la capa de infraestructura no es la limitación. La limitación reside en el código de la aplicación, décadas de lógica empresarial acumulada, dependencias implícitas a través de conjuntos de datos y copias compartidas, y comportamientos en tiempo de ejecución que ningún análisis de infraestructura puede revelar.
Los ocho análisis necesarios antes de planificar de forma responsable cualquier migración de mainframe (inventario de programas, mapeo de dependencias, extracción de lógica de negocio, identificación de código muerto, clasificación de complejidad, análisis de programación de lotes, evaluación de la calidad de los datos y mapeo de integración) se describen en detalle en el contexto de la mitigación de riesgos en la migración de mainframe . Cada uno de estos análisis se centra en el nivel de código, no en la infraestructura.
Comparación de herramientas de evaluación para la migración a la nube
La tabla que aparece a continuación relaciona las principales herramientas de evaluación de la migración a la nube con la dimensión de evaluación que abordan y el escenario más adecuado para ellas.
| Capa de evaluación | objetivo en la nube | Uso recomendado | |
|---|---|---|---|
| Migración de Azure | Infraestructura | Azure | Detección y dimensionamiento óptimo de máquinas virtuales y servidores, estimación de costos de Azure. |
| Servicio de detección de aplicaciones de AWS | Infraestructura | AWS | Detección de servidores locales para migraciones a AWS |
| Centro de migración de Google | Infraestructura | GCP | Inventario de activos y costo total de propiedad para migraciones a GCP |
| Destacado de CAST | Código de aplicación | Multinube | Puntuación de preparación del código a escala de portafolio en diferentes lenguajes |
| CloudPilot | Código de aplicación | Multinube | Análisis detallado de compatibilidad para Python, JS, Node.js y Go. |
| SMART TS XL | Código de la aplicación + mapeo de dependencias | Multinube | Análisis de cartera en COBOL, JCL, mainframe y multilingüe |
| DMS de AWS | Datos | AWS | Migración de base de datos con conversión de esquema |
| Servicio de migración de bases de datos de Azure | Datos | Azure | Migración de SQL Server, MySQL y PostgreSQL a Azure |
| Strim | Datos | Multinube | Replicación en tiempo real para la migración de datos sin interrupciones. |
| Microsoft Defender para la nube | Seguridad | Azure / Multinube | Evaluación de la postura de seguridad y el cumplimiento normativo |
| Nube Prisma | Seguridad | Multinube | CSPM y cumplimiento normativo en AWS, Azure y GCP. |
| Infracosto | Costo | Multinube | Estimación de costos integrada de IaC en pipelines de CI/CD |
| Nublabilidad de la aplicación | Costo | Multinube | FinOps y gestión continua de costes en la nube |
| Corent SurPaaS | Infraestructura + aplicación | Multinube | Orquestación de descubrimiento, evaluación y migración impulsada por IA |
Cómo SMART TS XL Realiza evaluaciones del código de la aplicación para la migración a la nube.
SMART TS XL Aborda la capa de evaluación del código de la aplicación a la que no pueden llegar las herramientas de infraestructura, específicamente para entornos empresariales y heredados donde la cartera de aplicaciones abarca múltiples lenguajes, plataformas y generaciones tecnológicas.
Para un programa de migración que incluye programas COBOL, flujos de trabajos JCL, servicios Java, canalizaciones Python y esquemas SQL, SMART TS XL construye un modelo de dependencia unificado en todos ellos simultáneamente. Antes de que el equipo de migración decida qué volver a alojar, qué refactorizar y qué retirar, SMART TS XL establece lo siguiente:
Inventario completo del programa : Todos los programas fuente, archivos de copia, procedimientos y esquemas en todos los lenguajes del entorno; el inventario real, no el documentado, que en entornos heredados suele diferir entre un 20 % y un 30 %.
Mapeo de dependencias entre lenguajes : La función de mapeo de dependencias de la aplicación rastrea cómo un programa COBOL se conecta a un esquema DB2 que consulta un servicio Java, el cual alimenta una canalización de Python que produce una salida consumida por una interfaz React moderna. Esta cadena de dependencias entre lenguajes determina la secuencia de migración: los componentes con muchos dependientes deben migrar una vez que sus dependientes estén listos.
Identificación de código muerto : Los programas y procedimientos que nunca se ejecutan en ninguna ruta de producción pueden excluirse por completo del alcance de la migración. En grandes entornos heredados, esto suele representar entre el 10 % y el 25 % del inventario total, lo que supone una importante reducción de costes en la fase de evaluación.
Clasificación de complejidad : La capacidad de análisis de código estático clasifica cada programa según su complejidad ciclomática, el número de dependencias de copybook, el número de llamadas y otras métricas que determinan la dificultad de la migración. Los programas de alta complejidad con muchas llamadas son candidatos para refactorización o reconstrucción. Los programas de baja complejidad y pocas dependencias son candidatos para reubicación.
Análisis de impacto antes de cualquier cambio : La capacidad de análisis de impacto responde a la pregunta "¿qué se verá afectado si este programa cambia?" antes de que comience cualquier actividad de migración, convirtiendo el riesgo desconocido en un alcance estructurado y enumerado.
Para las organizaciones que planifican programas de migración de mainframe a la nube, SMART TS XL, modernización heredada El análisis genera la evaluación previa a la migración que los proveedores de servicios de migración requieren antes de que comience el trabajo de conversión: inventario estructural completo, gráfico de dependencias, clasificación de complejidad e informe de exclusión de código obsoleto.
Lo que debería producir una evaluación completa de la migración a la nube.
Una evaluación solo es valiosa en la medida en que permite tomar decisiones. Una evaluación completa de la migración a la nube debe generar cinco entregables que, en conjunto, definan el programa de migración:
Inventario de cartera de aplicaciones con asignación de estrategia de migración : Cada aplicación dentro del alcance se clasifica como Rehost, Replatform, Refactor, Rearchitect, Rebuild, Replace o Retire, con la evidencia de evaluación que respalda cada clasificación.
Plan de migración basado en dependencias : Secuencia en la que las aplicaciones deben migrar, derivada del grafo de dependencias en lugar de agrupaciones arbitrarias. Las aplicaciones sin dependencias entrantes de otras aplicaciones dentro del alcance pueden migrar en fases tempranas. Las aplicaciones de las que dependen muchas otras migran en fases posteriores, una vez que sus dependientes estén listos.
Estimación del costo total de la migración : Esfuerzo de ingeniería, costos de herramientas de migración, costos de ejecución paralela temporal y costos de capacitación, no solo las diferencias en los costos de infraestructura.
Modelo de TCO posterior a la migración : Gasto proyectado en la nube basado en configuraciones optimizadas y datos de utilización reales, comparado con los costos operativos actuales en las instalaciones, con supuestos realistas sobre cambios en las licencias y transiciones en el modelo operativo.
Registro de riesgos : Los riesgos identificados, los obstáculos de compatibilidad, las migraciones de datos complejas, las dependencias no documentadas, las restricciones de cumplimiento, con su probabilidad, impacto y las medidas de mitigación propuestas para cada uno.
Las organizaciones que elaboran estos cinco entregables antes de que comience la migración disponen de la información necesaria para que el programa tenga éxito. Las organizaciones que omiten la evaluación del código de la aplicación, la evaluación de datos o la evaluación de seguridad elaboran versiones incompletas de estos entregables y descubren las deficiencias durante la migración, cuando cada descubrimiento supone un coste adicional para solucionarlo.
