Servizi di modernizzazione del software legacy per aziende statunitensi ed europee

Nella maggior parte dei casi, modernizzare. Le riscritture complete falliscono con un tasso ben superiore al 50% perché bloccano il roadmap, moltiplicano il perimetro e impongono un unico cutover ad alto rischio. Il nostro approccio predefinito è il pattern strangler-fig: mantenere il sistema legacy in funzione, instradare il nuovo traffico verso microservizi estratti un bounded context alla volta e ritirare il codice legacy solo dopo che il nuovo percorso è stato validato in produzione. Una riscrittura è giustificata solo quando lo stack legacy è impossibile da mantenere, non restano più engineer che lo conoscono, o la conformità lo impone — e anche in quel caso lo facciamo per fasi.

Strangler-fig è un pattern di refactoring incrementale: un layer di routing si posiziona davanti al sistema legacy e reindirizza gradualmente le richieste per capacità specifiche verso nuovi microservizi. Il codice legacy continua a girare per tutto ciò che non è ancora migrato. Ogni bounded context — ordini, fatturazione, identità — viene estratto, distribuito, eseguito in dual-run per la validazione e poi messo in cutover. Il rollback è un cambio di routing, non un redeploy. Nel corso dei mesi il nuovo sistema “strangola” quello vecchio finché l'app legacy può essere dismessa in sicurezza.

La discovery e il piano di migrazione richiedono 4–6 settimane. La migrazione stessa dipende dalla dimensione del sistema e dalla propensione al rischio: un monolite .NET Framework o PHP di medie dimensioni con 200–400 KLOC richiede tipicamente 9–18 mesi di cutover incrementale. I programmi mainframe e COBOL richiedono per natura più anni. Lavoriamo in fasi da 2–3 mesi con un cutover dimostrabile alla fine di ogni fase, così il valore di business viene consegnato in modo continuo invece di aspettare un rilascio big-bang.

Sì, questo è il punto chiave dello strangler-fig. Il sistema legacy rimane in produzione per tutto il tempo. Il traffico si sposta dietro un layer di routing (API gateway, reverse proxy o feature flag) man mano che ogni bounded context va online. Eseguiamo in dual-run i percorsi vecchio e nuovo, confrontiamo i risultati e capovolgiamo la scrittura canonica solo dopo che la parità è confermata. Le finestre di manutenzione si limitano ai cutover del database e di solito sono inferiori a un'ora, pianificate con il vostro team operativo.

Sì. Abbiamo realizzato modernizzazioni su .NET Framework 4.x verso .NET 8, Java 8 verso Java 21 su Spring Boot, PHP 5/7 verso PHP 8 e Node.js, Delphi/Pascal verso C# e TypeScript, Oracle Forms e PL/SQL verso PostgreSQL con servizi Node o Java, classic ASP e VB6 verso stack web moderni, e AngularJS/Knockout/jQuery verso React, Vue o Next.js. I carichi di lavoro COBOL e mainframe vengono gestiti in collaborazione con fornitori specializzati in re-hosting quando necessario.

I dati sono la parte a più alto rischio di qualsiasi modernizzazione, quindi li trattiamo come un flusso di lavoro di primo livello. Iniziamo con il change data capture (Debezium, log shipping nativo o CDC del fornitore) per mantenere sincronizzati i nuovi e vecchi store. Durante il dual-run, le scritture vanno a entrambi i sistemi e un job di riconciliazione segnala le divergenze entro un'ora. Blocchiamo il percorso di scrittura legacy solo dopo una finestra di parità — tipicamente 2–4 settimane — e manteniamo il database legacy come fallback in sola lettura per 90 giorni dopo il cutover.