Migrazione e modernizzazione di software legacy

Il caso più comune non è un sistema famoso. È un programma desktop installato su pochi PC, che apre file locali, stampa, e si aggiorna solo se passa qualcuno. Oppure è un'applicazione web vecchia, che funziona finché non si tocca. In entrambi i casi il problema pratico è lo stesso: una modifica piccola fa paura, e i dati non sono raggiungibili da chi non è in quella postazione.

Cristian Gintili lavora su .NET, API e web app. Ha senso parlarne quando il software da affiancare o sostituire sta in quell'intorno, o quando il nuovo pezzo è un'applicazione web che convive con il vecchio. Non è una promessa di migrare qualunque piattaforma solo perché è vecchia.

Il modo sobrio è scegliere un flusso, costruirne la versione web e farla usare, mentre il resto resta dov'è. Il vecchio programma continua a coprire ciò che non hai ancora toccato. I dati del flusso scelto hanno una regola di passaggio: si copiano una volta, si tengono allineati per un periodo, oppure si smette di scriverli nel vecchio dal giorno del passaggio.

Questo periodo di convivenza va detto nella stima. Due sistemi accesi insieme costano attenzione: quale dei due fa fede, per quanto, e chi controlla che i numeri coincidano. Saltare questo punto significa scoprirlo il giorno in cui i totali non tornano.

Riscrivere tutto in un unico rilascio ha senso solo se il programma è piccolo e le regole sono note. Se le regole sono implicite, il rilascio unico le scopre troppo tardi, quando non c'è più il vecchio schermo con cui confrontarsi.

Il rischio principale non è il linguaggio del vecchio codice. È la regola non scritta. Pulsanti che si usano «solo il venerdì», calcoli che compensano un'eccezione di dieci anni fa, campi il cui nome non dice che cosa contengono. Finché quelle regole non sono raccontate da chi usa il programma, qualunque cifra è un intervallo largo.

Il secondo rischio sono i dati. Codici duplicati, storici incompleti, allegati salvati in cartelle e non nel database. Migrare i dati non è copiare una tabella. È decidere che cosa si porta, che cosa si archivia in sola lettura e che cosa si lascia indietro di proposito.

Il terzo è il fermo. Un gestionale operativo non può sparire un lunedì mattina. Il piano minimo è: il flusso nuovo è usabile, il vecchio resta consultabile, e c'è un modo per tornare indietro se il primo giorno rivela una regola mancante. Questo piano è parte del lavoro, non un dettaglio di go-live.

Dipende da quanti flussi entrano nel primo spostamento, da quante regole sono già spiegabili, dalla qualità dei dati e dal fatto che il vecchio sistema possa esportare. Non dipende, da solo, dal numero di schermate: un calcolo opaco può pesare più di dieci schermate di sola consultazione.

Le fasce della chat sono sotto i 2.000 €, tra 2.000 e 5.000 € e oltre i 5.000 €. Consultare in web un archivio, senza riscrivere i calcoli, può stare in basso. Spostare un flusso con regole, permessi e dati storici sta di solito sopra i 5.000 €. Non è una tariffa della migrazione. Hosting, licenze del periodo di convivenza e il tempo di chi racconta le regole restano fuori.

Nella chat di' che programma è, chi lo usa, quale flusso vuoi spostare per primo e quale deve restare com'è. Aggiungi se i dati si possono esportare e se esiste qualcuno che sa spiegare i calcoli. Non serve allegare il codice sorgente in chat: serve il comportamento.

Ricevi un riepilogo preliminare con macro-funzionalità, intervallo di investimento e indicazione di tempi. Non è vincolante. La call con Cristian si sblocca dopo quel riepilogo. Arrivare con il flusso già scelto rende la conversazione successiva breve. Arrivare con «vogliamo rifare tutto» la rende, giustamente, una richiesta di restringere il perimetro.