Dal server in sede al cloud: la via d'uscita si scrive prima

Contesto

Scriviamo come si esce dal fornitore il giorno in cui si entra. Il piano d'uscita fa parte della scelta iniziale: quali dati portare via, in quale formato, con quali dipendenze e costi.

In sede hai un server su cui gira quasi tutto: il gestionale, l'archivio documentale, le cartelle condivise, magari un'applicazione sviluppata anni fa per la tua attività. Ha funzionato a lungo. Ora l'assistenza sta per scadere e il rinnovo diventa incerto. Il cloud entra nella discussione, ma alla domanda «E se poi volessimo cambiare?» nessuno risponde con precisione.

È da qui che partiamo: dalla continuità del lavoro e dalla possibilità di scegliere ancora, anche dopo la migrazione.

Questo scenario rappresentativo nasce dalla nostra esperienza sul campo nei servizi e nella manifattura. Riunisce problemi e scelte ricorrenti, senza attribuirli a un cliente specifico.

La sfida

1. Nessuno ha definito quanto fermo è tollerabile. «Non possiamo fermarci» esprime una priorità, ma lascia aperte le decisioni operative. Quali attività devono continuare? Quali possono attendere, e per quanto? Concordiamo queste soglie con chi risponde dell'attività aziendale, coinvolgendo l'informatica nella valutazione delle alternative. Da qui dipendono ridondanza, frequenza dei backup e modalità di ripristino. Chiedere continuità senza definirla impedisce anche di valutarne il costo.

2. Durante la migrazione bisogna proteggere la coerenza dei dati. Il Manuale di abilitazione al cloud pubblicato su docs.italia.it (v1.4 del 13/09/2026) elenca fra i rischi la perdita o incoerenza dei dati, la corruzione, le interruzioni prolungate e le interferenze quando origine e destinazione sono in uso insieme. Sono possibilità da prevenire e verificare. Se entrambi gli ambienti accettano modifiche, dobbiamo sapere dove finisce ogni aggiornamento e quale copia considerare valida.

3. Il timore di restare legati al fornitore ha ragioni concrete. Lo stesso manuale (v1.2 del 07/06/2026) collega il lock-in a costi di uscita elevati e informazioni insufficienti perché un altro fornitore possa subentrare. Esportare i dati è soltanto una parte del problema: servono anche configurazioni, accessi, procedure e una conoscenza delle dipendenze. Senza queste informazioni, chi subentra deve ricostruire come funziona il servizio.

4. La spesa richiede un responsabile. Anche il server in sede comporta costi ricorrenti: assistenza, energia, manutenzione. Nel cloud una parte della spesa varia con l'uso. Ambienti di prova dimenticati, copie conservate senza criterio e traffico in uscita possono incidere sul conto. Stabiliamo chi controlla i consumi, chi può attivare risorse e quando uno scostamento richiede un intervento.

I numeri da guardare

Queste sono domande da rendere misurabili nel progetto. Le prime due richiedono una decisione aziendale; le altre servono a verificare che il servizio rispetti quella decisione.

• Quanto tempo di fermo puoi tollerare, e quando? Due ore di notte e due ore durante le spedizioni hanno conseguenze diverse: quale finestra è accettabile?
• Quanto lavoro recente puoi accettare di perdere? Dieci minuti di ordini, un'ora o una giornata sono ipotesi da valutare, non soglie da adottare per abitudine.
• Quanto durano oggi le operazioni abituali? Se un'operazione si ripete cento volte al giorno, quanto tempo assorbe l'attesa?
• Quanto spendi ogni mese rispetto al preventivo? Quale scostamento deve far scattare una verifica, e chi se ne occupa?
• Quanti dati escono dal fornitore ogni mese, e quanto costa trasferirli? Il calcolo comprende anche esportazioni e copie destinate ad altri ambienti?
• Quanto dura un ripristino completo? Quanto passa dall'avvio della procedura al momento in cui puoi usare di nuovo l'applicazione, secondo una prova datata?
• Quanto tempo e denaro servirebbero per cambiare fornitore? La stima comprende trasferimento, ricostruzione dei servizi e verifica del nuovo ambiente?

L'approccio

1. Concordiamo ciò che è tollerabile. Partiamo dalle attività: acquisire un ordine, consultare un documento, preparare una spedizione. Per ciascuna individuiamo applicazioni e dipendenze, poi definiamo fermo e perdita di dati accettabili. Mettiamo per iscritto le soglie e chi le approva. L'informatica valuta come rispettarle; chi governa l'attività decide se il costo è sostenibile. Se le esigenze cambiano, rivediamo insieme le scelte.

2. Proviamo il ripristino prima di spostare i servizi. Ripristiniamo un backup in un ambiente separato e controlliamo che l'applicazione sia utilizzabile. Verifichiamo dati, allegati, permessi, configurazioni e collegamenti necessari al lavoro. Un certificato mancante o una cartella esclusa dal backup possono impedire la ripartenza anche quando i dati principali sono presenti. Registriamo durata, problemi emersi e correzioni necessarie: la prova deve dimostrare che il servizio può tornare operativo.

3. Organizziamo la migrazione a ondate. Raggruppiamo i servizi in base a dipendenze e impatto sull'attività. Cominciamo dove possiamo contenere le conseguenze di un problema. Ogni ondata ha una finestra concordata, verifiche funzionali, criteri per procedere o fermarsi e un piano di ritorno con tempi dichiarati. Quando gli ambienti convivono, definiamo quale accetta le modifiche e come le trasferisce all'altro. Il ritorno deve gestire anche i dati scritti dopo il passaggio: riaccendere il vecchio server, da solo, potrebbe non bastare.

4. Scriviamo l'uscita all'ingresso. Prepariamo il piano all'avvio del progetto. Documentiamo formati di esportazione, accessi necessari, dipendenze dai servizi gestiti e componenti da sostituire o riscrivere. Stimiamo tempi e costi, dichiarando le ipotesi. Verifichiamo che un'esportazione sia utilizzabile altrove e indichiamo ciò che resta da provare. Aggiorniamo il documento quando cambia il sistema: una via d'uscita descritta per un'architettura ormai superata serve a poco.

Che cosa cambia

In questo scenario, il miglioramento si valuta dalla possibilità di rispondere a domande operative con documenti e prove aggiornati. Per i servizi gestiti definiamo anche chi controlla backup e aggiornamenti, chi riceve gli allarmi e chi interviene, con quali tempi concordati.

• Quando possiamo ripartire dopo un guasto? La risposta poggia su una prova di ripristino e sulle condizioni in cui è stata eseguita.
• Perché questo mese spendiamo di più? Lo scostamento è riconducibile a consumi e voci di costo.
• Come proviamo una modifica? L'ambiente di prova ha accessi separati, un responsabile e una data di spegnimento.
• Come cambiamo fornitore? Il piano distingue passaggi verificati, dipendenze e attività ancora da collaudare.
• Dove sono i dati e chi può accedervi? Contratto, documentazione e configurazione devono dare risposte coerenti.

Che cosa temono, e che cosa rispondiamo

«Una volta dentro, non se ne esce più.» Alcuni servizi gestiti rendono più impegnativo il trasferimento, soprattutto quando le applicazioni dipendono dalle loro funzioni. Il piano d'uscita rende visibile questo costo; eliminarlo del tutto può essere impossibile. Valutiamo quali dipendenze accettare e quali evitare. Mantenere la possibilità di cambiare può richiedere più documentazione, prove periodiche e componenti meno comodi da gestire. È un costo da confrontare con i vantaggi del servizio prima di sceglierlo.

«Il conto a fine mese sarà una sorpresa.» Il preventivo dipende da ipotesi sui consumi, che verifichiamo durante la migrazione e nell'uso quotidiano. La convivenza fra vecchio e nuovo ambiente può comportare spese aggiuntive. Assegniamo un responsabile alle risorse, definiamo soglie di avviso e controlliamo il conto ogni mese. Anche questo controllo richiede tempo. Un allarme segnala uno scostamento: serve poi qualcuno che ne trovi la causa e decida come intervenire.

«Perdiamo il controllo dei nostri dati.» Il fornitore di infrastruttura aggiunge un soggetto alla gestione dei dati. Per il nostro lavoro restiamo nell'Unione europea; nel progetto definiamo dove conservare i dati e chi può accedervi. Confrontiamo queste scelte con gli accordi applicabili e la configurazione effettiva. La collocazione geografica, da sola, non risolve la gestione degli accessi. Servono permessi verificabili, revoche e controlli periodici: attività che richiedono responsabilità assegnate e tempo anche dopo la migrazione.

Come lo affrontiamo oggi

Per spostare un sistema da cui dipende il lavoro quotidiano dobbiamo conoscere le sue dipendenze, concordare le interruzioni accettabili e provare il ripristino. Il piano d'uscita entra nella discussione iniziale e resta parte della gestione. Puoi approfondire come lavoriamo su applicazioni e gestionali:

• Sviluppo software su misura
• Il nostro percorso Odoo Partner

Hai un server in sede e un contratto di assistenza in scadenza? Parliamone: partiamo da cosa deve continuare a funzionare e da cosa serve per mantenere la possibilità di cambiare. 30 minuti, senza impegno.