Más allá de la migración de máquinas virtuales: Qué viene después del lift-and-shift

He tenido esta conversación decenas de veces con los equipos de infraestructura. Acaban de terminar una migración de máquinas virtuales desde un hipervisor heredado o están en pleno proceso. La parte difícil casi ha terminado. O eso creen.

Hay algo de lo que la mayoría no habla: la migración en sí es la parte fácil. Es algo táctico. Tiene un principio, un intermedio y un final claros. Lo que viene después, modernizar realmente cómo ejecutas tu infraestructura, es donde reside el trabajo de verdad y, sinceramente, donde está la mayor parte del valor.

Los cambios del sector que impulsan estas migraciones representan una oportunidad estratégica para la infraestructura moderna. Al abordar la eficiencia de las licencias, la optimización de costos y la flexibilidad de proveedores, las organizaciones eligen Red Hat OpenShift Virtualization a un ritmo sin precedentes; la adopción de los clientes ha aumentado un 178 % desde principios de 2024. Aunque muchos debates se centran solo en el hecho de migrar, el valor real reside en la innovación que surge tras el traslado.

En lugar de ver la migración como el objetivo final, las organizaciones con visión de futuro la consideran el punto de partida. Esta transición no consiste solo en resolver desafíos del pasado; se trata de ayudarte a crear una base para aprovechar al máximo las capacidades de una plataforma de aplicaciones moderna, unificada y lista para el futuro.

Así es como se ve ese plan más amplio en la práctica.

Etapa 1: Pon en orden tu entorno de Linux

Después de la migración, deberías evaluar la proliferación de sistemas operativos. La mayoría de las organizaciones cuenta con una combinación de distribuciones, versiones y contratos de soporte acumulados durante años de crecimiento orgánico, no por una elección deliberada. Para que quede claro: Como empresa open source, no estamos aquí para decirte que los monocultivos son siempre la solución. La heterogeneidad tiene ventajas reales. Puede reducir los modos de fallo compartidos y limitar el radio de impacto de una única clase de defecto. Parte de esa diversidad es intencional y justificable.

Sin embargo, en las grandes empresas, mucha no lo es. Es deuda técnica. Es la instancia de Ubuntu que alguien activó para un proyecto en 2019 y que ahora ejecuta algo crítico. Es el sistema CentOS que nadie parcheó tras el anuncio del fin de vida útil (EOL). Es el Windows XP que nadie sabe muy bien qué hace, pero si se desconecta, tienes problemas.

Una vez que hayas estandarizado la capa del hipervisor, el siguiente paso natural es analizar el entorno del sistema operativo guest. Ejecutar Red Hat Enterprise Linux (RHEL) junto con Red Hat OpenShift te ofrece un modelo operativo más coherente: gestión de parches unificada, planes de soporte coherentes y una aplicación de políticas que realmente funciona en todo tu entorno. La encuesta 2024 Global Tech Trends de Red Hat reveló que el 45 % de las empresas sitúa la modernización de su stack de aplicaciones al principio de su lista. Las iniciativas de modernización que funcionan siguen el mismo principio: eliminar la diversidad de sistemas operativos injustificada y mantener los que tienen un caso de negocio válido.

Etapa 2: Deja de gestionar la nueva plataforma como la anterior

Este es el error que vemos más a menudo. Los equipos completan una migración y siguen gestionando el nuevo entorno exactamente igual que el anterior. Los mismos procesos manuales. Los mismos ciclos de parches basados en tickets. Los mismos cambios ad-hoc a través de una consola.

El entorno tras la migración es un lienzo en blanco. Probablemente sea la mejor oportunidad que tendrás para definir correctamente tu estrategia de automatización.

Con Red Hat Ansible Automation Platform, los equipos pueden pasar de semanas de trabajo manual a solo unas horas. Una vez listos los playbooks, el aprovisionamiento, los parches y el cumplimiento normativo se ejecutan solos.

Si tu equipo ya utiliza GitOps, Red Hat Advanced Cluster Management for Kubernetes aporta esa misma disciplina a la virtualización. Las políticas se convierten en código almacenado en Git. Se acabó el desajuste de la configuración gestionado desde la consola. Esto supone un control más estricto de los desajustes, implementaciones más rápidas y operaciones del Day 2 más predecibles.

Esta es la realidad: la automatización no es algo opcional en el camino a la modernización. Es lo que permite que las etapas posteriores sean posibles.

Etapa 3: Ejecuta las cargas de trabajo donde realmente correspondan

No todas las cargas de trabajo deben ser máquinas virtuales (VM) para siempre. Algunas se adaptan de forma natural a los contenedores. Pero el objetivo no es contenerizarlo todo. El objetivo es ejecutar cada carga de trabajo donde tenga más sentido.

OpenShift te permite gestionar VM y contenedores en la misma plataforma, así que no tienes que elegir entre "hacer un lift-and-shift de todo" o "reescribirlo todo como desarrollado para la nube". Esa falsa dicotomía ha desperdiciado muchísimo tiempo y dinero en el sector. PNC Bank es un buen ejemplo de cómo hacerlo de forma pragmática. Adoptaron nuevos estándares y redujeron el tiempo de entrega de 8 semanas a un objetivo de 10 días.

Muchos equipos se estancan en esta etapa. La tecnología no es lo difícil. Lo difícil es determinar qué cargas de trabajo se mueven, cuándo y en qué orden. Contar con alguien que ya haya pasado por esto puede marcar la diferencia entre un ciclo de modernización de 6 meses y uno de 13. El estudio de ForresterPágina disponible en Inglés (Español no está disponible) lo confirma. Una organización compuesta redujo su despliegue de OpenShift y la migración de VM de 13 meses a 7 gracias a la orientación de expertos.

Etapa 4: Piensa en la inteligencia artificial antes de que sea necesario

Con la inteligencia artificial pasa una cosa: nadie que la haya implementado con éxito la integró en una infraestructura que ya era un desastre. Gartner® afirma que el gasto mundial en inteligencia artificial sumará 2,5 billones de dólares en 2026.

No digo que planifiques la inteligencia artificial antes de terminar la migración. Pero los equipos que he visto hacerlo bien tenían algo a su favor: una infraestructura subyacente limpia y automatizada. Las cargas de trabajo de inteligencia artificial son exigentes con el cómputo, el almacenamiento y la observabilidad. Es mejor resolver eso en una plataforma nativa de Kubernetes estandarizada que desenredarlo tras años de crecimiento orgánico.

La migración te mueve. La modernización te transforma.

La migración te aleja de una plataforma en la que no querías estar. La modernización construye la plataforma que realmente necesitas. Son cosas fundamentalmente distintas, y en el espacio que las separa es donde reside el trabajo real (y el valor real).

Comunicado de prensa de Gartner, Gartner afirma que el gasto mundial en inteligencia artificial sumará 2,5 billones de dólares en 2026, 15-01-2026

GARTNER es una marca comercial de Gartner, Inc. y sus filiales.