Cómo hacer migración de máquinas virtuales paso a paso

La migración de máquinas virtuales se ha convertido en una tarea del día a día en cualquier departamento de sistemas mínimamente moderno. Ya no se trata solo de mover una máquina de un servidor a otro: hoy hablamos de pasar de clusters VMware locales a Azure o Google Cloud, cambiar de plataforma de virtualización (por ejemplo de VMware a KVM/VMmanager), o incluso reorganizar recursos dentro del mismo centro de datos para ganar rendimiento o resiliencia, y todo ello intentando reducir al máximo el tiempo de inactividad.

En este artículo vamos a ver, con bastante detalle, cómo hacer una migración de máquinas virtuales de forma ordenada, repasando los casos de uso, los tipos de migración (en frío y en caliente), los procesos concretos de plataformas como Azure Migrate y Google Cloud Migrate to Virtual Machines, y cómo afrontar cambios de hipervisor hacia soluciones como VMmanager. La idea es que tengas una guía clara, basada en prácticas reales, para minimizar riesgos y saber qué está pasando “por debajo del capó”.

Por qué migrar máquinas virtuales en un entorno empresarial

En un entorno corporativo, las cargas de trabajo cambian constantemente: picos de tráfico inesperados, nuevas aplicaciones, campañas de marketing que disparan las peticiones, mantenimiento de hardware, etc. No siempre es viable desplegar servidores físicos adicionales cada vez que algo se desmadra, así que la migración de máquinas virtuales se convierte en una pieza clave para redistribuir recursos de forma dinámica.

Uno de los motivos más habituales para mover VMs es realizar tareas de mantenimiento programado en los hosts físicos (actualizaciones de firmware, cambios de hardware, reubicación en racks, etc.). En vez de asumir tiempos de caída para los usuarios, se desplazan las máquinas virtuales a otros servidores durante la ventana de mantenimiento y luego se devuelven al host original si procede.

La migración de máquinas virtuales también es fundamental para garantizar una alta disponibilidad ante fallos inesperados. Si un servidor físico se avería o muestra síntomas de fallo inminente, poder mover rápidamente las VMs a otro host o a otra nube permite que los usuarios apenas noten el incidente, manteniendo las aplicaciones en marcha.

Otro caso crítico es la recuperación ante desastres. Muchas arquitecturas replican máquinas virtuales y su estado (discos y, en algunos casos, memoria) entre un sitio principal y un sitio de contingencia. Cuando se declara un desastre, las VMs se migran hacia la infraestructura de recuperación, reduciendo el tiempo total de inactividad y la pérdida de datos.

Además, migrar VMs suele ser mucho más práctico que mover sistemas operativos y aplicaciones de forma individual. Al hacer migración de máquinas virtuales completas, es posible trasladar sistemas operativos heredados y aplicaciones críticas desde servidores antiguos a hardware nuevo o a la nube sin rehacer todo desde cero, y muchas veces con impacto mínimo en los usuarios.

Tipos de migración de máquinas virtuales: en frío y en caliente

Cuando hablamos de mover máquinas virtuales entre hosts, cabinas de almacenamiento o incluso centros de datos, casi siempre distinguimos dos enfoques: la migración en frío y la migración en caliente. La diferencia clave es el estado de la VM durante el proceso.

Migración en frío

Una migración en frío implica mover una máquina virtual apagada o en suspensión a un nuevo host o a un nuevo datastore. Durante este proceso también se pueden reubicar los ficheros asociados (configuración, discos, snapshots), cambiarla de un switch virtual a otro o incluso de un centro de datos a otro distinto.

Este tipo de migración puede hacerse de forma manual o programada para ejecutarse en una ventana concreta, pero tiene una desventaja evidente: hay una interrupción clara del servicio porque la VM debe detenerse. Además, a menudo se requiere un cierto nivel de conocimientos avanzados del hipervisor, la red y el almacenamiento para no liarla con dependencias, rutas o permisos.

Migración en caliente

En la migración en caliente, la máquina virtual se traslada mientras sigue encendida, es decir, continúa prestando servicio mientras cambia de un host a otro. Herramientas como vMotion en VMware o las funciones de live migration de otros hipervisores permiten que la disponibilidad sea prácticamente continua durante este proceso.

El sistema se encarga de copiar la memoria, el estado de CPU y la información necesaria para que la VM “despierte” en el nuevo servidor casi sin que el usuario lo note. Por ejemplo, es posible mover una VM en ejecución entre hosts que comparten el mismo almacenamiento, algo muy habitual en entornos como Citrix Hypervisor o clústeres KVM con cabina compartida.

La gran ventaja de la migración en caliente es que libera al administrador de muchas tareas manuales y mantiene la aplicación prácticamente siempre disponible. Eso sí, requiere una infraestructura bien diseñada (latencias bajas, almacenamiento compartido, red adecuada) para que la operación sea segura y no degrade el rendimiento.

Migración de VMware locales o AVS a Azure con Azure Migrate

En escenarios de nube híbrida, uno de los casos más frecuentes es mover VMs de un entorno VMware on-premises o de Azure VMware Solution (AVS) hacia máquinas virtuales nativas de Azure. Para ello, Microsoft ofrece la herramienta Azure Migrate: Migración y modernización, que permite migraciones con agente y, cada vez más, migraciones sin agente (agentless) muy automatizadas.

El proceso con Azure Migrate incluye desde la fase de preparación del entorno hasta la replicación, pruebas de migración y el cutover final. A continuación se explica en detalle todo el flujo para que veas qué pasos hay que seguir y qué decisiones debes tomar en cada punto.

Requisitos previos para migrar VMs VMware a Azure

Antes de meterte de lleno en el proceso, necesitas cumplir una serie de prerrequisitos básicos en Azure y en tu entorno VMware. Si no los preparas, lo normal es que termines con errores de permisos o problemas de red en mitad del proyecto.

Lo primero es contar con una suscripción activa de Azure. Si no dispones de una, puedes crear una cuenta gratuita y, a partir de ahí, habilitar los servicios necesarios para la migración. Sin una suscripción, obviamente, no podrás desplegar nada.

A nivel de proyecto, Microsoft recomienda completar al menos un tutorial inicial para preparar Azure y VMware para la migración (configuración básica de redes, permisos, etc.). Además, es muy útil ejecutar el tutorial de evaluación de Azure Migrate para analizar las VMs VMware antes de migrarlas, aunque este paso no es estrictamente obligatorio.

En Azure Migrate tendrás que usar un proyecto ya creado o crear uno nuevo donde se centralizarán las evaluaciones y migraciones. Verifica también que la cuenta de Azure que vayas a usar tenga permisos suficientes para crear máquinas virtuales y escribir en discos administrados.

Para hilar fino con los permisos, es recomendable revisar la documentación específica de roles integrados de Azure y permisos requeridos por Azure Migrate (creación de proyecto, detección, evaluación y migración). Esto te evitará sorpresas al arrancar tareas automatizadas que luego no pueden crear recursos.

Configuración del dispositivo de Azure Migrate

La solución de migración de Azure utiliza un appliance ligero desplegado en VMware, que se encarga de descubrir las VMs, realizar evaluaciones y orquestar la replicación sin agente. Si ya hiciste la fase de evaluación, normalmente este dispositivo ya estará configurado y registrado en el proyecto.

Si aún no lo tienes, puedes desplegarlo de dos formas principales, en función de las restricciones de tu entorno y de si trabajas con nubes públicas estándar o entornos como Azure Government:

• Plantilla OVA: descargas la plantilla y la despliegas como una VM más dentro de vSphere. Es el método más directo cuando no tienes limitaciones especiales.
• Script de PowerShell: instalas el dispositivo en una máquina virtual VMware o en un servidor físico utilizando un script. Este enfoque se suele usar cuando no es posible o no conviene trabajar con OVA, o en entornos regulados específicos.

Una vez desplegada la máquina, verifica que se puede comunicar sin problemas con Azure Migrate: Server Assessment y Server Migration, completa la configuración inicial y regístrala en el proyecto de Azure Migrate correspondiente. Sin este registro, el portal no podrá asociar la información de detección y replicación con tu entorno.

Habilitar y configurar la replicación de las VMs

Con el dispositivo en marcha y la detección completa, el siguiente paso es activar la replicación de las máquinas virtuales VMware hacia Azure. Azure Migrate soporta hasta 500 replicaciones concurrentes, aunque en el portal solo puedes seleccionar 10 VMs por operación, por lo que conviene agruparlas en lotes.

Para iniciar la replicación, en tu proyecto de Azure Migrate entra en la sección de ejecución y elige la opción de Iniciar ejecución (Start migration). En el asistente, selecciona “Servers” o “Virtual Machines” como tipo de carga y “Azure VM” como destino del movimiento.

Después tendrás que decidir cómo seleccionar las cargas de trabajo: manualmente desde todo el inventario descubierto o partiendo de una evaluación previa, lo que puede simplificar la selección si ya tienes grupos y dependencias identificados.

En el método de detección, elige el dispositivo que corresponda al entorno de origen (en este caso, el appliance para VMware vSphere) y en “Modo de migración” marca la opción de migración sin agente. Posteriormente, selecciona las VMs que vas a replicar y el tipo de seguridad de máquina virtual de destino; Azure admite migrar a VMs con inicio seguro y TPM virtual (Trusted Launch), algo muy recomendable cuando la carga es compatible.

En la parte de configuración de destino, tienes que indicar la suscripción, la región objetivo y la cuenta de almacenamiento. Dentro de este paso también se define la red virtual y la subred de Azure en la que quedarán las VMs una vez completada la migración.

Otro aspecto clave son las opciones de disponibilidad. Puedes anclar las máquinas a zonas de disponibilidad concretas para distribuir nodos de una misma capa de aplicación entre distintas zonas, usar conjuntos de disponibilidad (si existen en el grupo de recursos de destino), o no aplicar ninguna opción extra si no es necesario. También deberás elegir el tipo de cifrado de disco: claves gestionadas por la plataforma, por el cliente o cifrado doble.

En cuanto a licenciamiento, Azure te permite indicar si quieres usar la Ventaja híbrida de Azure para máquinas Windows Server con Software Assurance o licencias activas. Si marcas que sí, podrás reducir costes aprovechando tus licencias existentes.

En la pestaña de cómputo, revisa cuidadosamente el nombre de la VM, el tamaño, el tipo de disco del sistema operativo y la configuración de disponibilidad. Si vienes de una evaluación previa, el asistente te propondrá tamaños recomendados; si no, Azure seleccionará el tamaño más parecido disponible en la suscripción. Siempre puedes ajustarlo manualmente según tus necesidades de CPU y RAM.

También tendrás que indicar cuál es el disco de sistema operativo (el de arranque) dentro de la VM origen, la zona de disponibilidad o el conjunto de disponibilidad destino y, si ya cuentas con reservas de capacidad, asociar la SKU de máquina virtual a una reserva para garantizar que habrá recursos disponibles cuando hagas el cutover.

En la pestaña de discos, eliges qué discos de la máquina quieres replicar y qué tipo de disco usarás en Azure (Premium v2, Ultra Disk, SSD estándar, HDD estándar o discos administrados Premium). Aprovecha para decidir dónde merece la pena pagar más por rendimiento y dónde basta un almacenamiento más sencillo.

Para finalizar la configuración inicial, puedes asignar etiquetas (tags) a las VMs, discos y NICs, algo muy útil luego a nivel de inventario, costes y automatización. Tras revisar todo, confirma la configuración y arranca la replicación inicial.

Seguimiento y supervisión de las migraciones en Azure Migrate

Una vez en marcha, es fundamental vigilar el progreso de la replicación y de las distintas fases de migración. Desde el portal, en la sección de ejecución del proyecto, puedes ver las migraciones agrupadas por aplicaciones o por cargas de trabajo, según te resulte más cómodo.

La operación se divide conceptualmente en tres fases: Preparación, Pruebas y Finalización. Cada servidor muestra además un estado: en curso, con error, pendiente de acción o completado. Durante la fase de preparación se está llevando a cabo la replicación inicial; en la fase de pruebas, ya hay replicación diferencial y se pueden lanzar migraciones de prueba; en la fase de finalización se efectúan los cutovers y la limpieza.

Mientras la replicación inicial está en curso, las VMs permanecen en fase de preparación y es posible detener, pausar o reanudar el proceso si hace falta. Cuando termina esa primera sincronización, las VMs pasan a fase de pruebas y es aquí donde deberías planear las pruebas de migración en una red de test que no interfiera con producción.

Si decides omitir las pruebas, puedes pasar directamente a la fase de finalización, aunque no es lo más prudente en cargas críticas. Una vez que la replicación diferencial se estabiliza y las pruebas han salido bien, puedes programar las migraciones definitivas (cutover) y, cuando todo está verificado, ejecutar la limpieza de recursos de migración.

Para un control más fino, Azure Migrate proporciona un cmdlet de PowerShell llamado Get-AzMigrateServerMigrationStatus. Con él puedes ver el tiempo restante de replicación en cada etapa, el progreso por disco, la velocidad de carga e incluso recomendaciones para acelerar la migración.

Desde Azure Cloud Shell, basta con abrir la consola, elegir PowerShell y ejecutar algo como:

Get-AzMigrateServerMigrationStatus -ProjectName «<nombre-proyecto>» -ResourceGroupName «<grupo-recursos>» -MachineName «<nombre-servidor>»

Si añades el parámetro -Expedite, el comando devuelve parámetros operativos del appliance y una lista priorizada de acciones sugeridas para reducir el tiempo restante de migración. También es posible lanzar el comando sin MachineName para ver el estado de todas las VMs del proyecto, o usar parámetros como -Health para obtener información detallada de errores, posibles causas y pasos de resolución.

Asimismo, puedes filtrar por ApplianceName para revisar el estado global de todos los servidores asociados a un dispositivo concreto de Azure Migrate, algo especialmente útil en despliegues grandes con varios appliances distribuidos.

Ejecutar una migración de prueba en Azure

Cuando la replicación diferencial está activa, es muy recomendable ejecutar al menos una migración de prueba por cada VM antes de realizar el cambio definitivo. El objetivo es validar que la máquina arranca correctamente en Azure, que la aplicación funciona y que no aparecen sorpresas con dependencias, firewall o DNS.

La migración de prueba consiste en crear una VM de Azure a partir de los datos replicados y ubicarla normalmente en una red virtual de pruebas, aislada del tráfico de producción. Las máquinas origen, tanto locales como en AVS, siguen funcionando y replicando datos durante todo el proceso, por lo que no se interrumpe el servicio.

Para lanzar la prueba, en el proyecto de Azure Migrate ve a la sección de migraciones, selecciona el servidor deseado y, desde el menú desplegable de pruebas, elige la opción de Iniciar migración de pruebas. A continuación selecciona la VNet de Azure donde se creará la VM de prueba y asigna las subredes adecuadas a cada NIC replicada.

Otra ventaja es que puedes aprovechar para actualizar Windows Server durante esta fase de test. Si la opción de actualización está disponible, elige la versión de sistema operativo de destino y aplica el cambio, de manera que valides ya en la prueba cómo se comporta la aplicación con la nueva versión.

Tras iniciar la migración de prueba, el portal mostrará el avance en el estado de ejecución. Una vez que termines de comprobar que todo funciona, no olvides limpiar los recursos creados y seleccionar la opción Limpiar migración de pruebas en el mismo menú de pruebas, para no dejar VMs de test consumiendo recursos y generando costes innecesarios.

Migración final (cutover) de las máquinas virtuales

Después de comprobar que las pruebas son satisfactorias, llega el momento de migrar definitivamente las VMs desde el entorno de origen hacia Azure. Este es el punto en el que se suele programar una ventana de mantenimiento, ya que normalmente implica apagar las máquinas de origen.

En la sección de migraciones del proyecto, selecciona el servidor objetivo y, en el menú de finalización, escoge la opción de Migrar. El asistente te preguntará si quieres apagar las VMs de origen para realizar una migración planificada sin pérdida de datos; si eliges “Sí”, Azure Migrate apagará la máquina, ejecutará una replicación bajo demanda con los cambios recientes y garantizará que no se pierda información.

Si por alguna razón no deseas apagar la VM origen, puedes seleccionar “No”, aunque esto suele implicar mayor riesgo o mayor cuidado con la sincronización de datos. También puedes volver a aprovechar esta fase para actualizar Windows Server durante la migración, eligiendo la versión de destino adecuada.

Si tienes reservas de capacidad para la SKU de VM que vas a usar en la región de destino, conviene vincularlas aquí para asegurarte de que habrá recursos garantizados justo en el momento del cutover. Una vez que confirmes todo, se lanza el trabajo de migración y puedes seguir su progreso en las notificaciones de Azure y en la propia vista de migraciones.

Cuando el trabajo termina, la máquina queda disponible como VM de Azure completamente gestionable desde el portal, y su estado dentro de Azure Migrate pasará a la fase de finalización para que puedas completar los pasos de cierre.

Completar y rematar la migración en Azure

Con la VM ya funcionando en Azure, aún quedan varios pasos para cerrar correctamente la migración y dejar el entorno limpio y bien documentado. Lo primero es indicar a Azure Migrate que la migración ha finalizado para esa máquina, usando la opción Completar migración en el menú de finalización.

Al completar la migración, se detiene la replicación desde el origen y se limpia el estado de seguimiento de la máquina dentro de Azure Migrate. Durante este proceso, Azure instala de forma automática el agente de VM para Windows y Linux en las nuevas máquinas, facilitando así su gestión posterior (monitorización, extensiones, etc.).

Después deberías comprobar si la activación de Windows en la VM de Azure se ha realizado correctamente y resolver cualquier aviso. Es un buen momento también para ajustar configuraciones de aplicación: nombres de host, cadenas de conexión de base de datos, rutas internas, configuración del servidor web, reglas de firewall y cualquier otro parámetro dependiente del entorno.

A nivel funcional, es importante llevar a cabo pruebas finales de la aplicación y una validación por parte del negocio. Una vez que todo el mundo dé el visto bueno, podrás redirigir el tráfico de forma definitiva hacia la nueva instancia en Azure (cambios de DNS, reconfiguración de balanceadores, actualización de endpoints en aplicaciones cliente, etc.).

Solo entonces deberías eliminar las máquinas virtuales de origen del inventario local y de las soluciones de backup on-premises, asegurándote antes de que no quede ningún servicio o dependencia colgando. No olvides actualizar toda la documentación interna para reflejar la nueva ubicación, IPs y particularidades de las VMs que ahora residen en Azure.

Buenas prácticas después de migrar a Azure

Más allá de que la VM arranque y funcione, conviene aplicar una serie de procedimientos recomendados post-migración para reforzar la resiliencia, el rendimiento y la seguridad de las cargas que acabas de mover a la nube.

En primer lugar, calcula cómo vas a manejar la protección de datos. Azure Backup permite realizar copias de seguridad de las VMs de forma centralizada y gestionar la retención de manera flexible. Para protegerte frente a desastres regionales, podrías replicar las VMs a otra región mediante Azure Site Recovery, logrando así una capa adicional de continuidad de negocio.

En el plano de rendimiento, revisa la configuración de caché de los discos de datos. Por defecto, muchos discos se crean con la caché en “None”, pero según el tipo de carga (bases de datos, aplicaciones transaccionales, servidores de archivos, etc.) puede ser conveniente cambiar esta configuración para obtener un rendimiento óptimo.

La seguridad y la supervisión continua son igualmente clave. Es recomendable integrar las VMs con herramientas de monitorización y gestión de costes como Microsoft Cost Management para vigilar el consumo, así como emplear soluciones de logging centralizado, alertas y análisis de seguridad que te permitan reaccionar rápido ante anomalías.

Por último, es útil revisar el Azure Cloud Adoption Framework, donde se describe el recorrido completo de adopción de nube en Microsoft, desde la estrategia hasta la gobernanza y la operación, lo que te puede ayudar a encajar tu proyecto de migración de VMs dentro de una iniciativa más amplia.

Migración de VMs a Google Cloud con Migrate to Virtual Machines

Si tu objetivo es llevar máquinas virtuales desde tu entorno actual (por ejemplo, un centro de datos VMware) a Google Cloud, la solución nativa es Migrate to Virtual Machines, enfocada a migraciones de tipo lift-and-shift con mínimas modificaciones automáticas sobre las VMs destino.

Esta herramienta se integra directamente en la consola de Google Cloud y usa un mecanismo continuo de replicación de datos que replica los discos de las VMs origen mientras estas siguen en funcionamiento. Sobre esos datos replicados se crean VMs de prueba, clones y finalmente la instancia de producción en Compute Engine.

Fases del proceso de migración en Google Cloud

Migrate to Virtual Machines estructura el proceso de migración en varias fases muy claras: incorporación, replicación, definición del objetivo, clon de prueba, cambio (cutover) y finalización. El flujo es bastante lógico y permite validar cada paso antes de avanzar.

En la fase de incorporación, seleccionas las máquinas virtuales origen que quieres migrar. En un entorno vSphere, por ejemplo, la consola de Google Cloud mostrará todo el inventario del centro de datos, y tú eliges solo las VMs que te interesa mover, añadiéndolas al proyecto de migración.

Después se inicia la fase de replicación, en la que se copian los datos de los discos de la VM de origen hacia Google Cloud sin detener la máquina. La replicación es continua y se ejecuta en segundo plano, minimizando el impacto en la producción. Esta fase consta de un primer paso de replicación completa (snapshot inicial de los discos) y sucesivos pasos incrementales, que se ejecutan cada cierto tiempo (por defecto, cada dos horas) usando mecanismos de seguimiento de bloques cambiados (CBT).

Una vez que la replicación está en marcha, defines los detalles de la VM de destino en Compute Engine: proyecto, zona, tipo de instancia, memoria, redes, etc. Estos parámetros se pueden modificar en cualquier momento y serán los que se usen al crear clones de prueba o la VM final de producción.

La siguiente fase es la de clon de prueba. En cualquier momento tras completar la replicación inicial puedes crear una VM de prueba en Compute Engine a partir de los datos replicados y los ajustes de destino. Este clon es un snapshot estático de la máquina origen en ese momento y sirve para validar el comportamiento en Google Cloud sin tocar la VM original.

En la fase de cambio (cutover), cuando ya has probado todo lo que necesitas, Migrate to Virtual Machines detiene la VM de origen, realiza una última replicación para sincronizar los cambios finales y crea la instancia definitiva de Compute Engine que sustituirá al servidor original. Es en este momento cuando se produce la ventana de mantenimiento, ya que la VM origen se apaga para evitar divergencias de datos.

Por último, en la fase de finalización se realiza la limpieza de datos de replicación y recursos temporales asociados a la migración. Es importante tener en cuenta que, hasta que no elimines estos datos, seguirás pagando por el almacenamiento que ocupan, por lo que conviene completar esta fase una vez verificado que la VM migrada funciona correctamente a largo plazo.

Adaptaciones del sistema operativo en Google Cloud

Para que las VMs migradas se comporten correctamente en Google Cloud, no basta con copiar discos tal cual; es necesario realizar una serie de adaptaciones del sistema operativo que se aplican automáticamente al final de cada paso de replicación.

Entre estas adaptaciones están cambios en la configuración de red, instalación del agente de Compute Engine y habilitación de la consola serie. El tipo exacto de ajustes depende de si la máquina es Linux o Windows, pero el objetivo es siempre el mismo: que la VM arranque y se integre correctamente en la infraestructura de Google Cloud sin que tengas que hacer demasiados apaños manuales.

Durante las pruebas, es fundamental aislar el clon de prueba del entorno de producción, ya que la VM origen sigue ejecutándose y replicando datos. De lo contrario, podrías tener dos instancias activas del mismo servicio respondiendo a clientes y generando inconsistencias.

Escenarios de éxito y reversión en Google Cloud

Durante la fase de cambio, pueden darse varios escenarios que hay que tener claros desde el principio. Si el cutover falla por algún motivo técnico (problema de red, errores de configuración, etc.), la VM origen habrá sido detenida pero la replicación final seguirá siendo válida. En este caso, lo normal es revisar la causa del fallo y reintentar el cambio.

Si el cambio se completa pero la nueva VM en Compute Engine no funciona correctamente, puedes optar por una reversión: detienes y eliminas la instancia problemática en la nube, vuelves a arrancar la VM de origen y rediriges el tráfico de nuevo hacia ella. No es un proceso completamente automático, así que hay que planificarlo con cuidado, especialmente en lo que se refiere a datos que se hayan escrito en la instancia fallida y que no se replicarán de vuelta al origen.

Cuando el resultado es satisfactorio y la VM en Compute Engine rinde como esperabas, la migración se considera completada desde el punto de vista operativo. A partir de ahí ya puedes optimizar la instancia, ajustar tipos de máquina, discos y redes, y preparar el cierre de la migración con la fase de finalización y la limpieza de datos replicados.

Migrar VMs a plataformas de virtualización rusas: ejemplo con VMmanager

En ciertos países se están impulsando políticas de sustitución de software extranjero por soluciones nacionales. Esto ha generado situaciones en las que algunos clientes siguen usando productos internacionales, pero con riesgos claros: problemas para renovar licencias, prohibiciones de actualización, pérdida de soporte oficial e incluso posibles sanciones adicionales.

Para reducir esos riesgos, muchas organizaciones valoran la transición hacia plataformas de virtualización locales como VMmanager. Se trata de una solución madura, pensada tanto para pequeñas instalaciones como para grandes infraestructuras, y permite consolidar VMs procedentes de distintos hipervisores sin necesidad de herramientas de migración extremadamente complejas.

La documentación oficial de VMmanager explica con bastante detalle el proceso de importar VMs desde Hyper-V, VirtualBox, VMware, Xen y otras plataformas basadas en QEMU-KVM. El enfoque típico se divide en cuatro pasos: preparar la VM para la migración, preparar el entorno VMmanager, transferir los discos de la máquina y arrancarla en el nuevo hipervisor.

Durante la preparación de la VM, normalmente hay que ajustar controladores, eliminar herramientas específicas del hipervisor anterior (por ejemplo, las VMware Tools) y dejar la configuración de red en un estado que permita reconfigurarla fácilmente en el destino. Luego se configura VMmanager para recibir esas VMs, se copian los discos (vmdk, vhdx, qcow2, etc.) al almacenamiento de la plataforma y se crea una ficha de máquina virtual apuntando a esos discos.

Si en algún momento el proceso se complica, los administradores pueden apoyarse en el soporte técnico de VMmanager, cuyos ingenieros suelen ayudar a resolver incompatibilidades y a pulir detalles de la migración para que el traspaso resulte lo más suave posible.

Probar migraciones mediante conversión de discos

En muchos entornos, especialmente cuando se trabaja con almacenamiento basado en QEMU-KVM o sistemas de ficheros específicos, se recurre a migraciones de prueba que se centran en la conversión del formato de disco virtual y en la creación de VMs temporales para validar el proceso.

Un enfoque habitual consiste en convertir discos VMDK al formato nativo del nuevo entorno y levantar máquinas virtuales a partir de esos discos convertidos, ubicándolos en el qtree o volumen designado para tal fin. Esta metodología simula la migración real sin afectar a la VM de producción original.

Estas pruebas permiten comprobar si el sistema operativo arranca correctamente tras la conversión, si los drivers necesarios están disponibles, si la red se configura sin problemas y si hay que realizar cambios adicionales (instalar agentes, reconfigurar servicios, etc.). Solo cuando la migración de prueba se considera estable y libre de errores se plantea pasar a la migración definitiva.

Planificar y ejecutar bien estas pruebas reduce de forma drástica el riesgo de encontrar sorpresas desagradables durante una ventana de mantenimiento real, tanto si migras a una nube pública como si cambias de plataforma de virtualización on-premises.

La migración de máquinas virtuales, ya sea entre hosts locales, hacia nubes públicas como Azure o Google Cloud o hacia nuevas plataformas como VMmanager, es un proceso que exige planificación, pruebas y una buena comprensión de las fases de replicación, adaptación del sistema operativo y cutover. Siguiendo las prácticas descritas, apoyándote en herramientas nativas de cada proveedor y validando siempre con migraciones de prueba, puedes cambiar la infraestructura subyacente sin que los usuarios apenas noten el movimiento y, de paso, ganar en resiliencia, rendimiento y capacidad de crecimiento.