La scadenza che vi costringe a farlo è nel calendario di qualcun altro.

Di solito non dovreste. Un sistema vecchio, noioso e che fa il suo lavoro non è un problema, e "usa un framework fuori moda" non è una giustificazione economica. I motivi per agire sono esterni e hanno una data: il fornitore ha smesso di rilasciare aggiornamenti di sicurezza, una piattaforma attraverso cui distribuite ha cambiato le regole, un runtime da cui dipendete arriva a fine supporto, oppure l’ultima persona che lo capiva ha dato le dimissioni. Se non si applica nessuno di questi casi, vi diremo di lasciarlo stare.

Migrazione, in quasi tutti i casi che abbiamo visto, e le eccezioni sono più rare di quanto l’entusiasmo suggerisca. Una riscrittura riparte da una specifica che nessuno ha messo per iscritto, perché la specifica reale è il comportamento del sistema che state sostituendo — comprese le parti che sembrano difetti e sono in realtà il 2014 che arriva a una soluzione tampone che nessuno ha documentato. La migrazione conserva quel comportamento e sostituisce le parti che hanno effettivamente ceduto.

È la maggior parte di questo lavoro. Comincia con due settimane di lettura anziché di progettazione, e la prima consegna è un resoconto scritto di ciò che il sistema fa davvero — che in modo affidabile non è ciò che dice la documentazione e spesso non è nemmeno ciò che l’azienda crede. Abbiamo preso in carico un’applicazione di pagamento in produzione, una base di codice mobile ereditata e un’infrastruttura che qualcun altro gestiva da anni.

Non dovrebbe esserlo, e progettare perché non lo sia è la parte più difficile. Ondate anziché un big bang, il sistema vecchio che gira a fianco del nuovo finché il nuovo si è guadagnato il traffico anziché riceverlo a una data stabilita, e una procedura di rollback scritta prima che serva e non durante. Sull’applicazione di pagamento che manteniamo, la migrazione di framework è avvenuta senza interrompere il servizio — le persone l’hanno usata per pagare per tutto il tempo.

Due documenti. Una relazione tecnica con la metodologia, le evidenze, la causa radice di ciò che sta effettivamente cedendo, i difetti collegati, i rischi di sicurezza notati lungo il percorso, un piano di rimedio — e una sezione su ciò che lo studio non ha potuto accertare e perché. E un’istruzione di implementazione scritta per i vostri ingegneri: passo per passo, per componente, con una procedura di verifica, una procedura di rollback, scenari di test e una checklist di accettazione. Potete consegnare entrambi a un altro fornitore.

No, e firmiamo contratti che lo dicono. Ci sono incarichi in cui valutiamo noi e implementa il vostro team, e quel confine sta nei documenti e non in una conversazione. Un revisore che può essere pagato solo se la verifica trova del lavoro per lui ha un interesse in ciò che la verifica trova, ed è un elemento da rimuovere dall’accordo anziché da negare.