Desmitificando las Opciones de Migración de Sistemas Legados a la nube de AWS

Por Phil de Valence, Arquitecto de Soluciones para Legacy Modernization en AWS

Muchas empresas o instituciones aún poseen sistemas legados no-x86 en sus centros de datos: sistemas propietarios de mainframe, gama media o UNIX.

La migración de estas cargas de trabajo a través de arquitecturas de hardware a la nube de Amazon Web Services (AWS) requiere una tecnología de software avanzada. Los enfoques de migración a corto plazo utilizan principalmente emulación de hardware, emulación de middleware, refactorización automática o re-plataforma de middleware.

Esta publicación destaca las opciones de migración a corto plazo, sus diferencias técnicas clave, así como sus beneficios diferenciados. Estas opciones son particularmente adecuadas para aplicaciones personalizadas hechas a la medida que se ejecutan en una plataforma legada donde se encuentra disponible todo el código fuente. Por otro lado, las aplicaciones creadas por terceros generalmente requieren una discusión con dichos proveedores de software para validar las opciones de modernización hacia AWS.

Opciones de Migración a Corto Plazo

Estas opciones de migración resultan en proyectos de corta duración, con retorno de inversión (ROI) y ganancias rápidas.

El diagrama de la Figura 1 muestra, para cada opción, cuales componentes cambian y cuales permanecen iguales durante la migración de la plataforma legada que no es x86.

Figura 1 – Cambios de componentes en migración de legados.

Emulación de hardware legado: el emulador de hardware reemplaza el hardware legado, pero el sistema operativo (SO) legado y las aplicaciones permanecen igual.
Emulación de middleware legado: el emulador de middleware reemplaza las API de middleware legadas y las API de sistema operativo requeridas por la aplicación, permitiendo su portabilidad. La mayoría del código fuente de la aplicación se vuelve a compilar sin cambios, con algunas adaptaciones para las dependencias modificadas.
Refactorización automática del legado: el código, los datos y las dependencias se convierten automáticamente a un lenguaje, almacén y estructura de datos modernos, al tiempo que garantiza la equivalencia funcional con las funciones del negocio.
Reemplazo de middleware moderno: este sólo aplica a los lenguajes modernos, middleware y runtimes que están disponibles tanto en sistemas legados como en sistemas x86, por ejemplo, Java, PHP y bases de datos relacionales. Permitiendo la reutilización del código de la aplicación y las bases de datos.

Propuestas de Valor Diferenciado

Cada opción de migración tiene sus casos de uso preferidos y una propuesta de valor única, relevante para una carga de trabajo legada específica.

Teniendo en cuenta una carga de trabajo de tamaño promedio con unos pocos millones de líneas de código, el diagrama de la Figura 2 muestra características diferenciales clave, como el costo del proyecto, la duración del proyecto y la agilidad de la nube, como lo representa el Modelo de Madurez Nativo de la Nube. Este modelo promueve el uso de principios de diseño de AWS Managed Services, Twelve-Factor App, Microservicios y automatización, como la Integración Continua/Despliegue Continuo (CI/CD).

Figura 2 – Opciones de migración en relación con la duración, el costo y la agilidad.

Los detalles y explicaciones sobre cada opción de migración se proporcionan en las secciones siguientes.

Emulación de hardware legado

Tipo de migración: re-host usando emulación de hardware.
Sistemas aplicables: esta opción se aplica a los mainframes IBM Z, mainframes Unisys ClearPath, máquinas SPARC, computadoras AlphaServer, estaciones VAX, computadoras HP 3000 y HP 9000, minicomputadoras PDP y otras. Permite ejecutar sistemas operativos como IBM z / OS, Unisys ClearPath MCP u OS2200, Solaris, SunOS, HP-UX, MPE, OpenVMS, Tru64, RSX-11, RSTS o RT-11, sobre la infraestructura de AWS.
Descripción: el software del proveedor para emulación, provee la funcionalidad de emular un conjunto de instrucciones de hardware legado. Por lo tanto, puede ejecutar los binarios legados sobre un conjunto moderno de instrucciones de Linux y x86-64. Esto permite ejecutar el sistema operativo legado y sus aplicaciones sin cambios, sin requerir recompilar el código fuente o transformar los binarios.

Figura 3 – Emulación de hardware legado.

Ejemplo arquitectura destino: los emuladores de hardware del proveedor se ejecutan en instancias de Amazon Elastic Compute Cloud (Amazon EC2). Debido a que el sistema operativo es legado, los servicios administrados de AWS no se usan para computación o datos.
Enfoque de migración: dado que el sistema operativo de origen, los binarios y archivos no han cambiado, se trata de una reubicación del sistema operativo del hardware legado al sistema de emulación. Por lo general, se realiza con una restauración del backup o restauración del volcado del sistema operativo legado, junto con la transferencia de archivos de respaldo a través de AWS Direct Connect o AWS Snowball. Las aplicaciones, los datos y las interfaces permanecen inalterados, y la cantidad de pruebas requeridas se reduce, lo que permite migraciones en días o semanas.
Casos de uso típicos: Migración de ambientes de desarrollo y prueba a AWS; Migración de aplicaciones de producción estabilizadas a AWS; Mantener el mismo stack de software de desarrollo de aplicaciones mientras se moderniza el hardware; proceso de apagado de centro de datos, incluyendo el retiro de hardware legado.
Beneficios del emulador de hardware: No se hacen cambios en el código de la aplicación, el middleware, ni el sistema operativo; Se mantienen las mismas interfaces y los mismos protocolos de comunicación; Migración transparente para usuarios finales y propietarios de aplicaciones.
Beneficios con AWS: gran variedad de tipos de instancia de Amazon EC2 para CPU, memoria, almacenamiento, ancho de banda de red; Cambios de capacidad y escalabilidad en minutos; Costo optimizado con el modelo de pago por uso de AWS o instancias reservadas (RI); Mayor disponibilidad usando las zonas de disponibilidad (AZ).
Precaución: la emulación de conjuntos de instrucciones de hardware requiere la traducción de instrucciones sobre la marcha, lo que tiene un impacto en el rendimiento. Dependiendo de la antigüedad del hardware legado de origen y del software del emulador, este impacto en el rendimiento puede ser más o menos notable. De cualquier manera, se recomienda un punto de referencia de rendimiento. Las instancias de Amazon EC2 con la velocidad de reloj del procesador más rápida, como las instancias z1d a 4.0 GHz, pueden ayudar.
Ejemplos de proveedores: Stromasys Charon, IBM Z Development and Test Environment, Unisys ClearPath Forward.
Mejores prácticas del proveedor: es importante comprender cómo cada proveedor optimiza la traducción de las instrucciones del emulador y las posibles opciones de afinamiento en rendimiento con AWS.

Emulación de Middleware Legado

Tipo de migración: re-plataforma con código migrado a un emulador de middleware.
Sistemas aplicables: esta opción se aplica a algunos mainframes IBM Z, mainframes Unisys ClearPath, IBM AS/400, iSeries e IBM i. Permite portar y recompilar aplicaciones que anteriormente dependían de middleware legado y almacenes de datos, como IBM CICS, IMS, VSAM, QSAM, Unisys COMS, TIP, IBM DB2 para z/OS, DB2 para i (DB2/400) y Adabas. Estas aplicaciones se pueden escribir en lenguajes de programación como COBOL, PL/I, RPG y Natural.
Descripción: El software del emulador del proveedor emula las API del middleware y del sistema operativo necesarias para el código de la aplicación. Por ejemplo, los emuladores de middleware pueden proveer las API para el acceso a archivos indexados, para la gestión de transacciones, para interfaces y protocolos legados, para almacenamiento temporal y soporte al batch . Esto permite migrar y recompilar el código fuente de la aplicación para la ejecución nativa x86-64.Si un lenguaje específico no es compatible, primero debe convertirse a uno compatible. Debido a la compilación, el emulador no realiza una traducción de instrucciones sobre la marcha y, en consecuencia, no hay un impacto relacionado en el rendimiento. Las dependencias o funcionalides no provistas por el emulador (planificador, impresión, seguridad, etc.) deben reemplazarse por equivalentes x86 con código o adaptaciones de configuración correspondientes.El formato de datos legados se puede mantener (VSAM, QSAM) o mapear a una base de datos relacional, tal como Amazon Aurora, Amazon RDS para Oracle o Amazon RDS para SQL Server.

Figura 4 – Emulación de middleware legado.

Ejemplo de arquitectura destino: El software de los proveedores de emulación para middleware, generalmente, se ejecutan en instancias de Amazon EC2. Algunas dependencias de seguridad, programación, o colas de mensajes se implementan en sus propias instancias. Los almacenes de datos se pueden modernizar para beneficiarse de los servicios administrados de Amazon RDS, incluida Amazon Aurora. Algunas aplicaciones pueden beneficiarse de AWS Auto Scaling y Elastic Load Balancing entre zonas de disponibilidad (AZs).
Enfoque de migración: debido a los cambios en el sistema operativo, el middleware y las dependencias, las adaptaciones de código, la conversión de formato de datos y la re-compilación completa, este es un proyecto de re-plataforma donde los programas y las funciones del negocio se migran de manera incremental y se prueban exhaustivamente.Comienza con el descubrimiento de todos los programas, datos, dependencias e integraciones. Continúa con el diseño de la arquitectura de destino y las nuevas dependencias, definiendo las conversiones y reemplazos del lenguaje de programación y planificando los paquetes de trabajo y las transiciones. Luego, la mayor parte de la migración ocurre con cambios masivos automáticos en el código fuente, actualizaciones a las reglas de migración del código, conversión de datos correspondiente y pruebas.Las pruebas se centran en los cambios de código, datos, dependencias e integraciones. Una vez que las pruebas unitarias, de regresión, integración y rendimiento sean exitosas, la aplicación y los datos se implementan en sus entornos destino de AWS. Hay más detalles disponibles en Migrar un mainframe a AWS en 5 pasos y un caso de un cliente en Complete Mainframe to AWS Migration with Candid Partners. Dicha migración puede durar entre meses y años, dependiendo del número de líneas de código y otros factores.
Casos de uso típicos: Migración desde hardware y software legados y costosos; Retener la inversión del código de una aplicación, mantener el equipo de desarrollo, mientras moderniza la infraestructura que soporta la aplicación; Llevar los entornos de desarrollo y prueba a AWS; Migración de aplicaciones de producción estabilizadas a AWS.
Beneficios del emulador de middleware: Elimine software y hardware de proveedores legados; Conserve el lenguaje de programación de aplicaciones, el código y la experiencia en desarrollo; Las mismas interfaces y los mismos protocolos de comunicación; Migración transparente para los usuarios finales; Facilitar la modernización e integración con servicios en la nube; Reduzca los riesgos conservando la misma lógica y código.
Beneficios de AWS: Este Incluye los beneficios de AWS descritos para el emulador de hardware, además de la capacidad de usar los servicios administrados de AWS como Amazon RDS o Elastic Load Balancing. Algunas aplicaciones pueden beneficiarse de la escalabilidad y elasticidad horizontal con Auto Scaling Groups. Las aplicaciones pueden beneficiarse de los servicios DevOps para administrar un pipeline de CI / CD.
Precaución: Tales proyectos no son de reubicación, puesto que requiere un análisis y planificación detallados para cambios de dependencia, adaptaciones de código, conversión de datos y proceso de pruebas exhaustivas. Algunos códigos de aplicación legadas o formatos de datos legados pueden dificultar el uso de las mejores prácticas de AWS para la escalabilidad y disponibilidad.Si el emulador no soporta un lenguaje de programación o un activo (assembler, código personalizado, bases de datos propietarias), la complejidad aumenta drásticamente. Las aplicaciones se basan principalmente en el emulador de middleware para la integración de servicios de AWS. Diferentes proveedores de emuladores de middleware tienen diferentes capacidades para integraciones y optimizaciones de AWS.|
Ejemplos de proveedores: Micro Focus Enterprise Server, NTT DATA UniKix, TmaxSoft OpenFrame, Astadia OpenMCS, Infinite i.
Mejores prácticas del proveedor: las aplicaciones se benefician de una mejor disponibilidad, elasticidad, rendimiento y optimización de costos al usar la escalabilidad horizontal de AWS. Los emuladores de middleware deberían facilitar la escalabilidad horizontal, especialmente para almacenes de datos legados, estructuras de datos compartidas en memoria, favoreciendo arquitecturas activas / activas entre AZ y evitando los arquitectura en silos.Los emuladores de middleware también se diferencian con el soporte para servicios de AWS como Amazon Aurora, Amazon RDS, Amazon Linux y Amazon CloudWatch.

Refactorización Automática Legada

Tipo de migración: refactorización automatizada con conversión de código, dependencias y datos.
Sistemas aplicables: esta opción se aplica a lenguajes como COBOL, PL/I, RPG, Natural y FORTRAN, incluyendo generadores de código tal como Cobol: Aplicaciones Gen o PowerBuilder. Este convierte modelos de datos de almacenes de datos como IBM DB2 z/OS, VSAM, QSAM, IMS DB, DB2 para i (DB2/400), Adabas y Data Management System.Eso significa que muchas aplicaciones alojadas en mainframes IBM Z, mainframes Unisys ClearPath, IBM AS/400, iSeries e IBM i pueden beneficiarse de la refactorización automática a AWS.
Descripción: La refactorización automatizada no es una reescritura manual de código, es una conversión y generación automatizadas de código moderno, acceso a datos, formato de datos y dependencias, todo en conjunto. Esta transformación exhaustiva y coherente garantiza la equivalencia funcional, mientras que la automatización aumenta la velocidad y reduce los riesgos.Esta transformación aplica patrones y reglas para migrar componentes legados, tal como llevar interfaces legadas, acceso a archivos indexados y procesos en batch hacia aplicaciones modernas con programación orientada a objetos y orientada a servicios, basada en lenguaje de programación (Java o C #), frameworks para el back-end (Por ejemplo, Spring), y frameworks para el frontend (Por ejemplo, Angular).Las herramientas de refactorización automatizadas le brindan, desde el primer momento, la posibilidad de elegir varios servicios de AWS gestionados mientras se transforma en aplicaciones nativas de la nube. La refactorización también puede aislar grupos de programación y dependencia de datos, facilitando la identificación y creación de microservicios.

Figura 5 – Refactorización automática legada.

Ejemplo de arquitectura de destino: Por defecto, las herramientas del proveedor convierten el stack para que se ejecute en instancias de Amazon EC2 como capa de cómputo, en Aurora o Amazon RDS para la capa de datos, forjando una arquitectura web elástica. Con la flexibilidad de la refactorización automática y la capacidad de ajustar las reglas de transformación, se pueden incorporar muchos otros servicios administrados de AWS, como Amazon Simple Queue Service (SQS) para mensajería o Amazon ElastiCache para estructuras de datos compartidos en memoria.Algunas aplicaciones también pueden beneficiarse de la ejecución en contenedores dentro de Amazon Elastic Container Service (Amazon ECS) y Amazon Elastic Container Service para Kubernetes (Amazon EKS), o dentro de las funciones serverless AWS Lambda. Dado que la nueva arquitectura está enfocada en servicios, las funciones de negocio se publican fácilmente a nuevos clientes, tal como aplicaciones móviles, a través de Amazon API Gateway.
Enfoque de migración: el enfoque general y las fases de un proyecto de refactorización automático de un sistema legado son similares a los de un proyecto de emulación de middleware legado, porque ambos incluyen un inventario de activos, mapeo de dependencias de aplicación con los nuevos componentes de arquitectura, cambios masivos en el código fuente, compilación de código y proceso de pruebas, que pueden llevar entre el 60 y el 80 por ciento del tiempo dedicado al proyecto.De manera específica, las herramientas de refactorización automatizadas permiten la ingeniería inversa del código de la aplicación y los modelos de datos para construir un diseño de la aplicación que muestre todas las dependencias de programa y datos, junto con sus características importantes. Este modelo detallado es usado para definir la estrategia de migración, mapeo de componentes y datos, reglas de conversión de código y formato de datos, descomposición de flujos de trabajo, y transiciones.La mayor parte de la migración ocurre con conversiones automáticas de código y datos, con transiciones incrementales, actualizaciones de las reglas de conversión, pruebas exhaustivas y sin reescritura manual de código. Hay más detalles disponibles con ejemplos de clientes en Refactorización automatizada de un mainframe del New York Times a AWS con sistemas modernos, y en Refactorización automatizada de un mainframe del Departamento de Defensa de los EE. UU. A AWS. Dicha migración general puede durar meses o años, dependiendo del número de líneas de código y otros factores.
Casos de uso típicos: Migración de lenguajes como COBOL, PL/I, RPG y Natural; Modernizar y estandarizar del stack técnico completo, mientras se mantiene la inversión de de las aplicaciones del negocio; Resolver el retiro de sistemas legado y las brechas de conocimiento de estos sistemas; Innovando con prácticas ágiles, servicios gestionados y tecnologías nativas de la nube.
Beneficios de refactorización automatizada: Eliminar tecnologías legadas; Mantener las aplicaciones enfocadas en el negocio y sus interfaces; Reducir o eliminar los costos de licencias de software de middleware; Agilidad de infraestructura y aplicaciones; Transformar hacia una arquitectura de componentes similar a una aplicación nativa de la nube; Facilitar la definición de microservicios; Reducir los riesgos garantizando la equivalencia funcional.
Beneficios de AWS: la arquitectura de aplicación modernas permite una mejor escalabilidad horizontal, elasticidad, rentabilidad y mejores prácticas de DevOps. Los datos se vuelven fácilmente reutilizables entre servicios de analítica y big data de AWS. Los programas orientados a servicios pueden integrarse rápidamente con nuevos casos de uso, como aplicaciones móviles a través de Amazon API Gateway o interfaces de voz con Amazon Alexa.
Precaución: la herramienta de refactorización automatizada es un factor crítico de éxito. Dichas herramientas deben evaluarse exhaustivamente durante una prueba de concepto (PoC) completa que demuestre equivalencia funcional, velocidad de conversión, velocidad de pruebas, calidad de código y rendimiento de código. Los procesos batch pueden ser un buen caso de prueba para una PoC completa.Los proyectos de refactorización automatizada implican pruebas exhaustivas. Esto puede afectar drásticamente el precio y la duración del proyecto dependiendo de qué herramientas de automatización se estén utilizando, cuál es el alcance de las pruebas, qué tan exhaustivas son las pruebas y quién es responsable de ejecutar estas pruebas.
Ejemplos de proveedores: Blu Age, TSRI, Modern Systems, Heirloom.
Mejores prácticas de proveedores: muchos proveedores proporcionan herramientas de ingeniería inversa para el inventario y el análisis profundo de los activos legados. Pero, pocos proveedores ofrecen ingeniería avanzada con alta automatización (sin reescritura manual de código), conversión integral y coherente de datos (no solo transcodificación línea por línea), gran soporte de servicios AWS (herramienta adecuada para el trabajo correcto) y calidad código mantenible.El código que se puede mantener debería eliminar las funciones de COBOL legadas como GO-TOs y PERFORMs and MOVEs (No JOBOL). También debería reducir la complejidad del código (que se puede medir con SonarQube), usar operadores de lenguaje, tipos y método nativos, permitir procesamiento multi-threading para un alto rendimiento y adaptarse a las convenciones de nomenclatura y estándares de codificación del cliente.

Replataforma de middleware moderno

Tipo de migración: Replataforma, manteniendo el mismo middleware moderno pero diferentes sistemas operativos.
Sistemas aplicables: esta opción se aplica a middleware o runtimes que están disponibles de manera similar (generalmente con el mismo lenguaje de programación) tanto para el sistema operativo legado como para el sistema operativo x86. Por ejemplo, se aplica a aplicaciones que se basan en servidor de aplicaciones IBM WebSphere, en runtime PHP o Perl, en aplicaciones Java o en bases de datos IBM DB2.
Descripción: dado que el mismo middleware está disponible entre diferentes sistemas operativos, el código y los datos de la aplicación se pueden mover y ejecutar con cambios mínimos o sin cambios. Por ejemplo, los lenguajes interpretados son independientes de la plataforma. Del lado de la base de datos, se reutiliza el mismo esquema de datos o se realizan adaptaciones para migrar a un tipo de base de datos diferente.

Figura 6 – Reemplazo de middleware moderno.

Ejemplo de arquitectura destino: para replataforma puede usar, dependiendo del soporte y los requisitos previos del software de middleware, instancias de Amazon EC2 y servicios administrados de AWS como Amazon Elastic Beanstalk, Amazon EKS, Aurora y Amazon RDS.
Enfoque de migración: debido a que las aplicaciones y los datos se basan en middleware específico de terceros, se deben seguir procedimientos e instrucciones de migración específicos de los mismos proveedores para permanecer en una ruta de migración compatible. Dicho procedimiento puede implicar la exportación y luego la importación de paquetes de aplicaciones, o la copia de seguridad y luego la restauración de las bases de datos, incluidos el esquema y los datos.
Casos de uso típicos: estandarizar de la arquitectura técnica de software; Pasar a servicios gestionados; Evitar sistemas operativos propietarios de alto costo.
Beneficios de replataforma de middleware moderno: elimine los sistemas operativos legados; Habilite la agilidad de la infraestructura con elasticidad, tipos de instancias, mejores prácticas de DevOps e infraestructura como código.
Precaución: puede haber desafíos si la aplicación utiliza funciones nativas del sistema operativo o si el middleware no admite la misma configuración en todas las plataformas.

Otras opciones que puede considerar

La reescritura manual requiere volver a desarrollar la lógica de negocios desde cero y manualmente en un nuevo lenguaje de programación, y rediseñar los servicios de infraestructura. Para aplicaciones legadas típicas con millones de líneas de código, este enfoque tiene mayores riesgos:

Intentando capturar las especificaciones lógicas antiguas.
Errores con desarrollo de código manual.
Inconsistencias con las necesidades del negocio.
Pruebas de funciones que ya no son parecidas.
Gestionar proyectos muy grandes con muchas personas durante un período de 4 a 5 años.

La reescritura manual es más adecuada para funciones básicas y para identificar transacciones o programas con un alcance, interfaces y datos claros y limitados.

La recompra con un paquete de software implica identificar y reemplazar la aplicación local legada con una aplicación empaquetada de terceros. Esto suele ser más adecuado para aplicaciones cuya lógica central está mejor desarrollada por un proveedor externo. Por ejemplo, una solución de pago SaaS o una solución de cadena de suministro SaaS específica de la industria.

Dependiendo de si la aplicación legada ejecuta funciones centrales del negocio o no, la estandarización de un paquete de software podría resultar en una pérdida de ventaja competitiva. Con tales proyectos, existen riesgos al tratar de capturar las reglas comerciales de la aplicación legada, y existen riesgos en torno a la capacidad en desarrollos y personalizaciones manuales necesarias para satisfacer las necesidades comerciales.

Migración vs. agregación de funcionalidades

La migración consiste en trasladar aplicaciones de forma incremental pero permanente de una plataforma legada a AWS y, finalmente, cerrar el hardware legado. Sin embargo, algunos clientes desean mantener la plataforma legada por ahora y aun así beneficiarse de la propuesta de valor de AWS. Estos clientes pueden agregar funcionalidades a su plataforma legada con servicios de AWS.

Por ejemplo, tenemos clientes que utilizan con éxito AWS para análisis de datos legados y para habilitar nuevas interfaces como dispositivos móviles o de voz. Estos clientes suelen utilizar la replicación de datos entre el almacén de datos legado y los servicios de datos de AWS.

Otros clientes eligen crear y escalar ambientes de desarrollo y prueba en AWS. Por lo general, usan un IDE (Integrated Development Environment) en AWS, usan emuladores descritos anteriormente para las pruebas y promueven el código con un pipeline de regreso a la plataforma legada para el ambiente de producción.

Y hay otros clientes que reemplazan su costosa copia de seguridad y almacenamiento de archivos (como el hardware de cinta virtual) con soluciones de copia de seguridad de almacenamiento en la nube con costo optimizado.

Calidad de Servicio

Los sistemas legados a menudo tienen requisitos no funcionales estrictos. AWS ofrece numerosos servicios y características para construir y operar sistemas seguros, de alto rendimiento, resistentes y eficientes que soportan cargas de trabajo empresariales. Por ejemplo: cifrado de datos de seguridad con AWS Key Management Service (KMS); fiabilidad con AZ y regiones; elasticidad con Auto Scaling Groups; gestión del sistema con AWS Systems Manager y Amazon CloudWatch.

AWS Well-Architected Tool y AWS Trusted Advisor ayudan a construir y operar sistemas seguros, eficientes y rentables en la nube. Además, AWS agrega agilidad a las cargas de trabajo al proporcionar velocidad en la nube, servicios administrados, una amplia variedad de servicios e innovación facilitada.

Enfoque de migración

No hay un patrón único para la modernización legada. Los clientes necesitan la herramienta adecuada para el trabajo correcto, alineados tanto con la estrategia de TI como con las limitaciones técnicas legadas. Debido a la complejidad técnica, cualquier definición de enfoque debe incluir una Prueba de concepto técnica práctica que confirme si el enfoque y las recomendaciones de herramientas son viables.

Al considerar una evaluación para una migración de carga de trabajo legada, los siguientes resultados facilitan el proceso de decisión:

Inventario de activos a migrar.
PoC completa que demuestra la viabilidad técnica.
Descripción detallada del enfoque de migración.
Plan de proyecto por fases para la migración completa.
Dimensionamiento de AWS y estimaciones de costos del proyecto.
Caso de negocios para la migración legada, incluido el ROI.

Para obtener más información sobre las capacidades de migración legadas a AWS, comuníquese con su representante de AWS y revise nuestras soluciones de socios en el Blog de APN.

Revisores técnicos – idioma local

João Aragão Pereira

FSI Solution Architect, Amazon Web Services

Javier Cristancho

Solutions Architect, Amazon Web Services

Blog de Amazon Web Services (AWS)