«Migriamo tutto lo storico»
Spesso metà dello storico non viene più letto. Separare archivio e operativo riduce tempi, rischio e costo, ma va deciso all’inizio.
Migrare il database di un gestionale senza fermare l’azienda.
Un gestionale in esercizio non si spegne per un fine settimana. La migrazione va progettata come un passaggio graduale con una via di ritorno, non come un salto: è questa la differenza fra un progetto che si controlla e uno che si subisce.
Cosa si sposta davvero
Il database è la parte visibile. Sotto ce n’è altra.
- I dati: la parte che tutti stimano, e quasi sempre la meno problematica.
- La logica dentro il database: stored procedure, funzioni, trigger, viste. È qui che si concentra il rischio.
- I lavori pianificati: job notturni, esportazioni, riconciliazioni. Vivono fuori dall’applicazione e nessuno se li ricorda finché non saltano.
- Le integrazioni: report, strumenti di analisi, applicazioni di terzi che leggono direttamente dal database, spesso senza che l’IT lo sappia.
- I permessi: utenti, ruoli e viste create negli anni per singole esigenze, che si scoprono solo quando qualcuno perde l’accesso.
Il passaggio, senza fermarsi
Un sequenza che tiene sempre aperta la via di ritorno.
- Replica iniziale a sistema acceso, in modo che il nuovo database si allinei mentre il vecchio lavora.
- Doppia scrittura o allineamento continuo per il tempo necessario a validare, con il vecchio che resta la fonte autorevole.
- Confronto sistematico fra i due: non a campione, ma sui totali che l’azienda usa per chiudere il mese.
- Passaggio della fonte autorevole in una finestra breve, con criteri di rientro decisi prima e scritti.
- Il vecchio sistema resta in sola lettura per un periodo concordato: costa poco e vale moltissimo il giorno che serve.
Gli errori che costano di più
«Il collaudo lo fa l’IT»
I difetti veri li trova chi usa il sistema tutti i giorni, perché conosce i casi che nessuno ha documentato. Senza utenti nel collaudo si scopre in esercizio.
«Le prestazioni le vediamo dopo»
Un piano di esecuzione diverso su un motore diverso può rendere lentissima la query più usata dell’azienda. Va misurato durante, sui volumi veri.
«Torniamo indietro se va male»
Il ritorno è possibile solo se è stato progettato: dopo qualche ora di scritture sul nuovo sistema, senza un piano, non si torna più.
Cosa avere pronto prima di iniziare
- L’inventario di chi legge dal database, applicazioni di terzi comprese.
- La lista dei report e dei totali che verranno usati per il confronto.
- La finestra di passaggio concordata con chi lavora, non solo con l’IT.
- I criteri di rientro, scritti: chi decide, entro quando, e in base a cosa.
Se hai una migrazione da pianificare, guardiamo insieme l’inventario e la finestra di passaggio.
Prenota una valutazionePagina aggiornata al 10 agosto 2026.