Lista de verificación de migración a la nube:8 pasos para garantizar un viaje a la nube fluido (y seguro)

Mover aplicaciones y datos de misión crítica a la nube es un proyecto masivo que requiere una planificación profunda si espera un alto retorno de la inversión. Sin una estrategia sólida, es probable que su migración a la nube cause más pérdidas de ganancias y dolores de cabeza que beneficios comerciales.

Este artículo ofrece una lista de verificación de migración a la nube que garantiza que su traslado a la nube se realice sin problemas, con seguridad y sin sorpresas desagradables. Puede usar nuestra lista de verificación como punto de referencia para el proceso de migración, ya que el plan paso a paso a continuación cubre todos los aspectos principales de mover una aplicación a la nube.

Lista de verificación de migración a la nube

Luchar con la migración a la nube es un problema común para las empresas. Estudios recientes revelan que el 55 % de las migraciones a la nube experimentan retrasos significativos o superan el presupuesto .

Además, el 62 % de las organizaciones que actualmente realizan la transición a la nube describen el proceso como difícil o fallando . La mayoría de estas empresas se precipitan en la transición sin considerar detenidamente:

• El costo total de propiedad (TCO).
• Cómo trasladará el equipo grandes cantidades de datos y aplicaciones de misión crítica a la nube.
• Diferentes opciones para implementaciones e integración en la nube.
• Posibles nuevos riesgos de ciberseguridad.
• Cuán preparado está el equipo interno para operar en la nube.

La siguiente lista de verificación de migración a la nube garantiza que considere estos factores antes de que el equipo comience a mover aplicaciones y servicios a la nube.

Elija uno o más arquitectos de migración a los que acudir

La migración a la nube implica numerosos planes y decisiones técnicas, por lo que debe designar un solo especialista o un equipo de expertos para liderar el esfuerzo. Ya sea que vaya con uno o más miembros del personal, el rol de un arquitecto de migración es:

• Evaluar los servicios para ver si encajan mejor en el alojamiento local o en la nube.
• Cree un cronograma para la migración y la hoja de ruta de la nube.
• Diseñe estrategias óptimas para mover datos y aplicaciones.
• Identificar y supervisar la refactorización de aplicaciones necesaria.
• Determinar las prioridades de migración.
• Defina la cadena de herramientas necesaria.

El arquitecto dedicado también debe proporcionar una imagen completa de su TI. Este proceso consiste en responder a las siguientes preguntas:

• ¿Qué aplicaciones tienes y quién las usa (y con qué frecuencia)?
• ¿Qué tan críticas para el negocio son las aplicaciones que desea migrar?
• ¿Qué recursos consumen los programas y dependen de otras aplicaciones?
• ¿Qué SLA, medidas de continuidad comercial y medidas de cumplimiento existen actualmente?
• ¿Hay problemas de rendimiento que estén afectando las operaciones actuales?

Según el análisis, el arquitecto de migración debe evaluar si su fuerza laboral actual tiene los conocimientos necesarios para:

• Realice la migración.
• Operar en el entorno de la nube.

Nunca comience la transición a la nube a menos que esté seguro de que su equipo puede prosperar en la nueva configuración.

El equipo de migración dedicado también debe determinar el costo total de propiedad (TCO) para ilustrar el ROI de la migración a la nube. La evaluación del TCO para la migración a la nube incluye factores como:

• El costo total de la migración.
• Costos de la nube posteriores a la migración (principalmente el precio del ancho de banda y las redes).
• El costo de la capacitación del personal.
• Mantenimiento regular posterior a la migración.
• El costo del posible tiempo de inactividad.
• Costos de espacio, refrigeración y electricidad (para una nube privada local).

Establecer objetivos de migración y KPI

El siguiente paso es establecer los objetivos principales de la migración. Algunos objetivos comunes de alto nivel son:

• Modernización de una aplicación heredada.
• Aceleración de un servicio en particular.
• Mejorar las capacidades operativas.
• Aumento de la resistencia del sistema.
• Mejorar la experiencia del usuario.
• Lograr una mejor escalabilidad del servicio.
• Reducción de los costes de funcionamiento.
• Mejorar la seguridad de los datos.

Además del objetivo general, el equipo debe definir los indicadores clave de rendimiento (KPI) de la migración a la nube. Estas métricas medirán el rendimiento de una aplicación o servicio migrado frente a las expectativas. No hay límite para la cantidad de KPI que su equipo puede rastrear, pero todas las métricas pertenecen a una de dos categorías:

• KPI que sigue durante el proceso de migración.
• KPI posteriores a la migración.

Estos son los KPI más comunes que una empresa puede controlar durante el proceso de migración:

• Duración de la migración (tanto en conjunto como por aplicación).
• Disponibilidad de servicios críticos.
• Tiempo de inactividad de los servicios y centros de datos.
• Degradación del servicio debido al tiempo de inactividad.
• El número de tickets de servicio generados.
• Coste de la migración.

Veamos algunos KPI posteriores a la migración que su equipo puede rastrear:

• KPI de infraestructura (uso de CPU, consumo de memoria de servicio, rendimiento del disco, equilibrio de carga, latencia, rendimiento de la red, etc.).
• Métricas de rendimiento de la aplicación (tasas de error, cantidad de tiempos de espera, tiempo de respuesta promedio (ART), tiempo de respuesta máximo (PRT), tiempo de actividad, disponibilidad, etc.).
• KPI de la experiencia del usuario (número de picos de solicitudes, errores de código de estado HTTP, excepciones lanzadas y registradas, retraso, tiempos de respuesta, etc.).
• Métricas de impacto comercial (duración del proceso de pago, tasas de suscripción y cancelación de suscripción, tasas de participación, etc.).
• KPI de costos (facturación mensual, costos de personal, herramientas de terceros, costos de consultoría, etc.).

Debe establecer un valor de referencia para cada KPI antes de decidir qué rastrear. La línea de base es el proceso de medir el estado actual (antes de la migración) de una aplicación y un servicio. Estos KPI le permiten determinar si el rendimiento posterior a la migración es aceptable o no.

Realizar evaluación de datos y aplicaciones

La evaluación de datos es un paso vital de esta lista de verificación de migración a la nube, ya que mover datos suele ser la parte más complicada de adoptar la nube. La evaluación cuidadosa de los datos le permite a su equipo evaluar:

• Niveles de riesgo de datos.
• El volumen y el tipo de datos que planea migrar.
• Resistencia general de los datos.
• Requisitos legales de privacidad de datos (si los hay).
• Amenazas más importantes a la integridad de los datos.
• Posibles escenarios de fuga o violación de datos posteriores a la migración.

El lugar donde residen sus datos puede afectar el rendimiento de un servicio o un servicio. Mover datos a la nube cuando los métodos de acceso a datos aún funcionan en las instalaciones puede afectar significativamente el rendimiento. Lo mismo ocurre si la base de datos todavía está en las instalaciones, pero el servicio que accede a ella reside en la nube.

Además de evaluar los datos, sus aplicaciones locales deben recibir el mismo tratamiento. Antes de migrar, el equipo debe crear un inventario de todas las aplicaciones locales y sus servidores. También debe evaluar las máquinas virtuales actuales y tener en cuenta las posibles dependencias de las aplicaciones.

Como resultado, puede determinar qué aplicaciones requieren refactorización antes de moverlas a la nube. El equipo también puede comenzar a priorizar qué aplicaciones migrar primero.

Evaluar las opciones de migración a la nube

El siguiente paso de la lista de verificación de migración a la nube es evaluar qué aplicaciones requieren qué tipo de integración con la nube. Tienes dos opciones:

• Integración de nube superficial (también conocida como lift-and-shift): Cuando levanta y cambia una aplicación, hace pocos o ningún cambio en el código y configura la aplicación en la nube más o menos en su forma actual. La migración de una aplicación sin ningún cambio se conoce como rehosting.; hacer modificaciones menores al mover una aplicación a la nube es refactorizar .
• Integración profunda en la nube: A diferencia de su contraparte superficial, la integración profunda en la nube requiere que modifique la aplicación para aprovechar las funciones de la nube. Los cambios pueden variar desde ajustes relativamente simples (como configurar el escalado automático y el equilibrio de carga dinámico) hasta actualizaciones avanzadas (como habilitar la computación sin servidor) que hacen de la aplicación una solución nativa de la nube.

La integración en la nube superficial es una opción significativamente más rápida que refactorizar partes importantes de una aplicación. En general, las aplicaciones de misión crítica suelen valer el esfuerzo de integraciones profundas. Las aplicaciones y los servicios menos vitales pueden funcionar con un enfoque superficial, ya que puede refactorizarlos con el tiempo después de migrar a la nube.

Las empresas también suelen decidir retirar o conservar las aplicaciones al evaluar qué servicio requiere qué tipo de integración:

• Retirar es el proceso de identificar una aplicación o un servicio obsoletos que no tienen ningún valor si se suben a la nube.
• Retener es la decisión de mantener una aplicación local, generalmente debido a un problema de seguridad o cumplimiento.

Elija el modelo de implementación en la nube adecuado

Elegir un modelo de implementación en la nube adecuado es vital para una migración a la nube exitosa. Diferentes modelos se adaptan a diferentes casos de uso, y las cinco opciones entre las que puede elegir son:

• Nube pública (un entorno multiinquilino que proporciona acceso a recursos informáticos a través de Internet o a través de una conexión directa dedicada).
• Nube privada (un sistema de inquilino único en el que una empresa ejecuta recursos de nube dentro de su propio centro de datos).
• Nube híbrida (una combinación de sistemas locales, nubes públicas y privadas en las que las cargas de trabajo se mueven entre entornos a través de la automatización y la orquestación).
• Nube múltiple (una combinación de dos o más entornos IaaS de nube pública).
• Nube comunitaria (infraestructura compartida entre varias empresas con necesidades o preocupaciones compartidas).

El modelo de implementación que debe usar depende principalmente de las necesidades y objetivos únicos de su empresa. Aquí hay algunos consejos:

• La nube pública proporciona un entorno escalable con un modelo de pago por uso. Si bien es altamente escalable, la nube pública puede no ser ideal para cargas de trabajo sensibles.
• Una nube privada es perfecta para una empresa con el presupuesto para ejecutar un entorno de nube local personalizado para sus cargas de trabajo de misión crítica.
• Una nube híbrida le permite ejecutar cargas de trabajo confidenciales en las instalaciones y, al mismo tiempo, aprovechar la escalabilidad de la nube pública durante los picos de demanda.
• Si bien es muy beneficioso cuando se hace correctamente, existen algunos desafíos de la nube híbrida que debe tener en cuenta antes de diseñar una arquitectura híbrida.
• Multi-nube es una excelente opción para empresas preocupadas por el bloqueo de proveedores o empresas que buscan mezclar y combinar servicios de múltiples proveedores.

Elija un proveedor de servicios en la nube

A menos que haya optado por configurar una nube privada local, el siguiente elemento en la lista de verificación de migración a la nube debe ser encontrar un proveedor de nube. Si bien la mayoría de los proveedores ofrecen servicios similares, no todos son iguales. Algunas consideraciones clave al elegir un proveedor de nube son:

• Precios.
• Selección de servicios.
• Disponibilidad en regiones específicas.
• Garantías de tiempo de actividad.
• La familiaridad de su equipo interno con la pila tecnológica del proveedor.
• Requisitos de cumplimiento específicos de la industria (por ejemplo, mantener los datos del usuario en la ubicación de origen de acuerdo con CCPA o GDPR).
• Soporte posterior a la migración y servicios de TI administrados.

Recuerde que los proveedores de servicios más populares no siempre son los más adecuados. Los proveedores destacados tienen como objetivo satisfacer un amplio conjunto de necesidades, por lo que no siempre hacen una buena combinación con una empresa en una vertical específica.

Por ejemplo, una empresa que opera en el cuidado de la salud podría estar mejor si se asocia con un proveedor de nicho que comprenda mejor y respalde el cumplimiento de HIPAA.

Realizar la refactorización necesaria

Una vez que sepa qué implementación en la nube necesita y con quién asociarse, su equipo debe comenzar a realizar los cambios necesarios en las aplicaciones y los servicios antes de migrarlos a la nube.

El objetivo es hacer que el software funcione de la forma más eficaz y eficiente posible en la nube . Por ejemplo, su equipo puede refactorizar una aplicación para:

• Trabaja con un número variable de instancias en ejecución para permitir un escalado casi instantáneo.
• Aproveche las capacidades de la nube dinámica (como la capacidad de asignar y desasignar recursos según las necesidades actuales).
• Cree una arquitectura más orientada a servicios para mover rápidamente servicios individuales a la nube (tanto esta vez como más adelante).

Ahora también es el momento adecuado para repensar la gobernanza y la seguridad. Es probable que deba ajustar su estrategia de gobierno para depender menos de la seguridad y el control internos y más de los servicios en la nube del proveedor. En términos de seguridad en la nube, debe:

• Evaluar si la migración puede generar nuevas vulnerabilidades.
• Comprenda cómo trabajará su equipo interno con el proveedor para mantener seguros los activos en la nube.
• Ajuste (y potencialmente mejore) sus medidas y prácticas de seguridad actuales.
• Decida si puede beneficiarse de las herramientas de seguridad adicionales que ofrece el proveedor.
• Configure mecanismos de conmutación por error y recuperación ante desastres.

Migrar y cambiar metódicamente el tráfico desde las operaciones locales

Si bien puede migrar todo a la nube de una vez, este enfoque puede ser desafiante y arriesgado de lograr. En su lugar, debe migrar aplicaciones y servicios uno por uno , comenzando con aplicaciones menos críticas y avanzando lentamente hacia las más importantes.

Este es el aspecto que debería tener este enfoque de la migración:

• Dé prioridad a las aplicaciones que su equipo puede mover con la menor cantidad de riesgo para las operaciones. Buenas opciones son las aplicaciones que solo requieren un realojamiento o utilizan recursos mínimos (como poco almacenamiento o cómputos).
• Luego, comience a mover aplicaciones que tengan un alto valor para su negocio pero que presenten un riesgo relativamente bajo durante la migración.
• Por último, deje las cargas de trabajo disruptivas y de misión crítica para las etapas finales de la migración. Nunca comience a mover estas aplicaciones a menos que las de los pasos anteriores funcionen de manera óptima.
• Utilice una prueba manual o automática (o ambas) para verificar si la migración se realizó correctamente o no.

Según la arquitectura de sus aplicaciones y almacenes de datos, puede cambiar el tráfico de la solución local a la nube de dos maneras:

• Todo a la vez: El equipo cambia todo el tráfico local tan pronto como la aplicación comienza a ejecutarse en la nube.
• Un poco a la vez: Traslada algunos clientes al nuevo entorno una vez que el equipo configura la aplicación basada en la nube. Si todo funciona como se espera, continúa cambiando a los clientes a la nube con el tiempo hasta que todos los usuarios finales confíen en la nueva aplicación.

Use nuestra lista de verificación de migración a la nube para migrar con confianza

Si bien migrar a la nube suele ser una decisión obvia, muchas empresas luchan o tienen un éxito limitado al migrar aplicaciones a la nube. Cumplir con la lista de verificación de migración a la nube anterior le garantiza evitar todos los errores comunes, por lo que puede comenzar a planificar su adopción de la nube sin temor a errores costosos.