Riscrivere un legacy o migrarlo per domini?
Un gestionale di vent'anni regge ancora l'operatività. Si butta e si rifà, o si smonta un pezzo alla volta?
La riscrittura completa è seducente perché promette di lasciarsi alle spalle tutto in una volta. Il problema è che concentra il rischio in un unico momento: il giorno del passaggio. Fino a quel giorno il nuovo sistema non ha mai visto un utente vero, e quel giorno li vede tutti insieme.
C'è anche un problema meno visibile. Un sistema di vent'anni contiene regole che nessuno ricorda di aver scritto, e che qualcuno usa. Riscriverlo da una specifica significa riscrivere solo le regole che qualcuno ha saputo raccontare.
La decisione
Migrare per domini. Si individuano le aree del sistema, prenotazioni, sedi, clienti aziendali, le loro dipendenze e l'ordine in cui possono essere separate. Poi il nuovo sistema prende una responsabilità alla volta, con il vecchio che continua a reggere il resto. Ogni passo ha un confine chiaro e una strada indietro.
Il prezzo è una convivenza lunga: per un periodo i dati vivono in due posti e serve uno strato che li tenga allineati. È un costo reale, e va detto al cliente all'inizio. In cambio si ottiene la possibilità di verificare ogni parte in condizioni reali, con utenti veri, e di fermarsi in qualunque momento senza aver rotto niente.
Quando invece si riscrive
Quando il sistema è piccolo abbastanza da poter essere verificato per intero prima del passaggio, o quando non ha utenti che dipendono dalla continuità. E quando il nuovo può girare in ombra accanto al vecchio, ricevendo lo stesso traffico e confrontando le risposte, prima di prendere il volante.
In tutti gli altri casi la domanda giusta è quanto costa un giorno di fermo. Se la risposta è molto, si migra per domini.
Descrivici il sistema. Ti diciamo cosa vediamo.
Dieci minuti, una domanda alla volta. Alla fine, la nostra lettura onesta del caso. È il filtro, prima ancora della call.