Sostituzione dei sistemi legacy passo dopo passo: Strangler Pattern, operatività in parallelo e coerenza dei dati durante il rollout

Una sostituzione del sistema legacy fallisce raramente per la “costruzione” della nuova soluzione, ma per la transizione: i dati devono rimanere corretti, le interfacce non devono rompersi e l’esercizio deve continuare durante la migrazione. In molte aziende, per questo motivo, un approccio Big Bang non è un’opzione – le dipendenze sono troppo ampie, i costi di fermo troppo elevati, la reversione troppo complessa.

Nella pratica si è dimostrato efficace un approccio graduale con Strangler Pattern (parti funzionali vengono deviate una dopo l’altra), esercizio parallelo (sistema vecchio e nuovo funzionano temporaneamente in parallelo) e regole chiare per la coerenza dei dati. Questo contributo mostra come combinare questi elementi in modo che siano sostenibili nella quotidianità della direzione IT, dell’amministrazione e dei responsabili di progetto – inclusi i modelli di errore tipici, le conseguenze operative e i punti decisionali nel roll-out.

Perché l’approccio passo dopo passo è spesso la sostituzione realistica dei sistemi legacy

I sistemi legacy raramente sono “solo un’applicazione”. Di solito sono collegati: batch, interfacce basate su file (cartelle SFTP, unità di rete), processi di stampa e scansione, strumenti locali, estratti BI, relay di posta elettronica, hardware specializzato, deviazioni della Shadow-IT e workaround manuali. Con un approccio Big Bang tutti questi percorsi devono funzionare nello stesso weekend – e ciò include autorizzazioni, dati anagrafici, storici e casi particolari.

L’approccio passo dopo passo riduce il rischio, ma non lo sposta automaticamente verso il basso. Lo rende più visibile e gestibile, richiedendo però decisioni chiare di architettura e di esercizio: dove si effettua il routing? Chi è il responsabile dei dati? Quale livello di coerenza è inderogabile dal punto di vista funzionale e dove è accettabile una latenza temporale? E come evitare che l’esercizio parallelo si trasformi in un cantiere permanente?

Strangler Pattern nella realtà aziendale: non “microservices”, ma confini di interfaccia chiari

Il Strangler Pattern significa: si sviluppano nuove funzionalità a fianco del sistema esistente e si devia il traffico gradualmente, fino a rendere obsoleto il vecchio componente. Importante: non è una guerra di religione architettonica (“monolite vs. microservizi”), ma un modello di migrazione. Funziona anche se l’architettura target resta un monolite – solo più moderna, manutenibile e meglio integrabile.

La decisione più importante: segmentare per processi, non per tabelle

In molte sostituzioni la separazione viene fatta guidata dai dati (“Prendiamo prima le tabelle clienti e ordini”). Questo spesso conduce a un esercizio parallelo doloroso, perché i processi attraversano trasversalmente questi dati. Meglio un taglio orientato ai processi, p.es. “creazione offerta”, “ricevimento merci”, “gestione reclami” o “ticket di assistenza fino alla fatturazione”.

Regola pratica: una fase Strangler dovrebbe coprire un flusso funzionalmente chiuso, che può essere gestito e monitorato end-to-end nel nuovo sistema. Ciò include ingressi (UI, API, importazione), elaborazione (regole di business) e uscite (stampa, export, contabilizzazione, notifiche).

Strangler braucht einen „Umlenker“: Gateway, Proxy oder Routing-Schicht

Affinché gli utenti e i sistemi collegati non debbano ogni volta imparare nuovi endpoint, si impiega spesso uno strato di routing. A seconda della situazione iniziale può trattarsi di: un reverse proxy davanti alle applicazioni web, un API-Gateway per endpoint di servizio o uno strato di integrazione che aggrega interfacce file ed eventi. Decisiva è l’operatività: configurazione centrale, log chiari, monitoring e un rollback controllato.

Per gli amministratori è importante che questo strato non diventi una black box. Hanno bisogno di instradamenti tracciabili (quale request è andata dove), correlazione tramite log (es. Request-ID) e timeout/regole di retry definiti, in modo che gli errori non si „incollino“.

Parallelbetrieb ist ein Betriebszustand – kein „Projekttrick“

Funzionamento parallelo significa: componenti vecchie e nuove lavorano contemporaneamente in produzione per un periodo. Questo è normale, ma costoso – soprattutto in esercizio. Avrete più elementi in movimento, più monitoring, maggiore potenziale di incidenti e responsabilità più complesse. Per questo il funzionamento parallelo deve essere pianificato come modalità operativa limitata nel tempo, inclusi criteri di interruzione.

Typische Parallelbetriebs-Modelle (und wann sie passen)

• Passaggio per gruppi di utenti (gruppo pilota → ondate): adatto quando i ruoli utente sono chiaramente separabili e i processi non attraversano i gruppi.
• Passaggio per mandanti/sedi: indicato per strutture filiali/impianti, se i flussi di dati tra sedi sono limitati.
• Passaggio per fasi di processo: p.es. „acquisizione nuova, fatturazione ancora vecchia“ – rischioso se esistono molte retroazioni, ma talvolta inevitabile.
• Passaggio per tipologie di oggetto: p.es. nuovi cespiti nel nuovo sistema, parco storico nel vecchio – può funzionare se esistono regole chiare per lo storico/reporting.

Dal punto di vista operativo dovreste progettare il funzionamento parallelo in modo che i domini di errore rimangano piccoli: un guasto nella nuova componente non deve trascinare il sistema legacy (p.es. tramite interfacce bloccanti o lock sul database), e viceversa il legacy non deve sabotare tutti i nuovi flussi tramite esportazioni instabili.

Feature Flags und Routing-Regeln: Kontrolle statt „wir rollen aus und hoffen“

I Feature Flag sono interruttori con cui attivate/disattivate funzioni selettivamente – senza nuovo deployment. Per la direzione IT e i responsabili di progetto non è il dettaglio tecnico a essere decisivo, ma la governance: chi può commutare? Come si documenta il motivo del cambiamento? Quanto rapidamente si può tornare indietro? Quali dipendenze emergono (p.es. se i dati sono già stati generati nel nuovo formato)?

Una pratica sensata è un piccolo protocollo di change (Decision Log) per ogni azione di commutazione: momento, owner, gruppo di utenti coinvolto, effetto atteso, indicatori di monitoraggio, condizione di rollback. Questo previene il classico „nessuno sa più perché è instradato così“.

Consistenza dei dati nel rollout: il nucleo da cui dipendono molte migrazioni

La coerenza dei dati significa che i dati siano corretti dal punto di vista funzionale, completi e disponibili nell’ordine previsto. Nel funzionamento parallelo questo diventa difficile, perché due sistemi scrivono contemporaneamente o almeno entrambi rivendicano la „verità“. Qui si decide se la sostituzione del sistema legacy risulterà stabile o se vi troverete a eseguire confronti dei delta per mesi.

Prima chiarire: chi è il „System of Record“ per ciascun ambito dati?

Per ciascun ambito dati (p. es. clienti, articoli, prezzi, ordini, movimenti di magazzino, documenti) è necessaria una determinazione su quale sistema sia dominante. Non è solo una questione architetturale, ma operativa:

• Dove vengono effettuate le correzioni in caso di assistenza?
• Dove risiede il processo di approvazione (quattro occhi, SoD/separazione dei ruoli)?
• Quali tracce di audit sono necessarie (chi ha modificato cosa e quando)?
• Come si evita di dover effettuare lavorazioni correttive nella chiusura mensile?

Nelle prime fasi del pattern Strangler spesso conviene lasciare inizialmente il sistema legacy come responsabile dei dati e fare in modo che il nuovo componente si limiti a consumarli. Successivamente invertirete la leadership. Questo cambio di leadership è un traguardo a sé stante e richiede una finestra di cutover chiara oltre a un piano di comunicazione e di accettazione.

Pattern di sincronizzazione: Dual Write, CDC ed eventi – con aspettative realistiche

Esistono diversi modi per sincronizzare i dati tra il sistema vecchio e quello nuovo. Nessuno è „gratuito“.

• Dual Write: un’azione scrive su entrambi i sistemi (p. es. creazione ordine → legacy e nuovo sistema). Vantaggio: disponibilità rapida. Svantaggio: la gestione degli errori è complessa (cosa succede se il Sistema A scrive e il Sistema B no?), inoltre si introducono dipendenze e spesso rischi di performance.
• Change Data Capture (CDC): le modifiche vengono estratte dal log del database o tramite trigger/replica come delta. Vantaggio: disaccoppia applicazione e sincronizzazione. Svantaggio: si replicano anche modifiche „tecniche“ e bisogna ricostruire gli eventi funzionali; inoltre le modifiche di schema nel legacy diventano improvvisamente un rischio per l’integrazione.
• Integrazione basata su eventi: il sistema pubblica eventi funzionali (p. es. „ordine approvato“) che gli altri sistemi consumano. Vantaggio: semantica funzionale chiara. Svantaggio: richiede definizioni precise degli eventi, idempotenza (elaborazione multipla senza effetti collaterali) e un solido modello operativo per il messaging.

Per i decisori è fondamentale: la coerenza dei dati non è binaria. Alcuni processi richiedono forte consistenza (immediatamente corretta, p. es. approvazioni di pagamento), altri tollerano la eventual consistency (breve latenza, p. es. indice di ricerca, reporting, notifiche). Questa classificazione va concordata precocemente con il reparto di business e la revisione/audit.

Conflitti e duplicati: pianificate esplicitamente il „percorso brutto“

In funzionamento parallelo i conflitti tipicamente si manifestano così: due sistemi modificano lo stesso oggetto, ma secondo regole diverse. Oppure un import viene eseguito due volte perché un Retry è arrivato „troppo presto“. Oppure un utente corregge i dati nel sistema legacy, mentre la nuova interfaccia era già stata attivata.

Serve regole vincolanti per questo:

• Konfliktauflösung: „Last write wins“ è raramente corretto dal punto di vista funzionale. Meglio sono priorità (vince il sistema dominante) o regole di merge funzionali (es. dati anagrafici del contatto vs. condizioni).
• Idempotenz: ogni integrazione dovrebbe tollerare elaborazioni ripetute senza duplicati (es. stesso numero documento, stessa referenza esterna).
• Dead-Letter/Quarantäne: i delta non processabili devono essere rintracciabili, con responsabilità chiaramente definite e possibilità di riavvio.

Senza queste regole la consistenza dei dati scivola verso il „confronto su Excel“ e il lavoro manuale di rettifica – con la conseguente frustrazione e costi indiretti difficili da quantificare.

Rollout-Design: Wellen, Abnahmen und Rückfall, ohne den Betrieb zu überlasten

Un buon rollout è più di „deployment + formazione“. In funzionamento parallelo è necessario integrare rollout e operatività: chi si occupa del First-Level in caso di errori? Quali log sono immediatamente disponibili? Come viene gestita l’escalation? Quali processi non possono essere cambiati durante un’onda (es. chiusura mensile, inventario, modifica dei prezzi)?

Wellenplanung mit harten Kriterien

Si è dimostrata efficace una pianificazione a ondate con criteri di ingresso chiari, non solo con date. Esempi di criteri vincolanti:

• Dashboard di monitoring e alerting per la nuova componente sono live e testati (inclusa la riduzione del „rumore“ degli allarmi).
• Runbook per incidenti tipici esistono (timeout, congestione delle code, import errati, errori di autorizzazione).
• Il confronto dei delta è automatizzato e produce report comprensibili (differenze per tipo di oggetto, finestra temporale, classe di causa).
• Il meccanismo di rollback è stato provato (almeno in Staging/Pre-Prod in modo realistico).

Proprio l’ultimo punto è sottovalutato: rollback non significa „torniamo indietro“. Se il nuovo sistema ha già generato dati, dovete sapere come questi dati saranno visibili nel sistema legacy o come migrare/neutralizzare correttamente i dati prodotti.

Cutover-Mini-Cutovers statt Big Bang

Anche nello Strangler Pattern ci sono cutover – solo che più piccoli. Tipici sono i mini-cutover durante il cambiamento di un passaggio di processo o nel trasferimento della responsabilità dei dati. Ogni mini-cutover richiede:

• Congelamento dei dati (breve, ma vincolante): chi può modificare cosa durante questo periodo?
• Confronto: cosa è stato modificato dall’ultima sincronizzazione?
• Commutazione: routing/feature flags, job, pianificazioni, autorizzazioni.
• Verifica: smoke test funzionali (es. creare ordine → bolla di consegna → fattura), oltre a controlli tecnici (code, tassi di errore, carico DB).

Per la direzione IT è importante che questi passaggi siano documentati come processo ripetibile e garantiti dal punto di vista delle risorse. Altrimenti il successo del progetto dipende da singole persone che „sanno come si fa“.

Schnittstellen zuerst stabilisieren: Das unterschätzte Fundament der Legacy-Ablösung

Molti sistemi legacy comunicano tramite interfacce cresciute nel tempo: esportazioni CSV in cartelle, job notturni, accessi diretti al database da parte di tool di terze parti, workflow basati su e-mail. Una sostituzione graduale diventa nettamente più semplice se inizialmente inventariate il panorama delle interfacce e lo consolidate in pochi punti.

Praticamente significa: identificate i punti di integrazione critici per il sistema (es. contabilità finanziaria, spedizioni, riscontri di produzione, identità/autorizzazioni) e definite lì contratti chiari. „Contratto“ qui non indica l’ambito giuridico, ma la stabilità tecnica: versionamento, campi univoci, ID stabili, gestione degli errori documentata, SLA definiti per la consegna dei dati.

Se instaurate un modello interno di API-/Integration-Governance (Owner, regole di deprecation, percorsi di test/staging), il rischio che una modifica al legacy renda improvvisamente inutilizzabile la vostra nuova componente diminuisce. Un aggancio tematico adatto per un collegamento interno potrebbe essere, per esempio, un contributo su API-Governance e strategie di deprecation.

Security, Berechtigungen und Audit: Parallelbetrieb verschärft das Thema

In fase di funzionamento parallelo spesso esistono modelli di utenti e ruoli duplicati. Questo genera diritti ombra: un utente nel sistema nuovo può essere correttamente limitato, mentre nel legacy mantiene ancora permessi estesi — e finisce per usare la «via più semplice». A ciò si aggiungono account tecnici (Service Accounts) per sincronizzazione, importazioni, code e job batch.

Punti concreti da chiarire tempestivamente:

• Identity-Quelle: Da dove provengono utenti e gruppi? AD/Entra ID? Un proprio IAM? È importante che la procedura di provisioning sia rintracciabile.
• Rollenmapping: Se i ruoli non combaciano 1:1, servono ruoli di transizione, a tempo determinato e da ricertificare.
• Service Accounts: privilegi minimi, rotazione dei segreti, registrazione accurata. In particolare gli account di sincronizzazione costituiscono altrimenti un varco d’ingresso e sono difficili da auditare.
• Audit-Trails: Se la responsabilità dei dati cambia, deve essere chiaro dove risiede la prova delle modifiche e come questa rimanga ricercabile attraverso entrambi i sistemi.

Importante per i decisori: Security qui non è «scope aggiuntivo», ma influisce sulla fattibilità del rollout. Applicare successivamente le autorizzazioni durante il funzionamento parallelo è di solito più costoso che definire precocemente, in modo pragmatico, la segmentazione di ruoli e account di servizio.

Monitoring, Logging und Betriebsübergabe: Ohne Observability wird Parallelbetrieb blind

In funzionamento parallelo i pattern di errore sono spesso indiretti: un delta resta bloccato, un retry gira all’infinito, una coda si accumula, o un job sensibile al tempo collide con un lock sul database. Se lo vedete solo tramite ticket degli utenti, arrivate troppo tardi. Serve dunque fin dall’inizio un minimo di observability: Monitoring (stato), Logging (eventi) e — dove sensato — Tracing (catena attraverso i sistemi).

Segnali pratici e gestibili sono, ad esempio:

• Backlog di sincronizzazione (quante modifiche „sono in attesa“), più età della voce più vecchia.
• Tassi di errore per interfaccia e per classe di errore (validazione, timeout, autenticazione, conflitto dati).

Per il passaggio in esercizio conta meno quale strumento viene utilizzato e più che responsabilità e Runbooks siano chiari. Se avete On-Call o reperibilità, l’esercizio deve rimanere operativo nelle interruzioni tipiche senza che servano indagini da parte degli sviluppatori.

Quando lo Strangler Pattern non è adatto (o solo con chiare limitazioni)

Ci sono situazioni in cui un’adozione graduale funziona solo in maniera limitata:

• Accoppiamento transazionale estremamente stretto: se quasi ogni operazione attraversa tutti i moduli e richiede consistenza rigorosa, il funzionamento parallelo diventa rapidamente ingestibile.
• Accessi diretti al DB da parte di sistemi terzi: se più strumenti scrivono/leggono direttamente tabelle legacy, bisogna prima fermare o controllare questo proliferare.
• Proprietà dei dati poco chiara: se non si può stabilire chi è il responsabile dei dati, i conflitti sono garantiti – e la sostituzione diventa politica invece che tecnica.
• Disciplina operativa insufficiente: senza ambienti puliti, deployment riproducibili e monitoring, ogni step intermedio diventa a rischio.

Questo non significa che siate costretti al Big Bang. Ma allora dovete cambiare l’ordine: prima stabilizzare i punti di integrazione, centralizzare gli accessi ai dati, chiarire ruoli e ownership – e solo dopo applicare lo Strangler Pattern.

Un piano operativo pratico per la dismissione graduale del legacy

A scopo direttivo per i responsabili di progetto, si è dimostrato utile un processo in fasi chiare. La forma esatta dipende dal sistema e dal settore, ma la logica è solida:

1. Inventario e dipendenze: interfacce, job, flussi di dati, gruppi di utenti, finestre temporali critiche (chiusura, inventario).
2. Definire i punti di interfaccia: moduli di processo, responsabilità sulla fonte dei dati per area, contratti di integrazione.
3. Implementare routing e switch: Gateway/Proxy, Feature Flags, registrazione centrale.
4. Definire il percorso dei dati: CDC/eventi/dual write, regole di conflitto, quarantena, report di riconciliazione.
5. Pilota con carico reale: non solo demo, ma con casi reali, incluse le eccezioni.
6. Rollout a ondate: criteri di ingresso, checklist di cutover, esercitazioni di rollback.
7. Spegnere e pulire: disattivare percorsi legacy, rimuovere job, revocare permessi, aggiornare la documentazione.

L’ultimo punto è essenziale: molte organizzazioni lasciano i componenti legacy „per sicurezza“ in funzione. Risultato: costi duplicati, rischio poco chiaro, nessuno si azzarda a spegnere. Pianificate il decommissioning come sotto-progetto con scadenza, responsabili e evidenze (es. „nessun accesso da X settimane“, „tutte le esportazioni convertite“, „requisiti di audit soddisfatti“).

Conclusione: Sostituire passo dopo passo significa trattare la consistenza e l’esercizio come un prodotto

Una dismissione del legacy passo per passo non è automaticamente più semplice – ma in molte aziende è l’unica opzione realistica. Lo Strangler Pattern funziona se per ogni fase definite chiare interfacce di processo, pianificate il funzionamento parallelo come vero stato operativo e non lasciate la consistenza dei dati al caso. Decisivi sono decisioni precoci sulla ownership dei dati, pattern di sincronizzazione robusti con regole di conflitto, nonché un design di rollout con onde, accettazioni e procedure di fallback praticate.

Se pianificate una sostituzione e desiderate discutere in modo strutturato le interfacce, il funzionamento parallelo o il concetto di consistenza dei dati, potete contattarci tramite .

Discutere progetto o intervento di modernizzazione con Net-Base.