10 Errores de Arquitectura y ROI en la Migración Post-VMware
10 Errores de Arquitectura y ROI que Nadie Evaluó en la Huida Post‑VMware
Las alternativas open source son viables. Pero “viable” y “adecuado para tu negocio” son preguntas radicalmente distintas que exigen análisis técnico, financiero y de gobernanza antes de comprometer tu infraestructura una década.
Error 01 de 10
Confundir urgencia con estrategia
La adquisición de VMware por Broadcom en noviembre de 2023 por 61.000 millones de dólares desencadenó la mayor sacudida en virtualización empresarial de la última década. Y cuando decimos sacudida, nos quedamos cortos. Licencias perpetuas eliminadas, ~8.000 SKUs consolidados en 4 bundles, mínimo de compra de 72 cores y subidas de precio reportadas entre el 150 % y el 1.500 %. Tesco presentó una demanda de 100 millones de libras. Fidelity advirtió de riesgos para 50 millones de clientes. Vamos, que el panorama invitaba a salir corriendo.
Y eso es exactamente lo que ha pasado: mucha gente ha salido corriendo, pero no siempre en la dirección correcta. Una encuesta de CloudBolt (2026) reveló que el 63 % ha cambiado su estrategia de migración al menos dos veces (sí, dos veces). Gartner estima que la cuota de VMware caerá del 70 % al 40 % para 2029, pero el camino hasta allí está lleno de curvas que merecen bastante más reflexión de la que están recibiendo.
Perspectiva SIXE
La urgencia que genera Broadcom es totalmente comprensible —a nadie le gusta que le multipliquen la factura de un día para otro. Pero cada decisión de infraestructura tomada bajo presión se convierte en deuda técnica que los equipos heredarán durante años. La primera decisión correcta es separar la respuesta táctica inmediata de la estrategia a medio plazo y evaluar ambas con criterios diferentes. Respira, planifica y luego actúa.
Error 02 de 10
Ignorar la gobernanza del proyecto open source
No todo el open source es igual, ni mucho menos. La diferencia más relevante para una decisión empresarial a largo plazo no es la licencia, sino algo que casi nadie mira: quién controla el proyecto y qué mecanismos protegen a la comunidad si las prioridades comerciales cambian.
Proxmox Server Solutions GmbH es una empresa privada austriaca con un capital social de 35.000 € y un equipo estimado de 14–24 personas. Gente estupenda, seguro, pero no existe fundación independiente, ni consejo de gobernanza abierto, ni representación comunitaria en las decisiones de desarrollo. Es decir: el futuro de tu plataforma depende de las decisiones de una sola empresa.
Contrástese con la MariaDB Foundation, donde ninguna empresa puede ocupar más del 25 % de los asientos del consejo — un mecanismo que protegió al proyecto cuando MariaDB Corporation fue adquirida por K1 en septiembre de 2024. O con OpenStack, ahora bajo la Linux Foundation, con gobernanza distribuida entre cientos de organizaciones. Eso sí que es un colchón de seguridad.
Pregunta clave
¿Tu plataforma de virtualización —esa sobre la que van a correr tus aplicaciones de negocio los próximos 10 años— está controlada por una fundación independiente, un consorcio o una única empresa privada de menos de 25 empleados? No es una pregunta retórica: la respuesta tiene implicaciones directas sobre el riesgo a largo plazo.
Error 03 de 10
No leer el Contributor License Agreement
Lo sabemos, leer un CLA no es exactamente un plan de viernes noche. Pero merece la pena. El CLA de Proxmox otorga a la compañía una licencia perpetua, mundial e irrevocable sobre todas las contribuciones, con derecho a relicenciarlas bajo términos comerciales o propietarios. Este mecanismo no es inherentemente problemático, pero es exactamente la combinación estructural (empresa única + AGPL + CLA permisivo) que precedió a cada cambio de licencia relevante de los últimos siete años. Es como ver las nubes de tormenta y decir “seguro que no llueve”.
| Proyecto | Año | Cambio | Consecuencia | Gobernanza |
|---|---|---|---|---|
| MongoDB | 2018 | AGPL → SSPL | Dropped by Debian/Red Hat | Single vendor |
| Elasticsearch | 2021 | Apache 2.0 → SSPL | Fork: OpenSearch (Linux Foundation) | Single vendor |
| HashiCorp | 2023 | MPL 2.0 → BSL | Fork: OpenTofu · IBM: $6.4B | Single vendor |
| Redis | 2024 | BSD → SSPL | Fork: Valkey (Linux Foundation) | Single vendor |
| MinIO | 2021–26 | Apache → AGPL → Abandoned | Repo: “NO LONGER MAINTAINED” | Single vendor |
| Kubernetes | — | — | Apache 2.0 stable | Foundation (CNCF) |
| PostgreSQL | — | — | PostgreSQL License stable | Community |
| Linux | — | — | GPLv2 stable | Foundation (LF) |
¿Ves el patrón? Es bastante claro: ningún proyecto respaldado por una fundación independiente ha sufrido un cambio de licencia unilateral. Ni uno. Este dato debería informar cualquier evaluación de riesgo, independientemente de la plataforma que estés considerando.
Error 04 de 10
Asumir que los costes de suscripción se mantendrán
Toda empresa que desarrolla software open source necesita monetizar su trabajo, y eso es completamente legítimo — nadie vive del aire. La cuestión no es si habrá subidas de precio (las habrá, como en todo), sino si las estás incluyendo en tu modelo de TCO.
La suscripción Community de Proxmox pasó de 49,90 € a 120 €/año (~140 % de incremento), y en enero de 2026 todos los tiers subieron otro 3,8–4,3 %. El nuevo Proxmox Datacenter Manager requiere que al menos el 80 % de los nodos tengan suscripciones Basic o superiores (370+ €/socket/año). ¿Te suena familiar? A nosotros un poco también.
OpenStack, Ceph y otras alternativas también tienen estructuras de coste propias. Ninguna plataforma es gratuita en producción — si alguien te dice lo contrario, desconfía amablemente. La diferencia está en qué costes son predecibles y cuáles dependen de decisiones unilaterales.
Perspectiva SIXE
Cuando evaluamos alternativas con nuestros clientes, siempre modelamos tres escenarios de coste: optimista, realista y adverso, con proyecciones a 5 y 10 años que incluyen posibles cambios en la estructura de licenciamiento. Sí, es más trabajo. Pero también es la única forma de hacer un TCO que no se desmorone al primer cambio de precios.
Error 05 de 10
Subestimar la complejidad operacional de OpenStack
Vamos a ser justos con OpenStack: opera en producción con más de 45 millones de cores en organizaciones como Walmart, GEICO o LINE Corp. Su gobernanza —ahora bajo la Linux Foundation— es de las más sólidas del ecosistema. Estas son ventajas reales y de peso.
Pero (siempre hay un pero) el propio proyecto reconoce que el 44 % de los proveedores IT y el 39 % de las empresas reportan dificultad para encontrar profesionales cualificados. La plataforma comprende más de 30 proyectos de servicio. Desplegar y operar ese stack requiere equipos con experiencia en sistemas distribuidos que la mayoría de los equipos VMware no poseen —no por falta de talento, sino porque son conjuntos de competencias fundamentalmente distintos. Es como pedirle a un gran chef de cocina mediterránea que prepare sushi de competición: ambos son cocina de alto nivel, pero las habilidades no se transfieren automáticamente.
Matiz importante
OpenStack puede ser la elección perfecta para organizaciones con la escala y los equipos adecuados. El modelo gestionado (Canonical, Mirantis, Platform9) resuelve parte de la complejidad, aunque añade costes y dependencia. La pregunta no es “¿OpenStack sí o no?” sino “¿nuestro equipo, presupuesto y escala encajan con lo que OpenStack necesita para brillar?”
Error 06 de 10
Asumir que Ceph es “solo activar el checkbox”
Ceph es un sistema potente y está en producción en sitios impresionantes: CERN, Bloomberg y DigitalOcean, entre otros. Pero la distancia entre un clúster Ceph a hiperescala y uno de 3–5 nodos típico de una migración VMware es como la distancia entre pilotar un Airbus y un ultraligero: ambos vuelan, pero las reglas son muy diferentes.
Los benchmarks de StarWind en entornos Proxmox HCI muestran que Ceph alcanzó 270.000 IOPS en cargas mixtas 4K, frente a 1.088.000 IOPS de LINSTOR/DRBD y 1.199.000 de StarWind VSAN. Y los riesgos de los clústeres pequeños merecen atención especial: perder un nodo en un clúster de 3 con replicación 3x puede dejar el sistema en solo lectura. No es el mejor escenario a las 3 de la madrugada de un lunes.
Existen alternativas interesantes: LINSTOR/DRBD con rendimiento cercano al nativo, StorPool con latencias sub-100 µs, IBM Storage Virtualize con integración enterprise probada. Cada opción tiene sus fortalezas, limitaciones y requisitos de expertise.
Perspectiva SIXE
La capa de storage es posiblemente la decisión más crítica y menos reversible de toda la migración. Es donde no te puedes permitir improvisar. Debe evaluarse con pruebas reales sobre cargas de trabajo reales, no con benchmarks genéricos ni con “a fulanito le va fenomenal”. Es precisamente donde un integrador con experiencia en múltiples plataformas de almacenamiento aporta más valor.
Error 07 de 10
No inventariar las funcionalidades enterprise que desaparecen
VMware lleva más de una década construyendo funcionalidades sobre las que muchas organizaciones han diseñado sus procesos operativos. Son esas cosas que “simplemente funcionan” hasta que dejan de estar ahí. Y cuando desaparecen, el impacto va mucho más allá de lo tecnológico.
Balanceo automático (DRS)
Proxmox no tiene equivalente nativo: toca scripting propio. OpenStack ofrece funcionalidad parcial con Nova scheduling. En ambos casos, prepárate para arremangarte.
Fault Tolerance y DR
VMware FT/SRM proporcionan failover automático. Las alternativas open source requieren orquestación propia con ZFS replication, Ansible y runbooks manuales. Funciona, pero alguien tiene que construirlo y mantenerlo.
SDN y microsegmentación
Proxmox SDN soporta VLANs/VXLANs/EVPN, pero IPAM/DHCP están en “tech preview” (léase: todavía no está listo del todo). No existe equivalente al firewall distribuido de NSX.
Certificaciones de vendor
SAP, Oracle y Microsoft no certifican Proxmox. NVIDIA AI Enterprise tampoco está soportado oficialmente. Si dependes de estas certificaciones, es un detalle que conviene no pasar por alto.
Automatización y API
Los providers de Terraform para Proxmox son comunitarios. La API requiere especificar el nodo de destino manualmente. Nada insalvable, pero son fricciones que suman.
Soporte 24/7
Proxmox opera en horario austriaco (7:00–17:00 CET), sin opción 24/7 a ningún nivel. Cuando producción cae a las 3 AM, literalmente no hay a quién llamar. Y no, Google no cuenta.
Ninguna de estas limitaciones invalida la plataforma — que quede claro. Pero cada una representa un hueco que hay que cubrir con ingeniería, herramientas o consultoría, y cada solución tiene un coste que debe figurar en el modelo financiero. Hacer como que no existen es la receta perfecta para sorpresas desagradables.
Error 08 de 10
Calcular el ROI solo con la línea de licenciamiento
El ahorro en licencias es real. Pero presentar ese ahorro como el ROI del proyecto es como valorar una mudanza solo por lo que cuesta el camión: técnicamente correcto, prácticamente incompleto.
Gartner estima que los servicios de migración cuestan entre 300 y 3.000 dólares por VM. El 44 % de las organizaciones sufre downtime no planificado durante la migración. Y los proyectos estimados en 6 meses se convierten en 24 con una frecuencia que ya nadie debería ignorar.
Los costes ocultos que erosionan el ROI
Formación: 5.000–15.000 $/técnico + 3–6 meses de productividad reducida (tu equipo aprende rápido, pero no es instantáneo). Integración: backup, monitorización, CMDB, automatización — conectores maduros para VMware que no existen para Proxmox. Desarrollo custom: scripts de balanceo, DR, monitorización = deuda técnica interna. Rotación: cuando el ingeniero que los construyó se marcha, el conocimiento se va con él. Y siempre se marcha en el peor momento.
Error 09 de 10
Diseñar para el Día 1 e ignorar el Día 2
La migración es solo el principio — la luna de miel, si quieres verlo así. El coste real se manifiesta en las operaciones del día a día durante años.
Cybernews reveló que muchas organizaciones que migraron a Proxmox no mantienen las actualizaciones de seguridad. Es comprensible: cuando todo el esfuerzo se concentra en migrar, es fácil olvidar que después hay que mantener. A escala, la UI se vuelve poco responsiva con varios miles de VMs y pmxcfs alcanza sus límites en torno a 11.000 VMs.
Seguridad y compliance
Gestión de CVEs, hardening, auditorías (ENS, ISO 27001, PCI DSS). ¿Qué SLA de respuesta ante vulnerabilidades críticas ofrece cada plataforma? Pregunta incómoda pero necesaria.
Telemetría y observabilidad
Las alternativas open source (Prometheus, Grafana, Zabbix) son excelentes — de verdad que lo son — pero requieren integración y mantenimiento dedicado. No se configuran solas.
Backup y recuperación
Proxmox Backup Server es funcional pero juega en otra liga de ecosistema comparado con Veeam, Commvault o IBM Spectrum Protect.
Deuda técnica
Cada script custom es código que hay que mantener, documentar, testear y transferir. La deuda técnica es invisible hasta que no lo es — y entonces es lo único que ves.
Error 10 de 10
Creer que la tecnología es la decisión
La migración desde VMware no es un proyecto tecnológico: es una transformación operacional que afecta a personas, procesos, proveedores, presupuestos y riesgos. La tecnología es importante, por supuesto. Pero es solo una pieza del puzzle.
La migración de VMware no es un problema tecnológico. Es un problema de desacoplamiento operacional disfrazado de problema tecnológico.— Keith Townsend, The CTO Advisor
Las preguntas que realmente importan: ¿qué nivel de riesgo de gobernanza es aceptable para nosotros? ¿Tenemos el equipo necesario — o podemos formarlo a tiempo? ¿Cuál es nuestro TCO real a 5 y 10 años? ¿Cómo protegemos la inversión si el proyecto open source cambia de rumbo? ¿Qué cargas de trabajo migramos primero y cuáles quizá nunca deberían moverse? ¿Y quién será nuestro partner técnico cuando las cosas no funcionen como esperábamos? (Porque en algún momento, no funcionarán como se esperaba. Así es la vida.)
Nuestra convicción
El open source es, sin duda, la respuesta correcta para la infraestructura del futuro. De eso no tenemos ninguna duda. La cuestión no es si migrar, sino cómo hacerlo con el rigor que la decisión merece. La diferencia entre una migración exitosa y una que genere años de quebraderos de cabeza está en la calidad del análisis previo, la arquitectura elegida y el acompañamiento experto durante todo el proceso. Y oye, si después de leer todo esto te apetece hablar, aquí estamos.
La mejor migración es la que se hace con criterio, no con prisa
Más de 15 años diseñando, implementando y operando infraestructura de misión crítica. Conocemos VMware, Proxmox, OpenStack, Ceph, IBM Storage y las alternativas porque trabajamos con todas. Sin preferencias: solo la solución que encaja con tu negocio.
