Rifare un'applicazione senza fermare l'azienda

Contesto

In azienda basta dire «il programma» e tutti sanno di che cosa parli. Tiene insieme ordini, produzione, lotti e spedizioni. È cresciuto con il lavoro: una richiesta commerciale, un'eccezione in magazzino, un controllo aggiunto dopo un problema. Spesso è nato dal lavoro di una sola persona. Oggi contiene dettagli del tuo mestiere che un prodotto standard potrebbe non coprire.

Poi chiedi una modifica. Il campo compare nella schermata giusta, ma altrove qualcosa smette di funzionare. Rimandi la richiesta successiva. Quando arriva il preventivo per rifare tutto da zero, devi valutare un investimento impegnativo e un passaggio concentrato in un fine settimana.

È il problema che affrontiamo qui: sostituire un'applicazione legacy mantenendo operativa l'azienda. Prima ricostruiamo le regole che contiene; poi sostituiamo una funzione alla volta, con vecchio e nuovo in funzione e una procedura di ritorno per ogni passaggio.

Questo è uno scenario rappresentativo, costruito sulla nostra esperienza diretta nei processi e nei sistemi del settore manifatturiero. Non racconta il progetto di un singolo cliente.

La sfida

1. Il codice è diventato intoccabile. In una discussione tra sviluppatori italiani (r/ItalyInformatica, 5 maggio 2022), il software ereditato viene descritto come «non testabile, difficile da modificare» e «completamente monolitico». In azienda il problema prende una forma concreta: una richiesta che sembra da mezza giornata viene respinta perché non se ne prevedono gli effetti. Oppure viene realizzata e, la settimana dopo, non si stampano più i documenti di trasporto. Manca un modo affidabile per verificare che cosa cambia.

2. Le regole decisive sono scritte soltanto nel codice. Come si calcola uno sconto, quando un lotto può essere spedito, perché un articolo segue un controllo qualità diverso: sono decisioni accumulate negli anni. Chi usa il programma conosce il risultato atteso, ma può non conoscere tutte le condizioni che lo determinano. Riscrivere le schermate senza ricostruire queste regole significa rischiare di perdere pezzi del lavoro.

3. Collegare il sistema ad altri strumenti richiede continui adattamenti. La mancanza di interfacce per lo scambio dei dati è un ostacolo descritto anche nella guida alla migrazione dei sistemi legacy di braincomputing.com, del 21 marzo 2026. Nello scenario qui descritto, i collegamenti passano da esportazioni notturne, letture dirette del database e file trasferiti a mano. Ogni collegamento aggiunge dipendenze da capire prima di intervenire.

4. Il preventivo impone di decidere tutto insieme. Un progetto lungo, un unico rilascio, una data da cui dipendono tutti i reparti. Diventa difficile valutare una parte del lavoro e correggere la direzione prima di impegnarsi sul resto. La decisione si blocca; la manutenzione continua.

I numeri da guardare

Queste domande servono a misurare la situazione iniziale e a verificare i cambiamenti. Non presentano risultati ottenuti. Se le risposte mancano, partiamo dai registri degli interventi e da chi gestisce il sistema.

• Quanto passa dalla segnalazione di un errore alla correzione in produzione? Conta i giorni trascorsi, comprese attese e verifiche, distinguendoli dalle ore lavorate.
• Quante volte, nell'ultimo anno, una modifica ha compromesso una funzione estranea alla richiesta? Registra anche il lavoro necessario per ripristinarla.
• Quanti rilasci in produzione ci sono stati nell'ultimo anno? Se sono stati uno o due, verifica quante richieste sono rimaste ferme e perché.
• Quanti componenti non ricevono più aggiornamenti dal produttore o da chi li mantiene? Includi sistema operativo, database, librerie e linguaggio.
• Quanto tempo serve a una persona nuova per lavorare su quel codice? Misura settimane o mesi e il tempo di affiancamento richiesto a chi lo conosce.
• Quale quota del budget informatico assorbe la manutenzione e quanto resta per nuove funzioni? Distingui il lavoro previsto dagli interventi urgenti.
• Quante persone sanno ripristinare il sistema se si ferma di notte? Se è una sola, verifica che cosa succede quando non è disponibile.

L'approccio

1. Prima le regole, poi il codice. Prima di modificare il codice ricostruiamo e documentiamo le regole che applica. Leggiamo le parti interessate, seguiamo i passaggi dei dati e confrontiamo ciò che troviamo con chi gestisce ordini, produzione e spedizioni. Scriviamo condizioni, eccezioni e casi limite in una specifica che puoi leggere anche tu. Ogni regola ha esempi concreti e un referente aziendale che la conferma. Le incertezze restano esplicite.

Questo lavoro richiede tempo prima che compaia una funzione nuova. Le regole sono il patrimonio dell'azienda: il software è il contenitore. Averle scritte permette di conservarle anche quando cambiano tecnologia o fornitore.

2. Test che descrivono il comportamento attuale. Prima delle modifiche prepariamo verifiche automatiche sui casi individuati. Registriamo ciò che il sistema fa oggi, comprese le anomalie apparenti: un arrotondamento insolito potrebbe rispondere a un accordo commerciale. Quando emerge una differenza, la esaminiamo con chi conosce il processo. Concordiamo quali comportamenti conservare e quali correggere. I test rendono visibili gli scostamenti nei casi coperti; non dimostrano che siano state trovate tutte le eccezioni.

3. Un pezzo alla volta, con vecchio e nuovo in funzione. Scegliamo una funzione con confini verificabili: quali dati riceve, che cosa produce, quali altre funzioni la usano. La ricostruiamo mentre il sistema esistente continua a gestire il resto. Definiamo quale applicazione aggiorna ciascun dato e come lo rende disponibile all'altra, evitando registrazioni duplicate o discordanti.

Il big-bang non si fa. Ogni passaggio deve poter essere verificato prima del successivo. Concordiamo anche le attività richieste agli operatori e le eventuali finestre di intervento: mantenere operativa l'azienda richiede pianificazione.

4. Ogni pezzo migrato ha il suo modo di tornare indietro. Prima del rilascio definiamo quando interrompere il passaggio, chi decide e come riattivare la funzione precedente. Proviamo la procedura e misuriamo quanti minuti richiede nelle condizioni della prova. Includiamo i dati: che cosa succede agli ordini inseriti o ai movimenti registrati nel frattempo? Come li rendiamo nuovamente utilizzabili dal vecchio sistema?

Un backup da solo non risponde a queste domande. Se il ritorno non è praticabile, quella funzione non è pronta per la migrazione.

Che cosa cambia

L'obiettivo è tornare a decidere sulle richieste di lavoro con elementi verificabili. Per ogni parte migrata, documentazione, test e confini espliciti devono permettere di affrontare domande concrete:

• Che cosa comporta cambiare una regola di sconto? Consultiamo la specifica e verifichiamo i casi e le funzioni interessate.
• Quanto costa aggiungere un campo all'ordine? Possiamo stimare l'intervento ricostruendone le dipendenze, comprese stampe e integrazioni.
• Si può collegare il magazzino al portale del cliente? Valutiamo i dati e le operazioni necessari sulle interfacce documentate delle parti rifatte.
• Quanto serve per tornare alla funzione precedente? Abbiamo una procedura provata, con tempi misurati e condizioni dichiarate.
• Che cosa sa fare il sistema? La documentazione resta all'azienda e permette anche a un altro fornitore di orientarsi.

Usiamo queste domande per verificare il lavoro, funzione per funzione.

Che cosa temono, e che cosa rispondiamo

«Un progetto che non finisce mai.» La gradualità richiede disciplina: a ogni passaggio possono emergere nuove richieste. Definiamo prima il perimetro, l'ordine degli interventi e i criteri per chiudere ogni parte. Analisi, prove, documentazione e affiancamento hanno un costo da includere. Le richieste aggiuntive richiedono una decisione esplicita su tempi e budget. Alcune funzioni possono restare nel sistema esistente: il progetto si chiude quando il perimetro concordato è completato e verificato.

«Tenere accesi due sistemi significa pagarli entrambi.» Sì. Durante la convivenza sostieni la manutenzione del vecchio sistema, lo sviluppo del nuovo e il lavoro per collegarli. Il costo del vecchio può restare significativo anche quando ne usi solo una parte. Scegliamo le priorità considerando spesa di manutenzione, dipendenze e rischio operativo: la funzione più costosa non è necessariamente quella da sostituire per prima. Per ogni parte definiamo anche che cosa permette di dismetterla e quali costi cessano davvero.

«Le regole nascoste andranno perse, e ce ne accorgeremo troppo tardi.» Il rischio resta: alcune eccezioni emergono solo in condizioni rare. Per ridurlo servono lettura del codice, verifica con le persone e confronto fra i risultati del vecchio e del nuovo sistema. Questo richiede ore a chi conosce il lavoro e tempo per indagare le differenze. Dove eseguiamo confronti in parallelo, evitiamo di duplicare operazioni reali come spedizioni o movimenti di magazzino. Manteniamo la possibilità di tornare indietro durante la verifica.

Come lo affrontiamo oggi

In Gitogi prendiamo in carico applicazioni da cui dipende il lavoro quotidiano. Partiamo da una specifica leggibile: regole da conservare, dipendenze da gestire, confini dell'intervento. Da lì definiamo il primo pezzo da sostituire e le condizioni per farlo entrare in funzione.

Puoi approfondire il nostro lavoro qui:

• Sviluppo software su misura
• Software per la produzione
• Il nostro lavoro con Odoo

Hai un'applicazione che nessuno vuole più toccare e un preventivo per rifarla da zero? Parliamone — 30 minuti, senza impegno, per capire da dove cominciare.