Di fronte all’aumento dei costi delle licenze VMware, molte aziende stanno iniziando a chiedersi se sia il momento di cambiare. È una domanda legittima. Ma c’è un errore in cui è facile cadere: trasformare il fastidio per un preventivo troppo alto nella fretta di “spegnere VMware e accendere qualcos’altro”. La virtualizzazione è il cuore dell’infrastruttura aziendale, e una migrazione fatta male può costare molto più di un rinnovo caro. Se non hai ancora chiaro cosa sia cambiato nel modello di licenze VMware dopo l’acquisizione di Broadcom, vale la pena partire da lì prima di leggere il resto.
Questo articolo non parla di quale alternativa scegliere. Parla di una cosa che viene prima: quali rischi vanno messi sul tavolo, e valutati con metodo, prima ancora di decidere se e come migrare. Capire questi rischi è il modo per affrontare la scelta da una posizione di controllo, non di emergenza.
Migrare non è “spegnere e riaccendere”
Il primo malinteso da sciogliere è proprio questo. Cambiare hypervisor – cioè la tecnologia che fa girare le macchine virtuali – non è come sostituire un programma sul proprio computer. Significa spostare l’intera infrastruttura virtuale su cui poggiano i server aziendali: gli applicativi gestionali, la posta, i database, gli archivi, spesso i sistemi di autenticazione.
Ogni migrazione è quindi un progetto, non un’operazione estemporanea. E come ogni progetto sull’infrastruttura critica, ha dei rischi che si possono ridurre drasticamente se li si conosce in anticipo – oppure subire, se si procede senza un piano. Vale la pena ricordare che questo ragionamento nasce da un contesto preciso: i cambiamenti commerciali che hanno reso VMware più costoso e meno flessibile per le PMI. I rischi principali sono cinque, e vale la pena guardarli uno per uno.
1. La compatibilità delle applicazioni
Non tutto ciò che gira oggi su VMware funziona automaticamente, e allo stesso modo, su una piattaforma diversa. Alcuni applicativi – in particolare i più datati o quelli configurati su misura – possono dipendere da caratteristiche specifiche dell’ambiente attuale. Il rischio concreto è scoprire un’incompatibilità solo dopo aver spostato il sistema, cioè nel momento peggiore.
La risposta a questo rischio è l’assessment iniziale: una ricognizione che cataloga tutte le applicazioni in uso e ne verifica la compatibilità con l’ambiente di destinazione prima di muovere qualsiasi cosa. È un lavoro che richiede competenza, ma è ciò che separa una migrazione governata da una scommessa.
2. Le dipendenze nascoste tra i sistemi
In un’infrastruttura reale i sistemi non sono isole: si parlano tra loro. Un gestionale dipende dal database, che dipende dal sistema di autenticazione, che a sua volta è collegato ad altri servizi. Queste interdipendenze spesso non sono documentate da nessuna parte: vivono nella testa di chi ha configurato l’ambiente negli anni.
Nella nostra esperienza con le PMI del territorio, è proprio qui che le aziende si fanno male più spesso: si migra un sistema apparentemente isolato e si scopre, a cose fatte, che ne reggeva in piedi un altro. Migrare un pezzo senza aver mappato queste connessioni significa rischiare di interrompere qualcosa di apparentemente scollegato. Per questo una fase di mappatura delle dipendenze – chi dipende da chi, e cosa succede se un servizio si ferma – è parte integrante di una valutazione seria, e non un dettaglio tecnico da rimandare.
3. Il downtime e la continuità operativa
Il rischio più temuto è il fermo dei sistemi. Quanto a lungo l’azienda può restare senza i propri server senza danni? È una domanda a cui bisogna rispondere prima, non durante. Il dato di settore è eloquente: secondo una rilevazione di 451 Research, il 44% delle organizzazioni sperimenta downtime non pianificato durante le migrazioni. Non perché la migrazione sia impossibile, ma perché spesso viene affrontata senza una stima realistica della finestra di fermo accettabile.
Una migrazione ben pianificata definisce in anticipo la soglia di downtime tollerabile per ciascun sistema e sceglie di conseguenza il metodo e i tempi, procedendo per fasi e partendo dai sistemi meno critici, anziché spostare tutto in un colpo solo.
4. L’integrità dei dati e i backup
Durante una migrazione i dati sono nella fase più vulnerabile della loro vita. Un backup non valido, o non verificato, può trasformare un intoppo gestibile in una perdita permanente. Il principio di riferimento, riconosciuto a livello internazionale, è la regola del 3-2-1: almeno tre copie dei dati, su due tipi di supporto diversi, di cui una conservata fuori sede o offline.
Il punto cruciale, però, non è solo avere i backup: è averli validati prima di iniziare. Un backup che nessuno ha mai provato a ripristinare è una rete di sicurezza solo presunta, e capita più spesso di quanto si creda di scoprirlo nel momento sbagliato. La verifica preventiva dell’integrità dei backup è la prima cosa da pretendere in qualsiasi piano di migrazione.
5. L’assenza di un piano di rientro
Anche con la migliore pianificazione, qualcosa può andare diversamente dal previsto. La differenza tra un imprevisto e un disastro è una sola: avere o non avere un piano di rollback, cioè la possibilità di tornare alla situazione precedente in modo ordinato se la migrazione incontra ostacoli seri.
Un piano di rientro non è un segno di sfiducia nel progetto: è il contrario, è ciò che permette di procedere con serenità. Va definito in anticipo, documentato e – idealmente – testato, così che la decisione di proseguire o tornare indietro sia una scelta tecnica ragionata e non una reazione affannata sotto pressione.
Il metodo conta più del prodotto
Se da questi cinque punti emerge un filo conduttore, è questo: il successo di una migrazione dipende molto più dal metodo con cui la si affronta che dalla tecnologia di destinazione scelta. Esistono diverse piattaforme valide verso cui spostarsi, ognuna con i suoi punti di forza. Ma anche la migliore di esse, raggiunta senza assessment, senza mappatura delle dipendenze, senza backup validati e senza piano di rientro, diventa un rischio invece che un’opportunità.
È esattamente per questo che la scelta del partner conta più della scelta del prodotto. Un fornitore che conosce la tua infrastruttura, che parte da un’analisi e non da un preventivo, e che ti accompagna passo dopo passo, è ciò che trasforma una migrazione da salto nel buio in un percorso controllato.
In sintesi
Prima di decidere se e come lasciare VMware, vale la pena fermarsi a valutare i rischi reali: compatibilità delle applicazioni, dipendenze tra i sistemi, downtime, integrità dei dati e possibilità di tornare indietro. Sono questi gli elementi che determinano se una migrazione sarà un miglioramento o un problema. La buona notizia è che tutti e cinque si governano, a patto di affrontarli con metodo e per tempo. E se ti stai chiedendo da dove nasce tutto questo, il punto di partenza resta l’evoluzione dei costi e delle condizioni di VMware, che abbiamo analizzato in dettaglio in precedenza.
Noi di Alctech affianchiamo le aziende del territorio proprio in questa fase di valutazione, prima e indipendentemente da qualsiasi decisione.
Vuoi capire da dove parte una valutazione seria per la tua infrastruttura? Parti da un’analisi del tuo ambiente. Contattaci.