La paura che blocca molte migrazioni al cloud è il fermo: «e se lunedì mattina il gestionale non parte?». È una paura fondata solo se la migrazione è improvvisata. Fatta a tappe, con un piano di cutover e un rollback pronto, si porta in cloud un'intera infrastruttura senza che l'azienda perda un giorno di lavoro.
Si parte dall'assessment: l'inventario di cosa gira davvero in azienda. Applicazioni, database, condivisioni file, dipendenze tra sistemi, licenze, e — spesso la scoperta più utile — quel server dimenticato da cui dipende mezzo reparto. Ogni applicazione viene classificata: si sposta com'è, va adattata, o va sostituita. Per una PMI tipica l'assessment richiede una-due settimane e vale da solo il costo, perché produce la mappa che mancava.
Poi la scelta di fondo: lift & shift o refactoring. Il lift & shift sposta le macchine com'erano: veloce, poco rischioso, ma si porta dietro le inefficienze — pagate il cloud come paghereste dei server, senza sfruttarne l'elasticità. Il refactoring adatta le applicazioni ai servizi cloud (database gestiti, storage a oggetti, scalabilità automatica): costa di più oggi, rende di più ogni mese dopo. La risposta giusta di solito è mista: lift & shift per ciò che andrà in pensione entro pochi anni, refactoring per ciò su cui l'azienda vive.
Il cutover è il momento del passaggio, e si progetta come un'operazione chirurgica: si sceglie una finestra a basso impatto (il classico venerdì sera-domenica), si replica in anticipo tutto il replicabile in modo che nella finestra si sposti solo il delta finale, si fa almeno una prova generale su dati copia, e si scrive nero su bianco il piano di rollback: se entro l'ora X il sistema non supera i controlli, si torna indietro e l'azienda lunedì lavora sul vecchio.
Un caso tipico: azienda da 40 persone, un gestionale client-server, un file server e la posta. Posta e file migrano per primi, in settimane separate, perché sono i più semplici e fanno da collaudo del metodo. Il gestionale passa per ultimo in un weekend: replica del database durante la settimana, allineamento finale il venerdì sera, test con utenti campione il sabato, verdetto la domenica. Fermo effettivo percepito dagli utenti: zero.
Sui costi conviene essere onesti. Il cloud fa risparmiare su hardware da rinnovare, continuità (gruppi di continuità, condizionamento, ridondanze che una PMI non può permettersi in casa), disaster recovery e picchi stagionali. Non fa risparmiare automaticamente su carichi costanti e pesanti che girano 24 ore su 24, e il traffico dati in uscita ha un costo che a volte sorprende. Un confronto serio si fa sul costo totale a 3-5 anni, non sulla bolletta del primo mese.
La migrazione non finisce col cutover. I primi mesi servono a mettere a regime: right-sizing delle risorse (le macchine sovradimensionate «per sicurezza» vanno ridotte), spegnimento degli ambienti di test fuori orario, allarmi sui costi, backup verificati con prove di ripristino, e regole di accesso riviste — in cloud una configurazione sbagliata è esposta al mondo, non solo alla rete interna.
Da dove iniziare? Dall'assessment, sempre. È l'investimento più piccolo dell'intero percorso e trasforma la domanda vaga «dovremmo andare in cloud?» in un piano con priorità, costi e rischi scritti. Il resto viene una tappa alla volta — ed è esattamente il motivo per cui l'azienda non si ferma.