Hay varios escenarios en los que los clientes desean migrar a la nube, por ejemplo:

• Realizar migraciones de aplicaciones específicas.
• Evacuar el centro de datos por completo y moverse a la nube.
• Realizar una actualización de la infraestructura en el centro de datos y moverse a la nube por un período temporal.
• A algunos clientes les gustaría una flexibilidad híbrida; la capacidad de mover cargas de trabajo entre las instalaciones (on-premises) y la nube a voluntad.

Primero definamos: ¿Qué es una estrategia de migración de aplicaciones?

La estrategia de migración de aplicaciones generalmente se refiere al proceso de migración de todo el entorno de la aplicación y su infraestructura subyacente. Por lo general, esto se debe a decisiones comerciales para optimizar costos, encontrar más agilidad, mayor resiliencia o simplemente debido a la actualización de sistemas antiguos.

Las empresas suelen comenzar a contemplar cómo migrar una aplicación durante la segunda fase del “Proceso de migración”: descubrimiento y planificación de la cartera. Responder a las preguntas ¿Qué aplicaciones tengo en el entorno, cuáles son las interdependencias, qué migrará primero y cómo lo migrará?

Aquí es cuando determinan qué hay en su entorno (generalmente inspeccionan sus bases de datos de administración de configuración (CMDB), o hace uso de conocimiento institucional y/o implementan herramientas como AWS Discovery Service para comprender en profundidad qué hay en su entorno), cuáles son las interdependencias, qué será fácil de migrar y qué será difícil de migrar, y cómo migrarán cada aplicación.

Con este conocimiento, las organizaciones pueden definir un plan (que debe considerarse sujeto a cambios a medida que avanzan en la migración y obtienen experiencia) sobre cómo abordarán la migración de cada una de las aplicaciones de su cartera, mapeándolas a una estrategia “R” de migración (para cada aplicación o conjunto de aplicaciones) y definiendo el orden en que se migrarán.

1. Descubrimiento: esta etapa se identifica las aplicaciones y/o tecnologías que queremos migrar a la nube.
2. Evaluación: aquí evaluaremos los pro y contras de migrar a la nube y definiremos una lista de prioridades.
3. Selección de estrategia: durante esta etapa seleccionamos cuál estrategia es la indicada para migrar el workload o tecnología a la nube. El criterio de selección es sobre la base del objetivo de la migración. Cada estrategia tiene sus características, ventajas y desventajas.
4. Validación: Luego de hacer la migración validamos las cargas de trabajo, su funcionamiento y los objetivos planteados se hayan cumplido.

A continuación, haremos una breve descripción de las 6 estrategias de migración a la nube más comunes y detallaremos el séptimo enfoque que nos inspiró a escribir este post:

1- RE-HOSPEDAR: Cuando los clientes necesitan escalar rápidamente su solución por temas comerciales, en general optan por rehospedar en la nube. Esta estrategia, también conocida como Lift and Shift, permite:

• Mover aplicaciones a la nube sin realizar ningún cambio para aprovechar las capacidades de la nube. Por Ejemplo: migrar su base de datos Oracle local (on-premises) a una base de datos Oracle desplegada en una instancia de Amazon EC2 en la nube de AWS.
• La automatización de casi todo el proceso por medio de herramientas, como AWS Application Migration Service (MGN), CloudEndure Migration, AWS VM Import / Export, entre otras. No obstante, algunos clientes prefieren hacer la migración manualmente a medida que aprenden a aplicar sus sistemas heredados a la nueva plataforma en la nube.
• Las aplicaciones son más fáciles de optimizar / rediseñar una vez que ya se están ejecutando en la nube. En parte porque su organización habrá desarrollado mejores habilidades para hacerlo, y en parte porque la parte difícil (migrar la aplicación, los datos y el tráfico) ya se ha realizado.

2- RE-PLATAFORMA (CAMBIAR DE PLATAFORMA): Este enfoque también es conocido como lift-tinker-and-shift, donde se pueden hacer algunas optimizaciones en la nube (u otras) para lograr algún beneficio tangible, pero no cambiará la arquitectura central de la aplicación. Es posible que desee reducir la cantidad de tiempo que dedica a administrar instancias de bases de datos migrando a un servicio gestionado de base de datos como Amazon Relational Database Service (Amazon RDS), o migrando su aplicación a una plataforma completamente administrada como Amazon Elastic Beanstalk.

3- RE-COMPRAR: Simplemente, es pasar a un producto diferente. Por lo general, la recompra se ve como un cambio a una plataforma Software as a Service (SaaS). Ejemplo, pasar de un CRM a Salesforce.com, o un sistema de recursos humanos a Workday, o un CMS a Drupal. Estos son los típicos proyectos que observamos en este enfoque de migración.

4- RE-FACTORIZAR o RE-ARQUITECTAR: En esta estrategia es donde re-imaginamos la arquitectura y el desarrollo de la aplicación, normalmente utilizando características nativas de la nube. Por lo general, esto se debe a una fuerte necesidad de negocio de agregar funcionalidades, poder escalar o tener una mejor performance que, de otro modo, sería difícil de lograr en el entorno existente de la aplicación. Esta estrategia tiende a ser la más costosa, pero también puede ser la más beneficiosa en términos de crecimiento al negocio.

5- RETIRAR: Nunca se sabe lo que va a encontrar hasta que mire, y es común que nos encontremos que nadie sabe lo que hace el 10 -20% de una cartera de TI empresarial y simplemente se pueden desactivar.

6- RETENER: Normalmente, esto significa “volver a revisarlo” o no hacer nada (por ahora). Muchas veces los clientes no están listos y prefieren mantener las aplicaciones en su entorno de origen. Estas pueden incluir aplicaciones que requieren una refactorización importante y desea posponer ese trabajo para más adelante, y aplicaciones heredadas que desea conservar, porque no existe una justificación comercial para migrarlas.

7- REUBICAR: Esta es una nueva “R” para acelerar las migraciones. Reubica rápidamente aplicaciones basadas en VMware vSphere entre su entorno local a VMware Cloud on AWS con un mínimo esfuerzo y complejidad, manteniendo las operaciones consistentes con los entornos basados en VMware. Este nuevo enfoque también es conocido como hypervisor-level lift and shift. Una vez en la nube de AWS, sus aplicaciones son más fáciles de optimizar o reestructurar para aprovechar la amplitud y profundidad de los servicios de AWS. Con VMware Cloud on AWS, puede mover la infraestructura a la nube pública sin necesidad de volver a escribir el código de la aplicación, comprar nuevo hardware o modificar las operaciones existentes. Las organizaciones que utilizan VMware como su centro de datos local pueden crear un centro de datos virtual utilizando los mismos componentes básicos de vSphere en VMware Cloud on AWS.

Fuente: AWS