Dobbiamo rinnovare il nostro legacy system di 12 anni: rifarlo da zero o procedere per gradi?

Tre anni fa abbiamo deciso di riscrivere da zero il nostro gestionale logistico che aveva volumi simili. Ci avevano promesso 6 mesi: ce ne sono voluti ben 16 e il budget è quasi triplicato. La prima settimana di go-live per via di errori nel calcolo degli sconti abbiamo emesso fatture errate a centinaia di clienti. Riscrivere da zero quando il vecchio sistema è in produzione è un azzardo pazzesco.

Ecco i passi da seguire per pianificare una migrazione graduale: 1) Mappare le relazioni nel vecchio database e individuare le aree indipendenti, 2) Mettere un router davanti al sistema per gestire il traffico, 3) Migrare prima i servizi non critici a prevalenza di lettura, 4) Lasciare i flussi core come ordini e pagamenti all'ultimo passaggio.

Nella mia esperienza di consulenza, su 5 sistemi enterprise riscritti da zero, ben 4 hanno superato la data di consegna concordata di almeno 6 mesi. Al contrario, nei progetti trasformati gradualmente gli scostamenti di budget sono rimasti contenuti e nessuno ha subito interruzioni critiche sugli ordini. La proposta del vostro sviluppatore poggia su basi decisamente più realistiche.

Anche la migrazione graduale ha un costo nascosto: per 18 mesi il vostro team dovrà gestire due architetture diverse, due modelli di dati differenti e la sincronizzazione tra di loro. Se il team è piccolo, questo doppio carico di manutenzione rischia di esaurire gli sviluppatori e bloccare di nuovo tutto.

Fate subito il primo passo per testare il piano del vostro sviluppatore. Prima di firmare un contratto da 110.000 dollari con l'agenzia, date 2 mesi di tempo al vostro dev per scorporare il modulo più semplice. Se riesce a gestire la sincronizzazione dei dati e a tirare su il nuovo servizio senza problemi, archiviate direttamente la proposta dell'agenzia.

Un'agenzia che sostiene di poter riscrivere da zero un ERP complesso di 12 anni fa in 8 mesi, significa che non ha ancora visto gli sconti cliente personalizzati e le regole contabili non documentate nascoste nel sistema; il giorno del go-live vedrete quegli 8 mesi trasformarsi magicamente in 20.

il discorso della migrazione dati è davvero il mal di testa più grande. nn puoi passare i dati al sistema riscritto da zero senza prima pulire i record corrotti o mancanti del vecchio db. con il passaggio graduale hai modo di verificare i dati reali passo dopo passo, con il passaggio secco quella possibilità nn ce l'hai.

Indipendentemente dal metodo scelto, vi consiglio di inserire nelle clausole contrattuali una garanzia di integrità dei dati e una procedura di rollback per ciascuna fase. Non bisogna mai dimenticare che la continuità operativa ha sempre la precedenza sull'architettura software.

La penso diversamente. Se non sono stati definiti i criteri di accettazione, il momento in cui il lavoro è finito è discutibile.

Il vero problema non è il numero, ma su cosa si basa quel numero. Se avete domande, scrivete, rispondo per quanto possibile.

Scrivo questo per evitare che facciate lo stesso errore. Se cerchi di cambiare tutto insieme, niente si stabilizza.

Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo. Se scrivete qui il risultato, sarà utile anche ad altri.

Mi sono rilassato leggendo questa risposta quindi non succede solo a me. comunque se ricevete tre risposte diverse su un argomento la domanda è posta male.

Quando prendi una decisione guarda prima quali dati hai a disposizione. Se avete domande, scrivete rispondo per quanto possibile.

Avrei una domanda, non vorrei deviare dall'argomento, ma... Se il contratto non specifica la proprietà del codice, al momento di andarsene non hai potere contrattuale.

Cercare di farlo da soli è la strada più costosa. Sono curioso di sapere se qualcuno lo fa in modo diverso.

Riassumo l'argomento perché sono state date diverse risposte. insomma l'errore commesso da rinnovamento legacy system è generalmente reversibile ma costoso.

Lo sentiamo dire da tempo, ma da noi non è mai andata così. Le credenziali di accesso devono essere create a nome dell'azienda, non con account personali.

Questa è la mia opinione, non la scrivo come verità assoluta.

La penso diversamente. Prendere appunti per due settimane dà risultati migliori rispetto a una stima di sei mesi.

Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore. Confermato dall'esperienza.

Come avete risolto questo? Se cerchi di cambiare tutto insieme, niente si stabilizza.

È tutto, scusate se mi sono dilungato.

La discussione si è dispersa, la riassumo. Le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

Lascio una nota, potrebbe servire.

Salvato.