Come calcolare il costo totale della migrazione di una PMI al cloud

Il costo della migrazione non si esaurisce con il trasferimento dei sistemi

Il cloud può cambiare il modo in cui un’azienda paga la propria infrastruttura, ma non garantisce di per sé un risparmio. Per decidere con cognizione di causa, una PMI deve confrontare il costo totale di proprietà (TCO) del mantenimento dei sistemi attuali con quello di uno o più scenari cloud nell’arco dello stesso periodo. Il confronto deve includere sia il progetto di migrazione sia la gestione operativa successiva, non solo la tariffa stimata dei server.

Il risultato dipende dalle applicazioni, dal loro modello di utilizzo, dal volume dei dati, dal lavoro necessario per adattarle e dalle condizioni contrattuali. Per questo, le stime generiche possono servire da orientamento, ma non sostituiscono i dati specifici dell’azienda.

1. Definire una baseline affidabile

Prima di proiettare la spesa futura, è opportuno fare l’inventario di ciò che esiste e di quanto costa oggi. Il registro dovrebbe mettere in relazione applicazioni e carichi di lavoro con l’infrastruttura che utilizzano, i relativi requisiti di capacità e i servizi che li supportano. È inoltre utile individuare contratti, apparecchiature o centri dati la cui scadenza possa influire sul calendario della migrazione.

La baseline non dovrebbe limitarsi all’acquisto dei server. A seconda del modello attuale, può comprendere manutenzione, hosting, energia, archiviazione, backup, licenze, strumenti di gestione e tempo del personale dedicato alla gestione dell’ambiente. Quando possibile, è preferibile utilizzare i costi effettivi e i dati di utilizzo — non solo la capacità installata — per evitare di confrontare un’infrastruttura dimensionata per i picchi con una stima cloud basata sull’utilizzo medio.

Questo riferimento consentirà in seguito di misurare se la spesa è cambiata e quali voci spiegano la differenza. Se si omettono i costi attuali o si imputano al progetto spese che continueranno a esistere, il confronto perde coerenza.

2. Separare i costi di migrazione da quelli di gestione operativa

Per ogni alternativa, organizzate i costi in due categorie. La prima riguarda il progetto di migrazione: valutazione e pianificazione, strumenti, servizi specialistici, lavoro del team interno, test, modifiche alle applicazioni e preparazione dei dati. La seconda comprende le spese ricorrenti una volta che i carichi di lavoro sono operativi.

Anche il lavoro interno va conteggiato. Non comporta sempre l’assunzione di nuovo personale, ma consuma tempo che potrebbe essere dedicato ad altre attività. Una stima pratica consiste nell’individuare i profili coinvolti, le attività che svolgeranno e il tempo che vi dedicheranno; successivamente, questo impegno può essere valutato secondo un criterio coerente con il budget dell’azienda.

Il metodo scelto modifica il profilo dei costi. Un trasferimento con poche modifiche può richiedere meno lavoro iniziale, ma mantenere nel cloud una configurazione inefficiente. Adattare o riprogettare un’applicazione può aumentare l’impegno e i tempi del progetto, ma consentire di utilizzare servizi gestiti o altre opzioni architetturali. Esistono anche soluzioni intermedie, come trasferire prima e ottimizzare i componenti in un secondo momento. Nessun percorso garantisce di per sé un costo totale inferiore: occorre modellarlo per ciascun carico di lavoro.

3. Proiettare la fattura cloud sulla base di modelli di utilizzo reali

Nello scenario cloud, calcolate separatamente le risorse che si prevede di consumare, come potenza di calcolo, memoria e archiviazione, e i servizi complementari. La tariffa pubblicata da un provider non equivale al costo completo: la stima dipende dalla configurazione scelta, dal consumo effettivo e dalle condizioni commerciali applicabili.

Includete anche database, backup, monitoraggio, assistenza e strumenti di amministrazione o sicurezza, sia che siano offerti dal provider sia che provengano da terzi. Verificate le licenze software esistenti: possono cambiare quando si trasferisce un carico di lavoro e alcuni strumenti sono condivisi tra ambienti locali e cloud. Evitate di considerare un risparmio una licenza o un contratto che l’azienda non potrà effettivamente disdire.

Il trasferimento dei dati merita una voce specifica. Possono esserci costi per trasferire le informazioni verso l’ambiente cloud e, a seconda del provider e della destinazione, per estrarle o spostarle tra regioni o piattaforme. L’importo dipende dal volume e dalla frequenza dei trasferimenti; se questi dati non sono ancora chiari, è opportuno documentare l’incertezza e modellare ipotesi diverse, invece di presentare una cifra come definitiva.

4. Considerare la coesistenza e la sicurezza

Durante una transizione può essere necessario mantenere attivi contemporaneamente i vecchi e i nuovi sistemi. Questo periodo di funzionamento in parallelo può comportare infrastrutture duplicate, licenze, assistenza e lavoro aggiuntivo. La durata dipenderà dal piano e dalle esigenze di convalida, quindi va inclusa nel calendario economico di ogni scenario.

La sicurezza non scompare con la migrazione. Provider e cliente possono avere responsabilità diverse, quindi l’azienda deve individuare quali controlli e attività continuerà a gestire: per esempio, la configurazione degli accessi, la protezione dei dati, il monitoraggio e la risposta operativa. Aggiungete gli strumenti, i servizi e le ore di lavoro del personale pertinenti. Non attribuite automaticamente al provider tutti i costi o le responsabilità in materia di sicurezza.

5. Confrontare gli scenari su un orizzonte temporale comune

Scegliete un periodo che consenta di rappresentare l’utilizzo abituale dei carichi di lavoro e le variazioni rilevanti, come quelle stagionali. Per ciascuna alternativa, applicate la stessa durata e le stesse ipotesi aziendali. È inoltre opportuno separare il periodo iniziale di avvio: i primi mesi possono comprendere attività di messa a punto e spese che non rappresentano il funzionamento a regime.

Una struttura semplice per il calcolo è:

L’uscita dal cloud merita una stima specifica. Se in futuro i dati o i servizi venissero trasferiti a un altro provider o a un’infrastruttura propria, potrebbero sorgere costi di trasferimento, strumenti, lavoro tecnico e funzionamento in parallelo. Non è possibile definire questo costo senza conoscere il volume dei dati, l’architettura e le condizioni contrattuali; lo si può trattare come un’ipotesi e aggiornarlo nel confronto delle offerte.

Una tabella per organizzare la stima

Verificare il modello e rivederne le ipotesi

Il confronto è più utile se ogni voce si basa su dati verificabili ed è contrassegnata come costo osservato, stima o ipotesi. Per i consumi cloud, i calcolatori dei provider possono aiutare a costruire scenari, ma i risultati vanno confrontati con l’inventario, l’utilizzo previsto e le condizioni contrattuali specifiche.

Invece di affidarsi a un’unica previsione, può essere utile confrontare varianti di consumo e di migrazione: per esempio, trasferire un’applicazione con poche modifiche oppure adattarla, o considerare un utilizzo stabile rispetto a uno variabile. L’obiettivo non è prevedere con esattezza una fattura futura, ma capire quali decisioni influenzano i costi e quanto la conclusione dipenda da ipotesi ancora incerte.

Infine, rivedete il calcolo quando cambiano il consumo, l’architettura, le licenze o il calendario. Una stima iniziale è una base per decidere e pianificare, non una garanzia di risparmio. Il confronto più utile per l’azienda è quello che mostra con trasparenza che cosa è incluso, per quanto tempo e a quali condizioni.