Da quando Broadcom ha chiuso l’acquisizione di VMware, i conti per gestire un’infrastruttura virtualizzata sono cambiati. Le licenze perpetue sono sparite, il portafoglio si è ridotto a una manciata di bundle in abbonamento e il prezzo è passato a un modello per-core. I preventivi di rinnovo sono spesso tornati 2 - 5 volte più alti rispetto a quanto i team pagavano prima. Per molti CTO e architetti in Europa, la domanda non è più “dovremmo valutare delle alternative” ma “verso cosa ci spostiamo, e in che ordine”.
Questo è un playbook, non un discorso di vendita. Siamo una società di consulenza ingegneristica, non un cloud provider, quindi non abbiamo nessuna piattaforma da spingervi a usare. L’obiettivo qui è darvi i concetti, gli standard aperti e una mappa onesta delle opzioni, così da poter prendere una decisione adatta al vostro stack.
Perché i team stanno lasciando VMware
I fattori sono ricorrenti tra le organizzazioni con cui parliamo:
- Costo. Le licenze per-core penalizzano gli host ad alta densità. Un server a due socket con due CPU da 16 core, che prima richiedeva due licenze CPU, ora conta come 64 core. Sommato al consolidamento dei bundle, molti rinnovi finiscono ben oltre la spesa precedente.
- Bundling. vSphere, vSAN, NSX e la suite Aria sono ora confezionati in grandi abbonamenti come VMware Cloud Foundation (VCF) e vSphere Foundation (VVF). Se usavate solo vSphere, potreste pagare per funzionalità che non implementate mai.
- Lock-in e pressione del fine supporto. vSphere 7 ha raggiunto la fine del supporto generale a ottobre 2025, e vSphere 8 è previsto per ottobre 2027. Le licenze perpetue continuano a funzionare, ma senza patch e supporto il conto alla rovescia è reale.
- Disruption dell’ecosistema. I cambiamenti ai programmi per partner e Cloud Service Provider (il modello VCSP è passato a inviti solo all’inizio del 2026) hanno spinto alcune relazioni di managed hosting verso la rinegoziazione.
Niente di tutto questo significa che dobbiate smontare tutto il prossimo trimestre. Significa che dovreste conoscere le vostre opzioni e avere una via d’uscita credibile.
Non esiste un unico sostituto di VMware
Questo è il punto più importante di tutto il playbook. VMware ha unito in un solo stack la virtualizzazione del compute, lo storage (vSAN), il networking (NSX) e la gestione (vCenter, Aria). Nessun progetto open source sostituisce tutto questo con un singolo prodotto. La mossa giusta è mappare le opzioni sui carichi di lavoro, partire dagli standard aperti (KVM, QEMU, libvirt, Ceph, OVN/Open vSwitch, le API OCI e Kubernetes) e scegliere gli strumenti adatti a ciascun livello.
Ecco il panorama generale, raggruppato in base a dove ogni opzione dà il meglio. Consideratele rappresentative, non esaustive, e non come una promozione di uno strumento rispetto a un altro.
Piattaforme VM-first (le più vicine a un’esperienza in stile vCenter)
- Proxmox VE - KVM più LXC, con clustering integrato, live migration e integrazione Ceph. Ottimo per il segmento dalle PMI al midmarket e per virtualizzazioni on-prem lineari, dove conta la semplicità.
- oVirt - l’upstream dell’ex Red Hat Virtualization. Ora mantenuto dalla community dopo il ritiro di Red Hat, e base di prodotti come Oracle Linux Virtualization Manager. Un modello datacenter/cluster/host familiare per i team a cui piaceva la struttura di vCenter.
- Harvester - la piattaforma iperconvergente open source di SUSE costruita su Kubernetes, KubeVirt e Longhorn. Offre una UI VM-centrica appoggiandosi a un’infrastruttura cloud-native sottostante.
Piattaforme private cloud (IaaS con multi-tenancy e self-service)
- OpenStack - l’opzione più capace e più modulare, con progetti separati per compute (Nova), networking (Neutron, tipicamente OVN), storage (Cinder, Swift) e identità (Keystone). Eccellente su larga scala, ma davvero complesso e premia un team operativo competente.
- Apache CloudStack - una IaaS integrata e dalle scelte ben definite, più rapida da mettere in piedi rispetto a OpenStack, con supporto multi-hypervisor e networking maturo. Apprezzata da service provider e telco.
- OpenNebula - leggera e pragmatica, ben adatta a edge, ambienti ibridi e private cloud di piccole e medie dimensioni, dove si vuole orchestrazione senza il peso operativo di OpenStack.
Percorsi Kubernetes-native
Se la vostra roadmap è già cloud-native, potete far convergere VM e container su un unico control plane:
- KubeVirt - esegue le VM come risorse Kubernetes. È un progetto CNCF (entrato in revisione per la graduation a fine 2025) con una base di adozione in crescita, ed è il motore alla base di diversi prodotti commerciali di virtualizzazione.
- Cluster API - provisioning dichiarativo e gestione del ciclo di vita dei cluster Kubernetes, spesso abbinato a KubeVirt o al bare metal per un modello cluster-as-a-service.
Per la migrazione di massa delle VM verso il mondo Kubernetes, il progetto open source Forklift (base del Migration Toolkit for Virtualization di Red Hat) si connette a vCenter, inventaria le VM, converte i dischi ed esegue migrazioni cold o warm.
Come scegliere
Partite dai vostri carichi di lavoro e dal vostro team, non da una shortlist di prodotti. Alcune domande che distinguono con costanza le scelte azzeccate da quelle dolorose:
- Cosa state effettivamente eseguendo? Per lo più VM Windows e Linux di lunga durata? Una piattaforma VM-first è la via di minor resistenza. State già containerizzando? Un percorso Kubernetes-native potrebbe consolidare due stack in uno.
- Vi servono multi-tenancy e self-service? Se sì, siete in territorio private cloud (OpenStack, CloudStack, OpenNebula) piuttosto che in un gestore di hypervisor single-tenant.
- Qual è la vostra maturità operativa? La potenza di OpenStack comporta un costo reale in day-2. Siate onesti sul fatto di avere - o di voler assumere, o di voler dare in outsourcing - le competenze per gestirlo.
- Quali funzionalità VMware sono portanti? vMotion, HA, DRS, vSAN, la micro-segmentazione NSX e Site Recovery Manager hanno tutti equivalenti open source, ma raramente si mappano uno a uno. Inventariate le funzionalità da cui dipendete davvero, non quelle che avete in licenza.
- La realtà di storage e networking. Gran parte dei percorsi open source si appoggia a Ceph per lo storage e a OVN/Open vSwitch per il networking. SAN, fabric e policy di segmentazione esistenti richiederanno una progettazione deliberata, non un copia-incolla.
Un approccio alla migrazione per fasi
Le migrazioni falliscono quando vengono trattate come un cutover unico. Sequenziate il lavoro e riducete il rischio a ogni gate.
1. Valutare
Costruite un inventario completo: VM, dipendenze, layout dello storage, policy di rete e sicurezza, ed esposizione delle licenze con le relative date. Assegnate un punteggio a ogni carico di lavoro per tolleranza al downtime, complessità e sensibilità alla compliance. L’output è un backlog di migrazione ordinato per priorità, non un foglio di calcolo che diventa obsoleto.
2. Progettare
Scegliete la piattaforma o le piattaforme di destinazione per ogni gruppo di carichi e progettate esplicitamente l’architettura di storage e rete. È qui che mappate le policy NSX sui security group OVN, vSAN su Ceph e il placement in stile DRS sul nuovo scheduler. Decidete qui anche la meccanica della migrazione: cold vs warm migration, tooling e rollback.
3. Pilota
Allestite la destinazione in un laboratorio e migrate il 10 - 20% di carichi equivalenti a quelli di produzione. Misurate la parità di prestazioni, validate il failover HA, testate backup e ripristino ed esercitate le vostre policy di sicurezza. Un pilota di due-quattro settimane fa emergere le sorprese mentre costano poco.
4. Migrare
Spostatevi a ondate, sequenziate per rischio, mantenendo piccolo l’impatto in produzione per ogni ondata (un tetto del 10 - 15% è una regola pratica sensata). Iniziate con dev/test stateless, poi i livelli web, poi i database e i sistemi mission-critical. Mantenete il vecchio ambiente come bersaglio di rollback finché ogni ondata non è validata.
5. Operare
Una nuova piattaforma richiede nuovi runbook, monitoraggio, cadenza di patching, capacity planning e procedure di DR. Pianificate il trasferimento di competenze, in modo che il team faccia proprie le operazioni day-2 invece di dipendere indefinitamente da chi ha eseguito la migrazione.
Insidie da prevenire
- Il problema del 10%. Un piccolo gruppo di applicazioni solo-VMware genera la maggior parte dell’attrito della migrazione. Individuatele presto; saranno loro a dettare i tempi.
- Il networking è più difficile del compute. vSwitch, port group e policy NSX non si trasferiscono direttamente. I disallineamenti di VLAN e la ricreazione delle policy sono una delle cause principali di downtime prolungato.
- Il test del DR richiede mesi, non settimane. Non scopritelo a ridosso del go-live. Coinvolgete gli stakeholder di compliance e DR già in fase di progettazione.
- Sottovalutare il day-2. La licenza che cancellate viene sostituita da responsabilità operativa. Mettete a budget competenze, automazione e observability.
- Monogamia di strumenti. Resistete alla tentazione di standardizzare tutto su un’unica piattaforma prima che il pilota lo dimostri. Gli ambienti misti sono normali e spesso ottimali.
Il vantaggio della sovranità UE
Per le organizzazioni europee, e in particolare per quelle tedesche, questa migrazione è anche un’opportunità di sovranità. Eseguire infrastruttura open source su capacità ospitata nella UE rimuove in un colpo solo due livelli di dipendenza esterna: il software non è controllato dalla roadmap o dai prezzi di un singolo fornitore straniero, e i dati restano sotto giurisdizione UE. Quella combinazione - open source più residenza dei dati nella UE - è esattamente ciò a cui puntano i framework dietro la recente spinta franco-tedesca per la sovranità digitale e gli sforzi della Commissione Europea sulla Cloud Sovereignty.
Il punto strategico è la leva negoziale. Gli standard aperti fanno sì che i vostri carichi restino portabili, che negoziate da una posizione di scelta anziché di dipendenza, e che la vostra postura di compliance (GDPR, regole settoriali sui dati) sia integrata anziché aggiunta in seguito. La sovranità qui è una capacità che si progetta, non una casella da spuntare.
FAQ
Proxmox è un vero sostituto di VMware?
Per gli ambienti VM-first, sì. Proxmox VE copre clustering, live migration, HA e storage basato su Ceph. Non è una IaaS private cloud completa, quindi se vi serve self-service multi-tenant guardate piuttosto a OpenStack, CloudStack o OpenNebula.
Proxmox vs VMware - qual è la differenza pratica più grande?
Architettura ed ecosistema. VMware offre uno stack strettamente integrato e single-vendor; Proxmox assembla componenti aperti (KVM, LXC, Ceph). Scambiate l’integrazione del vendor e i contratti di supporto enterprise con controllo dei costi, niente licenze per-core e niente lock-in.
Quanto tempo richiede una migrazione da VMware?
Dipende dalle dimensioni dell’ambiente e dalla quota di carichi solo-VMware, ma ragionate in trimestri, non in settimane. Un piano a fasi con un pilota reale e un cutover a ondate è ciò che mantiene contenuti rischio e downtime.
Dobbiamo spostare tutto da VMware in una volta?
No. Le licenze perpetue continuano a funzionare senza supporto, e questo fa guadagnare tempo. La maggior parte dei team migra a ondate e mantiene un footprint VMware in via di riduzione durante la transizione.
VM e container possono girare su un’unica piattaforma?
Sì. KubeVirt esegue le VM come oggetti Kubernetes, permettendovi di far convergere entrambi su un unico control plane. È adatto ai team già investiti in operazioni cloud-native.
Dove si inserisce Rapid Solutions
Siamo una società di consulenza ingegneristica vendor-neutral con uffici ad Amsterdam e Dubai. Non vendiamo una piattaforma, quindi la nostra raccomandazione è guidata dai vostri carichi di lavoro, dal vostro team e dalle vostre esigenze di compliance - non da ciò che dobbiamo monetizzare. Vi aiutiamo con la valutazione, la progettazione della destinazione, il pilota, la migrazione a ondate e il modello operativo day-2, con un approccio open-source-first e sovereign-by-design dall’inizio alla fine.
Se state affrontando un rinnovo VMware o pianificando un’uscita, contattate Rapid Solutions e vi aiuteremo a costruire un percorso di migrazione adatto allo stack che gestite davvero.