Salir de VMware: por dónde empezar

Casi todos los proyectos de salida de VMware que nos llegan empiezan por el mismo lado: alguien corrió los números del licenciamiento, el ahorro salió bien, y la pregunta que traen es cuál arquitectura conviene.

Es la tercera pregunta, no la primera. Y el problema de contestarla antes de tiempo no es académico: significa que el bloqueo aparece cuando ya hay presupuesto aprobado y una fecha comprometida.

Estas son las siete decisiones, en el orden en que hay que tomarlas. Cada una está desarrollada aparte; aquí está para qué sirve cada una y por qué va donde va.

1 · ¿Conviene migrar?

No siempre. Hay entornos donde VMware sigue teniendo sentido, normalmente por dependencias funcionales que no tienen equivalente directo y por contratos que todavía no vencen. El ahorro de licenciamiento es real, pero no es el único número de la ecuación.

Esta es la única decisión que se puede tomar sin tocar un servidor, y la única que se puede revertir sin costo. Está desarrollada en ¿VMware o Proxmox VE?.

2 · ¿Se puede migrar?

Aquí es donde la secuencia se rompe casi siempre, porque esta pregunta no parece una decisión — parece un detalle de implementación. No lo es: es una compuerta.

Un host arranca ESXi o arranca Proxmox, nunca los dos. Para convertirlo hay que vaciarlo, y la carga de ese host tiene que caber en los que quedan. Eso solo pasa si el uso de memoria por host está por debajo de (N−1)/N: 66% con tres hosts, 50% con dos, cero con uno.

Si tu entorno no cumple, la migración no es imposible — pero deja de ser un proyecto de software y necesita hardware temporal. La aritmética completa y cómo se dimensiona ese hardware están en si tus hosts están al 80%, no puedes migrar a Proxmox.

Ponla aquí, no al final. Es la única de las siete que puede convertir un proyecto aprobado en un proyecto que no se puede hacer como se planteó.

3 · ¿Sobre qué arquitectura?

Hiperconvergencia o servidores más un arreglo. Es la decisión que amarra el presupuesto y la forma de crecer por los siguientes cinco años, y la que más cuesta deshacer: cambiar de modelo a mitad del camino significa comprar dos veces.

Va después de la compuerta porque el hardware temporal, si hace falta, puede terminar siendo el primer nodo del modelo nuevo. Decidir la arquitectura sin saber si va a haber equipo prestado en medio es decidir con información incompleta. Está en hiperconvergencia contra servidores + SAN.

4 · ¿Qué almacenamiento?

En un clúster Proxmox el almacenamiento define casi todo: rendimiento, resiliencia y presupuesto. Ceph escala y sobrevive fallos, pero pide tres nodos para producción y más disciplina operativa de la que muchos esperan.

Y hay un detalle que conecta con la decisión 2: el destino Proxmox necesita almacenamiento propio de todos modos, porque no puede montar el VMFS mientras ESXi lo tenga tomado. La comparación está en Ceph contra almacenamiento compartido en Proxmox.

5 · ¿De qué tamaño?

Es donde más dinero se tira, y en las dos direcciones: comprar de más por si acaso, o quedarse corto y estrangular todo.

Una advertencia que vale más que cualquier fórmula: la densidad de memoria que consigues hoy en ESXi no está garantizada en Proxmox. Las dos plataformas reclaman memoria de forma distinta. Dimensiona sobre consumo real más holgura, nunca sobre la sobresuscripción que ya traes. El método está en dimensionar CPU, RAM y disco para virtualizar, y hay una calculadora de dimensionamiento gratuita para la primera pasada.

6 · ¿Cuánta alta disponibilidad?

Esta es la que normalmente contesta quien está cotizando, y por eso suele salir más grande de lo necesario. "Necesitas un clúster de alta disponibilidad" es una frase que precede a cotizaciones muy grandes y, a veces, a compras que no hacían falta.

La pregunta útil no es si quieres alta disponibilidad —todo mundo quiere— sino cuántos minutos de caída tolera cada carga, y cuáles de verdad. Qué se necesita y qué se vende está en clúster Proxmox de alta disponibilidad: qué necesitas de verdad.

7 · ¿Cómo se ejecuta?

Hasta aquí todo era decisión. Esta es la única parte que es procedimiento, y es la que la mayoría quiere leer primero.

El orden de las oleadas, qué se valida antes de cada corte, cómo se conserva la capacidad de regresar. Está en el checklist de migración que seguimos.

Por qué el orden importa más que las respuestas

Cada una de las siete tiene una respuesta razonable que depende de tu entorno, y en ninguna hay una recomendación universal. Lo que sí es universal es la dependencia entre ellas.

La secuencia que vemos en la práctica es 1 → 3 → 5 → 7, y la 2 aparece cuando el equipo técnico intenta ejecutar. En ese punto ya se firmó el hardware, ya se comprometió la ventana y ya se anunció la fecha en el comité. La compuerta no desaparece por haberla saltado: solo se vuelve más cara.

La 6 tiene el problema opuesto. Al no estar en la lista de nadie, la contesta por omisión quien manda la cotización, y la respuesta por omisión nunca es la barata.

Lo que no resuelve esta ruta

No cubre las dependencias funcionales que no tienen equivalente en Proxmox. Si tu operación depende de características exclusivas del ecosistema de VMware, eso se evalúa en la decisión 1 y puede cerrar el proyecto ahí mismo — que es exactamente para lo que sirve tenerla de primera.

Tampoco cubre el día después. Migrar es un proyecto con fecha de fin; operar la plataforma nueva no la tiene, y el equipo que la va a operar rara vez es el que la migró.

Por dónde empezar hoy

Si vas a leer una sola de las siete, lee la 2. Es la que puede ahorrarte descubrir un bloqueo con presupuesto ya comprometido.

Y si quieres el diagnóstico sin leer nada, nuestro VMware Migration Assessment recorre las siete decisiones con las respuestas de tu entorno y te dice, con número, si necesitas hardware temporal y de qué tamaño. Es gratuito y entrega el resultado antes de pedir cualquier dato.

El panorama de la plataforma está en Proxmox VE para empresas, y cómo acompañamos el proyecto completo en migración de VMware a Proxmox VE.