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.

Sì, ed è il caso predefinito. Lo strangler-fig consente al team delle funzionalità e al track di modernizzazione di procedere in parallelo: le nuove funzionalità atterrano sui microservizi estratti dal primo giorno, mentre il codice legacy gestisce i bounded context non ancora migrati. Coordiniamo convenzioni di branch, regole di confine dei servizi e un elenco di moduli legacy da non toccare per evitare collisioni tra i due track. Tipicamente il 20–30% della capacità di sprint del team funzionalità è riservata al lavoro di integrazione della modernizzazione; ne teniamo conto nel piano di fase.

Le integrazioni esterne vengono catalogate in discovery e classificate per rischio di migrazione. Le integrazioni con API documentate vengono prima incapsulate dietro un livello adattatore interno, così i nuovi microservizi chiamano l’adattatore anziché il connettore legacy direttamente. Le API vendor in end-of-life vengono segnalate e sostituite o dotate di uno shim di compatibilità durante la migrazione. Le integrazioni non sostituibili durante la migrazione rimangono nel sistema legacy e vengono migrate per ultime.

Accade, e lo pianifichiamo. Durante il dual-run un job di riconciliazione confronta gli output dei percorsi legacy e nuovo per ogni transazione. Le divergenze vengono classificate in differenze attese (cambiamenti di comportamento deliberati), bug legacy ora visibili e nuovi bug introdotti nel codice migrato. I bug legacy scoperti durante la migrazione vengono documentati e triaggiati con voi — alcuni corretti nel nuovo servizio, altri annotati come problemi noti da correggere dopo il cutover.

Definiamo tre livelli di metriche di successo all’inizio: tecnico (copertura dei test, frequenza di deploy, MTTR, tasso di errore sui servizi migrati), operativo (riduzione degli incidenti, delta costo infrastruttura, carico di reperibilità) e di business (velocità delle funzionalità sul nuovo stack, time-to-market per le nuove capacità). Queste metriche vengono riportate nelle revisioni mensili del programma. Ogni fase si chiude con un cutover dimostrabile e una dashboard di salute che mostra la percentuale di traffico legacy.