In sintesi. Una migrazione al cloud ha due prezzi: un costo una tantum per spostarsi e un costo ricorrente che sostituisce la sala server. La maggior parte dei budget sbaglia il secondo, perché stima i server che avete oggi e non quelli che vi serviranno davvero. Per un'azienda media che si sposta soprattutto con il lift and shift, un piano realistico va dai tre ai sei mesi; quando lungo la strada devono cambiare l'ERP o il software su misura, dai sei ai diciotto mesi è una stima più onesta. I rischi che fermano i progetti raramente sono tecnici in senso stretto: dipendenze dimenticate, licenze che non si spostano, una bolletta che nessuno controlla e nessuno incaricato di gestire il nuovo ambiente. Questa guida tratta costi, tempi e rischi. Se state valutando di affidare il progetto a un partner, trovate il nostro approccio nella pagina del servizio di migrazione al cloud.
A che punto sono le aziende italiane
Le aziende italiane usano il cloud più della media europea. Secondo Eurostat, nel 2025 il 75,6% delle imprese italiane con almeno dieci addetti ha acquistato servizi di cloud computing, contro una media UE del 52,7%. Il dettaglio però racconta altro. Gran parte di questo uso riguarda posta elettronica, software per l'ufficio e archiviazione di file: tra le piccole imprese italiane, il 72,5% acquista la posta elettronica come servizio cloud. Solo il 14,4% delle imprese italiane usa potenza di calcolo in cloud per far girare il proprio software, e il 17,5% usa un ERP erogato come servizio cloud.
Per la maggior parte delle aziende, quindi, la domanda non è se "andare in cloud": la posta è già lì. La domanda è cosa fare dei sistemi che girano ancora su server in ufficio o in un data center locale: l'ERP, i file server e i database, le applicazioni su misura che li collegano. È lì che stanno costi, tempi e rischi.
Quanto costa una migrazione al cloud
Il costo ha due componenti, che si comportano in modo diverso.
I costi una tantum si sostengono una volta, durante il progetto:
- Assessment. Un inventario di server, applicazioni, volumi di dati e dipendenze, con i dati reali di utilizzo. Senza, ogni stima successiva è un'ipotesi.
- Landing zone. Account, rete, identità e accessi, backup, log e monitoraggio, configurati prima che si sposti il primo carico di lavoro.
- Lavoro di migrazione. Lo spostamento di ogni sistema, che costa in modo molto diverso a seconda della strategia: il rehost di una macchina virtuale costa poco, il replatform di un database di più, il refactoring di un'applicazione è un progetto software a sé.
- Doppio esercizio. Per un periodo pagate sia il vecchio ambiente sia il nuovo. Pianificatelo in modo esplicito: è spesso la voce che fa sforare il budget.
- Test e cutover. Test funzionali, test di prestazioni, un cutover provato in anticipo e un piano di rollback.
- Formazione. Chi gestisce i sistemi deve conoscere il nuovo ambiente prima del go-live, non dopo.
I costi ricorrenti partono quando il primo sistema va in produzione e non si fermano più:
- calcolo, storage e backup, fatturati a consumo;
- il traffico dati in uscita dal cloud (egress), che compare ogni volta che utenti, partner o altri sistemi prelevano dati;
- le licenze software, che in cloud possono costare diversamente rispetto ai vostri server;
- servizi gestiti, piani di supporto, strumenti di monitoraggio e sicurezza;
- le persone, interne o esterne, che gestiscono l'ambiente e controllano la spesa.
Come stimare il costo ricorrente
Partite dall'utilizzo misurato, non dalle specifiche dei server attuali. Le macchine on-premise di solito sono dimensionate per il picco e per cinque anni di crescita, e una stima cloud che le copia paga ogni mese capacità inutilizzata. Usate i calcolatori dei fornitori (AWS, Azure, Google Cloud) con i dati reali di CPU, memoria e storage, e aggiungete a parte egress e backup, che sono le voci più spesso dimenticate.
Gli sconti a fronte di un impegno cambiano il quadro quando i carichi sono stabili. AWS, per esempio, dichiara che i Savings Plans costano fino al 72% in meno rispetto ai prezzi on-demand, in cambio di un impegno di uno o tre anni. Acquistateli dopo i primi mesi in cloud, quando sapete cosa usate davvero, non il primo giorno.
Lo spreco è l'altra metà della stima. Nel 2026 State of the Cloud Report di Flexera, basato su un sondaggio tra oltre 750 decisori e utenti del cloud, gli intervistati stimano che il 29% della spesa cloud sia sprecata, il primo aumento in cinque anni, e l'85% indica la gestione della spesa cloud tra le sfide principali. Un budget cloud ha bisogno di un responsabile dal primo mese: qualcuno che legge la fattura, spegne ciò che è inattivo e ridimensiona ciò che è sovradimensionato. Questa disciplina si chiama di solito FinOps.
Le voci di costo in sintesi
| Voce | Una tantum o ricorrente | Da cosa dipende | Spesso sottostimata perché |
|---|---|---|---|
| Assessment e inventario | Una tantum | Numero di sistemi e qualità della documentazione | Le dipendenze non documentate emergono solo quando si guarda |
| Landing zone | Una tantum | Requisiti di sicurezza, rete e conformità | È invisibile agli utenti, quindi viene tagliata |
| Lavoro di migrazione | Una tantum | Strategia per sistema: rehost, replatform, refactoring | Il refactoring viene stimato come se fosse un rehost |
| Doppio esercizio | Una tantum | Quanto a lungo convivono vecchio e nuovo ambiente | Le date di cutover slittano, il vecchio contratto continua |
| Calcolo e storage | Ricorrente | Utilizzo reale, sconti a fronte di impegno | I server vengono copiati con le dimensioni di oggi |
| Egress | Ricorrente | Dati che escono dal cloud verso utenti e altri sistemi | Non si vede fino alle prime fatture |
| Licenze | Ricorrente | Condizioni del fornitore per l'uso in cloud | Si presume che si spostino così come sono |
| Gestione e FinOps | Ricorrente | Chi gestisce e ottimizza l'ambiente | Si presume che sia "incluso" nel cloud |
Quanto dura una migrazione al cloud
I tempi dipendono dal numero di sistemi, dalla strategia scelta per ciascuno e da quanto cambiamento l'azienda riesce ad assorbire nello stesso periodo. Gli intervalli qui sotto sono intervalli di pianificazione che usiamo come punto di partenza per un'azienda media con qualche decina di server e un sistema gestionale principale. Non sono un benchmark: l'assessment serve proprio a sostituirli con i vostri numeri.
| Fase | Cosa succede | Intervallo di pianificazione tipico |
|---|---|---|
| Assessment | Inventario, dati di utilizzo, dipendenze, strategia per sistema, business case | Da 2 a 6 settimane |
| Landing zone | Account, rete, identità, backup, log, controlli sui costi | Da 2 a 4 settimane |
| Pilota | Un carico di lavoro a basso rischio spostato dall'inizio alla fine, con prova di cutover e rollback | Da 2 a 4 settimane |
| Ondate di migrazione | Sistemi spostati in gruppi che condividono dipendenze, partendo dai più semplici | Da 1 a 6 mesi, di più con il refactoring |
| Stabilizzazione e dismissione | Fine del doppio esercizio, spegnimento di vecchi server e contratti, ottimizzazione dei costi | Da 1 a 3 mesi |
Messi insieme: una migrazione fatta soprattutto di rehost si chiude in tre-sei mesi. Quando l'ERP deve passare a una nuova versione, un database cambia motore o un'applicazione su misura viene riprogettata lungo la strada, un piano da sei a diciotto mesi è più onesto. Le linee guida di AWS per le grandi migrazioni raccomandano di fare prima rehost, relocate o replatform e di modernizzare dopo, perché il refactoring durante la migrazione è la strategia più complessa e costosa.
Tre fattori allungano i tempi più della tecnologia: il calendario aziendale (nessuno sposta l'ERP durante la chiusura di fine anno), i tempi dei fornitori per licenze e contratti di supporto, e le persone che servono alla migrazione mentre continuano a gestire l'operatività quotidiana.
I rischi da pianificare
- Dipendenze nascoste. Un report che legge direttamente il database dell'ERP, uno scanner che scrive su una cartella di rete, uno script notturno su un server dimenticato. Ognuno si rompe il giorno del cutover, se nessuno l'ha trovato. L'assessment dovrebbe ricostruire le connessioni dai dati di rete, non solo dalla documentazione.
- Sorprese sui costi. Egress, macchine sovradimensionate e risorse che nessuno ha spento. Impostate budget e avvisi nella landing zone, prima che si sposti il primo carico di lavoro.
- Licenze che non si spostano. Alcuni software sono licenziati per server fisico o per core, e le condizioni del fornitore per l'uso in cloud possono essere diverse. Verificate ogni licenza prima di scegliere la strategia per quel sistema: può trasformare un rehost in un repurchase.
- Fermo al cutover. Pianificate la finestra di cutover con il business, provatela nel pilota e mantenete un percorso di rollback testato finché il nuovo ambiente non ha completato un intero ciclo operativo.
- Localizzazione dei dati e obblighi di sicurezza. Tutti e tre i principali fornitori hanno region in Italia: AWS a Milano dal 2020, Google Cloud a Milano e a Torino, Microsoft Azure con la region Italy North a Milano. Una region locale tiene i dati nel Paese, ma da sola non risolve gli obblighi GDPR e di sicurezza. Se la vostra azienda rientra nella NIS2, il fornitore cloud diventa un fornitore da valutare, come spiegato nella nostra guida a NIS2 e software legacy.
- Lock-in e uscita. I servizi gestiti di un fornitore fanno risparmiare lavoro e rendono più difficile andarsene. Il Data Act europeo limita una parte di questo rischio: dall'11 gennaio 2024 i fornitori possono applicare solo costi di passaggio ridotti, non superiori ai costi direttamente sostenuti, e dal 12 gennaio 2027 non possono più addebitare nulla per il passaggio, compreso l'egress dei dati legato al cambio. L'egress ordinario durante l'esercizio resta a pagamento. AWS, dal canto suo, da marzo 2024 non addebita il traffico in uscita ai clienti che portano i propri dati fuori da AWS. Tenete comunque un piano di uscita: formati di esportazione dei dati, infrastruttura come codice e documentazione.
- Nessuno è responsabile del risultato. Dopo il go-live qualcuno deve aggiornare, fare backup, monitorare e ottimizzare. Se questa responsabilità non viene assegnata prima di iniziare, il nuovo ambiente torna allo stato del vecchio, solo con una fattura mensile. Lo stesso vale per i sistemi che in cloud non dovrebbero arrivarci affatto: per quelli, la nostra guida su quando sostituire il software legacy aiuta a decidere.
Un esempio: un distributore con 60 dipendenti
Prendiamo un'azienda ipotetica (non un cliente WWG) con 60 dipendenti che distribuisce ricambi. Ha un ERP su due server in ufficio, un file server, un database SQL Server dietro un portale ordini su misura usato da 300 rivenditori e alcuni script che spostano dati tra questi sistemi. La posta è già in cloud.
L'assessment ordina i sistemi prima che si parli di fornitori. Il file server viene sostituito dall'archiviazione cloud che l'azienda paga già insieme alla posta (repurchase). Il produttore dell'ERP offre una versione in hosting dello stesso prodotto, quindi l'ERP passa al cloud del fornitore con il prossimo aggiornamento di versione, fuori dalla chiusura di fine anno (repurchase, legato al calendario aziendale). Il portale ordini e il suo database vengono spostati in cloud così come sono (rehost), e qualche mese dopo il database passa a un servizio gestito (replatform). Due degli script risultano alimentare report che nessuno legge e vengono spenti (retire).
Il piano: un mese tra assessment e landing zone, un pilota con l'ambiente di test del portale, file server e portale nella prima ondata, l'ERP nella seconda, in coincidenza con l'aggiornamento. Circa sei mesi in tutto, con due mesi di doppio esercizio messi a budget per l'ERP. Il rischio principale individuato non è tecnico: l'integrazione dei rivenditori con il portale, che richiede i loro referenti IT disponibili nel weekend del cutover.
Fonti
Tutte le fonti sono state consultate il 12 novembre 2026.
- Eurostat, isoc_cicce_use (aggiornato il 27 febbraio 2026): imprese che acquistano servizi di cloud computing per classe dimensionale e tipo di servizio, Italia e UE, 2025. ec.europa.eu/eurostat
- Flexera, comunicato sul 2026 State of the Cloud Report, 18 marzo 2026: spesa cloud sprecata al 29%, gestione della spesa tra le sfide principali per l'85%, sondaggio su oltre 750 intervistati. flexera.com
- Regolamento (UE) 2023/2854 (Data Act), articolo 29: soppressione graduale dei costi di passaggio. eur-lex.europa.eu
- Commissione europea, Data Act explained: costi di passaggio, compreso l'egress dei dati, eliminati dal 12 gennaio 2027; il regolamento si applica dal 12 settembre 2025. digital-strategy.ec.europa.eu
- AWS Prescriptive Guidance, strategie per le grandi migrazioni: le 7 R e la raccomandazione di modernizzare dopo la migrazione. docs.aws.amazon.com
- AWS News Blog, "Free data transfer out to internet when moving out of AWS", 5 marzo 2024. aws.amazon.com
- AWS, Savings Plans: risparmio fino al 72% rispetto ai prezzi on-demand. aws.amazon.com
- Werner Vogels, "Reaffirming our commitment to Italy: Introducing the AWS Europe (Milan) Region", aprile 2020. allthingsdistributed.com
- Google Cloud, regions and zones: europe-west8 (Milano) ed europe-west12 (Torino). docs.cloud.google.com
- Microsoft Learn, elenco delle region Azure: Italy North, Milano, tre availability zone. learn.microsoft.com
FAQ
Domande frequenti
Risposte brevi su quanto costa migrare al cloud, quanto tempo serve, i rischi principali e se si può cambiare fornitore in seguito.
