Quanto costa davvero uscire da VMware: i conti di una PMI con 12 VM

Da quando Broadcom ha completato l’acquisizione di VMware e ha riorganizzato l’intero modello commerciale, la domanda che ci arriva più spesso dai clienti non è più “come si migra a Proxmox”, perché quella è la parte facile e la procedura tecnica è documentata da anni. La domanda vera, quella che blocca le riunioni e fa rimandare le decisioni, è molto più semplice da formulare e molto più difficile da risolvere: conviene?

È una domanda a cui nessuno può rispondere con un numero secco, e diffidate di chi ci prova. Chi vi dice che risparmierete il 70% sta confrontando due voci di listino e sta ignorando tutto il resto, mentre chi vi dice che non ne vale la pena ha quasi sempre qualcosa da rivendervi. La verità, meno spendibile in una slide, è che il risultato dipende da quante macchine virtuali avete, da quanto è articolata la vostra infrastruttura e soprattutto da quanto vale il tempo delle persone che la gestiscono ogni giorno.

In questo articolo proviamo a mettere per iscritto tutte le voci di costo, comprese quelle che nella maggior parte dei confronti non compaiono mai, usando come riferimento un caso concreto che rispecchia la configurazione che incontriamo più spesso: una piccola impresa con due host fisici, dodici macchine virtuali e nessun sistemista interno a tempo pieno.

L’infrastruttura che prendiamo come riferimento

Prima di fare qualsiasi conto è necessario descrivere con precisione cosa stiamo contando, perché è proprio nella vaghezza delle premesse che si nascondono le sorprese. L’azienda tipo di cui parliamo ha due server fisici, ciascuno con due processori da otto core, per un totale di trentadue core fisici. Sopra ci girano dodici macchine virtuali, quattro delle quali con Windows Server, sei con distribuzioni Linux e due che sono appliance fornite da terzi. Lo storage è una SAN iSCSI condivisa fra i due nodi, le funzioni attive sono l’alta disponibilità e la migrazione a caldo, e il backup viene fatto con un agente installato nelle macchine. Non c’è un sistemista interno: la gestione è affidata a un contratto di assistenza esterna. Il gestionale e il file server sono considerati critici, con una tolleranza massima al fermo di quattro ore.

Se la vostra situazione è molto diversa, per esempio se avete un host solo oppure venti, il metodo che segue resta valido ma i risultati cambiano parecchio, e alla fine dell’articolo torneremo proprio su come si sposta l’equilibrio al variare della dimensione.

Le voci di costo che tutti mettono nel conto

Le licenze, il punto da cui parte ogni discussione

È l’unica voce che compare nelle discussioni da social, ed è anche quella su cui il cambiamento è stato più visibile. Due cose sono cambiate in modo strutturale rispetto a come funzionava prima.

La prima è il passaggio dalla licenza perpetua alla sottoscrizione, che significa che non si compra più un diritto d’uso permanente ma si paga un canone ricorrente, e che quando si smette di pagare si perde il diritto di utilizzare il prodotto, non soltanto gli aggiornamenti. La seconda, più insidiosa perché meno evidente, riguarda il modo in cui si contano le licenze. La regola pubblicata da Broadcom nella sua base di conoscenza è esplicita e vale la pena leggerla nella formulazione originale: «You must license a minimum of 16 physical cores for each CPU (physical processor) in your ESXi hosts, even if a CPU has fewer than 16 cores». Tradotto, bisogna licenziare almeno sedici core per ogni processore fisico anche quando quel processore ne ha meno.

Applicata alla nostra azienda di riferimento, che ha quattro processori da otto core, la regola produce un risultato controintuitivo: i core fisici sono trentadue, ma quelli fatturati sono sessantaquattro, perché ciascuno dei quattro processori viene conteggiato come se ne avesse sedici. Si paga esattamente il doppio di quello che si possiede, e questo accade proprio a chi ha scelto processori con pochi core ad alta frequenza, che per i carichi gestionali è una scelta tecnicamente sensata visto che le prestazioni per singolo thread contano più del parallelismo.

Confronto fra core fisici e core fatturati su tre configurazioni di server

Figura 1. La soglia minima colpisce soltanto chi ha processori con meno di sedici core, e li fa pagare il doppio.

Vale la pena ricordare, perché nel frattempo ha generato molta confusione, che nella primavera del 2025 questa soglia era stata portata da sedici a settantadue core per ordine, una modifica riportata dal distributore Arrow e ripresa dalla stampa di settore che avrebbe reso economicamente insostenibile qualsiasi installazione piccola. La decisione è stata poi ritirata nel giro di poche settimane e la soglia è tornata a sedici core per processore, che è quella attualmente pubblicata da Broadcom. Se avete sentito parlare dei settantadue core e ne siete rimasti allarmati, quella regola non è più in vigore, ma l’episodio dice molto sulla prevedibilità del quadro contrattuale in cui vi muovete.

Sul versante Proxmox la struttura è completamente diversa, e qui serve chiarire un equivoco frequente. Il software è distribuito con licenza libera e può essere installato e usato senza pagare nulla. Quello che si acquista è una sottoscrizione di supporto, il cui listino è pubblicato apertamente sul sito del produttore e si articola in quattro livelli, tutti calcolati per socket fisico occupato e con fatturazione annuale: Community a 120 euro, Basic a 370 euro, Standard a 550 euro e Premium a 1.100 euro. Un aspetto che quasi nessuno conosce è che perfino il livello più economico include l’accesso al repository enterprise e l’intero set di funzionalità: la differenza fra i livelli non sta in cosa potete fare con il prodotto, ma in quanti ticket di supporto avete diritto di aprire e con quale tempo di risposta.

Per la nostra azienda con due server a due socket ciascuno, cioè quattro socket totali, una sottoscrizione Standard costa 2.200 euro all’anno. Vi consigliamo comunque di sottoscriverla anche se il prodotto funziona senza, e più avanti spieghiamo perché la ragione principale non è il supporto.

L’hardware, che nella maggior parte dei casi si riusa

Questa è la buona notizia. Proxmox VE gira su qualunque server x86-64 ragionevolmente recente e riconosce i controller RAID e le schede di rete che avete già, quindi nella stragrande maggioranza delle migrazioni l’hardware esistente viene riutilizzato senza modifiche. Ci sono però tre aspetti che vanno verificati prima e che possono generare costi aggiuntivi.

Il primo riguarda lo storage condiviso. Se avete una SAN iSCSI o Fibre Channel, Proxmox la supporta, ma il livello di gestione funziona diversamente rispetto a quello a cui siete abituati. Lo scenario più moderno per l’alta disponibilità in ambiente Proxmox prevede Ceph in configurazione iperconvergente, che però ha requisiti suoi di cui parliamo fra poco, quindi con due soli host si continua a usare la SAN oppure si aggiunge un terzo nodo.

Il secondo aspetto è proprio quello del terzo nodo, ed è il più frequentemente dimenticato. Un cluster di due soli nodi non riesce a raggiungere il quorum, perché la documentazione ufficiale di Proxmox specifica che serve un numero dispari di voti per evitare che il cluster si divida in due metà di pari peso. Serve quindi un terzo elemento che faccia da arbitro, che può essere un terzo server completo oppure un QDevice, cioè un piccolo demone che gira su una macchina qualsiasi e si limita a votare senza ospitare macchine virtuali. Può essere un mini-PC da poche centinaia di euro, ma va messo a bilancio.

Il terzo aspetto è la rete. Se pensate di adottare Ceph vi servono interfacce dedicate da 10 Gbit, mentre se restate sulla SAN la rete che avete oggi con ogni probabilità è sufficiente.

Le voci di costo che quasi nessuno mette nel conto

Qui si separa un confronto onesto da uno di comodo, perché sono queste le voci che fanno la differenza fra un progetto che ripaga e uno che delude.

Le sette voci di costo divise fra quelle sempre calcolate e quelle trascurate

Figura 2. Due voci su sette compaiono in quasi tutti i confronti, le altre cinque quasi mai.

Il tempo della migrazione

Spostare una macchina virtuale non è difficile e chiunque abbia un minimo di dimestichezza ci riesce. Spostarne dodici senza fermare l’azienda, verificando che ognuna riparta correttamente e che gli applicativi funzionino come prima, è invece un progetto vero, con una sua durata e un suo costo.

Sulla base delle migrazioni che abbiamo seguito su infrastrutture di questa dimensione, il tempo si distribuisce più o meno così: da quattro a otto ore per l’assessment iniziale e l’inventario, da otto a dodici per installare e configurare il cluster, da quattro a otto per lo storage e la rete, da dodici a venti per la migrazione vera e propria delle macchine, da otto a dodici per i test funzionali e il collaudo, da quattro a otto per riconfigurare i backup e circa quattro per la documentazione e il passaggio di consegne. Il totale si colloca quindi fra le quarantaquattro e le settantadue ore.

Alle tariffe di mercato per un sistemista senior è una voce che pesa e che va messa a bilancio senza addolcirla, ed è anche la ragione per cui la migrazione conviene meno quanto meno macchine avete, dal momento che il costo fisso di progetto si distribuisce su un numero inferiore di macchine. C’è però un aspetto che raramente viene detto, e cioè che una parte di queste ore le spendereste comunque: anche un rinnovo VMware con cambio di modello di licenza richiede verifica della conformità, riconfigurazione e spesso un ridimensionamento, quindi il termine di paragone non è zero.

Il fermo macchina

Ogni macchina migrata richiede una finestra di indisponibilità. Con il metodo a freddo, che prevede lo spegnimento, la copia del disco e il riavvio sul nuovo hypervisor, il tempo è proporzionale alla dimensione del disco: su una rete interna da 1 Gbit un disco da 200 GB si copia in circa mezz’ora, e aggiungendo verifica e riavvio si arriva intorno ai quarantacinque minuti per macchina.

Con dodici macchine si può scegliere fra due strategie. La prima consiste nel concentrare tutto in un fine settimana, spostando il fermo fuori dall’orario di lavoro, ed è la scelta più comune nelle piccole imprese. La seconda prevede di procedere per lotti di due o tre macchine nelle sere infrasettimanali, il che allunga i tempi e mantiene l’infrastruttura in uno stato ibrido per settimane, ma riduce il rischio di trovarsi con tutto fermo contemporaneamente.

Il costo di questo fermo va quantificato con onestà. Se il gestionale è offline un sabato mattina, quanto costa davvero? Per molte aziende la risposta sincera è “nulla”, e in quel caso questa voce vale zero. Per un commercio elettronico o per una produzione a ciclo continuo la risposta è ovviamente diversa e va calcolata.

La formazione e il cambio di abitudini

Questa è la voce più sottovalutata in assoluto, e quella che più spesso ci sentiamo ignorare quando la solleviamo.

Proxmox non è VMware. L’interfaccia è diversa, la terminologia è diversa, le procedure quotidiane sono diverse. Chi gestisce l’infrastruttura, che sia una persona interna o il vostro fornitore, deve ricostruire la confidenza con operazioni che oggi esegue senza pensarci. Non si tratta di un ostacolo insormontabile, perché chi ha basi solide di Linux si orienta in fretta e la curva di apprendimento per le operazioni ordinarie si misura in giorni più che in mesi, ma nei primi mesi ogni intervento richiede più tempo del normale e questo si traduce in un costo reale anche se non compare in nessuna fattura. Vanno messe in conto la formazione iniziale, la riscrittura delle procedure operative documentate e un margine di inefficienza per i primi due o tre mesi.

Il backup

Il backup cambia quasi sempre, e qui c’è una notizia che rende le cose più semplici rispetto a un paio di anni fa. Se oggi usate Veeam, il supporto a Proxmox esiste ed è ufficiale: Veeam ha aggiunto Proxmox VE come piattaforma supportata a partire dalla versione 12.2 rilasciata nell’agosto del 2024, e la documentazione ufficiale di Veeam elenca oggi il supporto per le versioni di Proxmox dalla 8.2 in avanti. Resta comunque necessario verificare che le funzionalità specifiche che usate siano disponibili anche sulla piattaforma nuova, perché la parità non è mai immediata.

L’alternativa nativa è Proxmox Backup Server, che come software non costa nulla, si integra direttamente con l’hypervisor e offre backup incrementali a livello di blocco, deduplica e verifica dell’integrità. Richiede però il suo hardware, o quantomeno una macchina dedicata con spazio adeguato, e la sua configurazione.

Il supporto e il rischio residuo

Su questo punto bisogna essere schietti, perché è la differenza sostanziale fra i due mondi. Con VMware, quando qualcosa si rompe in modo grave, dall’altra parte c’è un fornitore globale con un processo di escalation strutturato e vent’anni di casistica documentata. È un servizio che si paga caro, ma esiste e funziona.

Con Proxmox la sottoscrizione dà accesso al supporto del produttore, che è competente e serio, ma il modello è diverso: più tecnico, meno accompagnato, e con una rete di partner in Italia meno estesa. La conseguenza pratica è che se non avete competenze Linux interne il ruolo del vostro partner IT diventa molto più determinante di prima. Non è automaticamente un costo aggiuntivo, ma è un fattore di rischio che va pesato e che per molte aziende si traduce in un contratto di assistenza più strutturato.

È anche la ragione per cui su un’infrastruttura di produzione consigliamo sempre di sottoscrivere almeno il livello base, e il motivo non è il supporto in sé ma l’accesso al repository enterprise, che riceve aggiornamenti testati invece che pacchetti appena pubblicati. Su un cluster che regge il gestionale aziendale questa differenza conta molto più di qualche ticket.

Come si mette insieme il conto

Il confronto corretto non è licenza contro licenza ma costo totale su tre anni, ed è importante capire perché proprio tre. Con un orizzonte di dodici mesi la migrazione quasi mai conviene, perché i costi una tantum di progetto, fermo e formazione pesano troppo rispetto al risparmio maturato. A tre anni il risparmio ricorrente sulle sottoscrizioni ha il tempo di assorbirli, e a cinque anni il vantaggio diventa netto. Se state valutando la migrazione con un orizzonte annuale, la risposta è quasi certamente no.

Le voci da mettere in colonna sono le licenze o sottoscrizioni moltiplicate per tre anni, l’eventuale hardware aggiuntivo, il progetto di migrazione come costo una tantum, il costo del fermo, la formazione, il backup con le sue licenze e il suo storage, e l’assistenza annuale moltiplicata per tre.

Andamento del costo cumulato nei due scenari, con il punto di pareggio

Figura 3. I costi una tantum spostano in avanti il pareggio: è la ragione per cui un orizzonte annuale non basta.

Come cambia il risultato al variare della dimensione

Il fattore che determina tutto è il rapporto fra i costi fissi di progetto e il risparmio ricorrente, e questo rapporto si muove in modo netto al variare del numero di macchine.

Con un solo host e quattro o sei macchine virtuali il progetto costa quasi quanto costerebbe con due host, ma il risparmio sulle sottoscrizioni è dimezzato, quindi il ritorno arriva tardi e spesso oltre i tre anni. In questa fascia la migrazione ha senso soprattutto quando ci sono motivazioni ulteriori, come la fine vita dell’hardware, la necessità di funzioni non disponibili oppure la volontà dichiarata di uscire da un fornitore.

Fra due e quattro host, con un numero di macchine compreso indicativamente fra dieci e trenta, il conto torna con molta più chiarezza, perché i costi fissi si distribuiscono su abbastanza macchine e il risparmio ricorrente diventa significativo. È anche la fascia in cui la regola dei sedici core minimi per processore morde di più.

Oltre i cinque host il risparmio assoluto diventa importante, ma cresce in parallelo la complessità, perché aumentano le integrazioni, le automazioni da rifare e le procedure da riscrivere. Qui la migrazione è un progetto da pianificare su mesi e non un fine settimana.

Quando invece non conviene migrare

Un consulente che risponde sempre di sì non vi sta consigliando, vi sta vendendo qualcosa, quindi vale la pena elencare le situazioni in cui restare su VMware è la scelta corretta.

La prima è quella in cui dipendete da funzionalità che Proxmox non replica, perché alcune integrazioni di ecosistema e alcuni strumenti di automazione non hanno un equivalente diretto. La seconda, e nella nostra esperienza è la più frequente, si verifica quando avete software gestionale certificato soltanto su VMware: migrare quella macchina significa perdere il supporto del fornitore applicativo, che è un rischio quasi sempre più grande del risparmio ottenuto. La terza riguarda l’orizzonte temporale, perché se entro un anno cambierete comunque tutta l’infrastruttura o vi sposterete in cloud, migrare adesso è lavoro destinato a essere buttato. La quarta è la mancanza di competenze Linux unita all’intenzione di gestire tutto internamente, perché in quel caso il risparmio sulle licenze si trasforma rapidamente in fermi macchina.

Il metodo che usiamo noi

Quando un cliente ci chiede se conviene, non rispondiamo prima di aver fatto tre cose. Facciamo un inventario reale dell’infrastruttura, con quante macchine ci sono davvero, quali sistemi operativi, quali dipendenze e quali integrazioni, e quasi sempre emerge qualcosa che nessuno ricordava. Leggiamo l’ultima fattura e la proposta di rinnovo, perché senza i numeri veri ogni confronto resta teorico. Infine compiliamo il modello a tre anni con i dati di quell’azienda e non con medie di settore. Solo a quel punto il numero che esce significa qualcosa, e a volte dice che conviene con ampio margine mentre altre volte dice che conviene aspettare il prossimo ciclo hardware. Entrambe sono risposte utili.

In sintesi

Il costo di uscire da VMware non coincide con la differenza fra due voci di listino, ma è la somma di sette voci, tre delle quali si pagano una volta sola e pesano quasi interamente sul primo anno. La valutazione corretta si fa su tre anni e con i numeri della vostra azienda, e il risultato dipende soprattutto da quante macchine virtuali avete: sotto le sei il conto raramente torna in fretta, mentre fra le dieci e le trenta si colloca la fascia in cui la migrazione ha più senso.

Vuoi il conto sulla tua infrastruttura?

Compiliamo insieme il modello a tre anni con i tuoi numeri, e per farlo ci servono soltanto due cose: l’inventario delle macchine virtuali e l’ultima proposta di rinnovo VMware. Quello che ne esce è un foglio di calcolo che resta tuo, con il totale a tre anni per entrambi gli scenari. Se il risultato dice che conviene restare su VMware te lo diciamo, perché è successo più di una volta.

Scrivici per una consulenza gratuita oppure chiama lo 051 021 7656.