Sostituirlo senza fermare l’azienda.
Il sistema funziona ancora. Solo che è costoso da modificare, difficile da affidare a qualcuno di nuovo, e lo capisce una persona sola. Si può sistemare: per gradi, con tutto che continua a girare.
Modernizziamo i sistemi datati un pezzo alla volta invece di sostituire tutto in un colpo. Vecchio e nuovo girano in parallelo, il traffico si sposta gradualmente e potete fermarvi in qualsiasi momento tenendo ciò che è già stato fatto. Si parte dal pezzo più rischioso, di solito quello che capisce una persona sola.
Aggiornato novembre 2026
La riscrittura che sostituisce tutto in una volta è il modo in cui questi progetti falliscono.
La tentazione c’è sempre. Ripartire da zero, farlo come si deve, passare al nuovo sistema un sabato. In pratica richiede il doppio del previsto, il vecchio sistema continua ad aver bisogno di modifiche mentre costruite, e il fine settimana del passaggio è davvero pericoloso.
L’alternativa è meno spettacolare e molto più sicura. Si sposta un pezzo alla volta. Il codice nuovo gestisce una parte del traffico, il vecchio sistema il resto, e la proporzione cambia man mano che ogni pezzo dimostra di funzionare.
Nel complesso richiede più tempo, e potete fermarvi quando volete, anche a metà, se le parti vecchie che restano si rivelano a posto. Già questa possibilità di solito vale il tempo in più.
Come lo facciamo.
Prima una valutazione onesta
In che stato è il codice, che cosa è rischioso, che cosa va bene. A volte la risposta è che serve meno di quanto temevate.
Prima il pezzo più rischioso
Non il più facile. La parte in cui l’uscita di una persona sarebbe un problema vero.
Nuovo accanto al vecchio
Entrambi attivi, traffico diviso, che si sposta gradualmente man mano che ogni pezzo dimostra di funzionare.
Dati coerenti
Finché entrambi i sistemi sono attivi, devono essere d’accordo. È la parte tecnicamente più difficile, ed è lì che serve cura.
Test prima delle modifiche
I sistemi datati raramente ne hanno. Aggiungiamo test attorno a un pezzo prima di toccarlo, così sapete se qualcosa si rompe.
Documentazione strada facendo
Di solito la prima documentazione vera che il sistema abbia mai avuto. Utile anche se vi fermate presto.
Il vostro team coinvolto
Così la conoscenza si trasferisce, invece di passare da un punto unico di fragilità a un altro.
Un punto di arresto a ogni fase
Ogni pezzo è completo in sé. Non vi ritrovate mai a metà migrazione con niente che funzioni.
Riscrivere tutto o sostituire per gradi.
Sono legittime entrambe. Una delle due fallisce molto più spesso, ed è quella che suona più pulita.
| Riscrittura completa | Sostituzione per gradi | |
|---|---|---|
| Quando arriva il primo beneficio | Tutto alla fine | Dalla prima fase, poi di continuo |
| Rischio al momento del passaggio | Tutto, in un fine settimana | Un pezzo alla volta |
| Modifiche al vecchio sistema nel frattempo | Ne mantenete due | Normali: è ancora attivo |
| Ci si può fermare a metà | No: non avete nulla | Sì, e il beneficio resta |
| Durata complessiva | Più breve sulla carta | Più lunga, davvero |
| Quanto spesso va male | Spesso | Raramente |
| Adatta quando | Sistema piccolo, rischio basso | L’azienda dipende dal fatto che funzioni |
Sistemi che abbiamo tenuto in vita.
Lavoro per il più grande switch di pagamento condiviso del Pakistan, dove un sistema non si può spegnere per rifarlo.
Piattaforma di gestione aziendale, web e app, costruita e fatta evolvere con il nostro fondatore come CTO.
Gran parte di ciò che modernizziamo è PHP di qualche anno fa. Lo leggiamo, invece di scappare.
Quando modernizzare.
Lo capisce una persona sola
Il motivo più comune, e il più urgente. È un rischio per l’azienda, non un problema tecnico.
Le modifiche semplici richiedono settimane
Quando una piccola funzione richiede un mese, il sistema vi fa pagare gli interessi su ogni decisione.
Non riuscite a trovare persone che ci lavorino
Se la tecnologia rende difficile assumere, peggiora ogni anno.
Non fa per voi se funziona e cambia di rado
Un sistema stabile che nessuno deve modificare non è un problema. Vi diremo di lasciarlo stare.
Come lavoriamo.
Leggiamo il codice
Davvero, e vi diciamo in che stato è, anche se la risposta onesta è che modernizzare non è urgente.
Troviamo il rischio vero
Di solito non è il codice più vecchio. Di solito è la parte che capisce una persona sola.
Concordiamo l’ordine
Quale pezzo per primo, e che cosa consegna ogni fase da sola.
Aggiungiamo prima i test
Attorno al pezzo da sostituire, così si vede se il comportamento è cambiato.
Facciamo girare entrambi
Il nuovo gestisce una parte del traffico, il vecchio il resto, e la quota si sposta man mano che cresce la fiducia.
Passiamo e rimuoviamo
Solo quando il pezzo nuovo ha funzionato senza problemi. Il vecchio codice resta disponibile finché non è davvero inutile.
Consegniamo ogni fase
Documentazione e una sessione per ogni pezzo, non un’unica grande consegna alla fine.
Modernizzazione del software
7 domande con risposta. Ne avete un’altra? Scriveteci.
Per gradi, quasi sempre, se l’azienda dipende dal fatto che il sistema funzioni. Una riscrittura completa suona più pulita e fallisce molto più spesso: non consegna nulla fino alla fine, vi costringe a mantenere due sistemi e concentra tutto il rischio in un fine settimana. Ha senso per un sistema piccolo, dove una brutta giornata è sopportabile.
Sette categorie. Quarantacinque servizi.
Raccontateci il progetto, com’è davvero.
Scriveteci cosa vi serve e dove siete bloccati. Vi rispondiamo entro un giorno lavorativo con domande vere, e se il progetto dovrebbe essere più piccolo di come lo immaginate ve lo diremo.