Legacy systems are simultaneously the most critical and most fragile components of most organizations' technology landscape. They run core business processes, contain decades of institutional knowledge embedded in their logic, and are understood by a shrinking pool of specialists. They are also slow, expensive to maintain, impossible to integrate with modern tools, and a growing security risk.
The temptation is a big-bang replacement: build the new system, flip the switch, decommission the old one. This approach has a catastrophic failure rate. A 2025 Standish Group report found that 67% of large-scale system replacement projects exceed their budget by more than 50%, and 28% are cancelled entirely. The organizations that succeed use incremental migration strategies that reduce risk and deliver value continuously.
Named after the tropical fig that gradually envelops and replaces its host tree, the strangler fig pattern is the safest approach to legacy system migration. Instead of replacing the old system all at once, you build new functionality alongside it and gradually redirect traffic and processes from old to new.
The pattern works in three steps. First, identify a specific business function handled by the legacy system that can be isolated. Second, build a modern replacement for that specific function. Third, route requests for that function to the new system while the legacy system continues to handle everything else. Repeat until the legacy system has no remaining functions and can be decommissioned.
The key architectural requirement is a routing layer (sometimes called a facade or proxy) that sits between users and both systems. This layer decides which system handles each request based on the migration status of each function. It also handles data synchronization between old and new systems during the transition period.
The strangler fig pattern typically takes 2-3x longer than a big-bang approach in total calendar time. But it delivers value from the first migrated function (usually within 3-4 months), maintains business continuity throughout, and has a dramatically lower risk of catastrophic failure.
Data migration is where legacy modernization projects most frequently derail. Legacy systems often contain data that is inconsistent, undocumented, or encoded in formats that no longer make sense. A customer record that has been modified by 15 different versions of the software over 20 years may contain fields that mean different things depending on when they were last updated.
Start with a comprehensive data audit. Map every table, field, and relationship in the legacy database. Identify data quality issues: null values where they should not exist, inconsistent formats (dates stored as strings in multiple formats), orphaned records, and duplicate entries. Quantify the scale of each issue -- a few hundred bad records can be fixed manually; a few hundred thousand require automated remediation.
Build a data transformation pipeline that cleans, normalizes, and migrates data in repeatable, testable batches. Never do a one-time data dump. Run the migration pipeline multiple times in a test environment, comparing source and destination data at each iteration. Only when the pipeline produces identical results across multiple consecutive runs should you execute it in production.
For mission-critical systems, parallel running is essential. Both old and new systems process the same transactions simultaneously, and automated reconciliation compares the outputs. Any discrepancy triggers an alert for investigation before the old system is decommissioned.
Parallel running adds cost and complexity, but it provides an invaluable safety net. The reconciliation process catches bugs, data migration errors, and business logic discrepancies that testing alone would miss. Plan for a minimum parallel running period of 30 days for non-critical functions and 90 days for critical functions like financial processing or customer-facing operations.
During parallel running, the old system remains the system of record. Users interact with the new system, but if a discrepancy is detected, the old system's output is used while the issue is investigated. Only when the new system has proven itself through sustained error-free parallel operation does it become the system of record and the old system is demoted to a backup role.
Legacy system migration is as much an organizational challenge as a technical one. The people who know the legacy system best are often the most resistant to replacing it -- they have built their expertise and sometimes their career identity around that system.
Involve legacy system experts from day one of the migration project. Their knowledge of business rules, edge cases, and workarounds is irreplaceable and cannot be extracted from documentation alone. Position them as essential contributors to the new system, not as defenders of the old one. Many of the most valuable insights about what the new system needs come from people who have spent years working around the old system's limitations.
Plan for a temporary productivity dip during migration. Users will be slower on the new system than on the old one for the first 2-4 weeks. Budget for this in your project timeline and communicate it explicitly to business stakeholders. The productivity dip is real but temporary -- within 6-8 weeks, most users report higher productivity on the new system than they had on the old one.
Non tutte le migrazioni di sistemi legacy seguono lo stesso schema. I quattro approcci qui sotto scambiano velocità con rischio. Per la maggior parte dei sistemi critici vince lo strangler fig, ma uno strumento interno a basso rischio può giustificare una via più rapida.
| Approccio | Rischio | Fermo | Costo relativo | Quando usarlo |
|---|---|---|---|---|
| Big Bang | Alto | Ore o giorni al passaggio | Basso all'inizio, alto se fallisce | Sistemi piccoli e ben compresi che puoi permetterti di rifare |
| Strangler Fig | Basso | Nessuno (reindirizzamento graduale) | Più alto in totale, distribuito nel tempo | Sistemi critici che devono restare attivi |
| Parallel Run | Molto basso | Nessuno (girano entrambi) | Il più alto (due sistemi insieme) | Sistemi finanziari o a contatto col cliente dove un numero sbagliato è inaccettabile |
| A fasi / modulare | Medio | Breve per modulo | Moderato | Sistemi che si dividono in modo netto in moduli indipendenti |
Metti a budget una cifra compresa tra il 15% e il 40% di quanto costerebbe una riscrittura da zero. La ripartizione raramente corrisponde a quella ipotizzata nella stima iniziale. Licenze e infrastruttura, la voce attorno a cui si costruisce quasi ogni budget, finiscono in fondo alla lista, mentre il lavoro sui dati e il periodo di esercizio parallelo occupano i primi due posti.
| Voce di costo | Quota tipica del budget | Cosa la fa crescere |
|---|---|---|
| Estrazione, pulizia e riconciliazione dei dati | dal 30% al 40% | Schemi non documentati, record duplicati, anni di correzioni improvvisate |
| Realizzazione o configurazione della nuova piattaforma | dal 25% al 35% | I flussi di lavoro su misura attorno a cui è cresciuto il sistema legacy |
| Esercizio parallelo | dal 10% al 20% | Ogni mese in più speso per tenere accesi entrambi i sistemi |
| Rifacimento delle integrazioni | dal 10% al 15% | Gli strumenti a valle che leggono direttamente dal database legacy |
| Formazione e accompagnamento al cambiamento | dal 5% al 10% | Il personale che usa le stesse schermate da dieci anni |
| Licenze e infrastruttura | dal 5% al 10% | Raramente la sorpresa, e raramente la voce più alta |
Un distributore con 40 dipendenti che sostituiva un sistema di gestione ordini del 2009 aveva stanziato 120.000 euro su nove mesi. La realizzazione della piattaforma è rimasta vicina al piano, a 38.000. Lo sforamento è arrivato dai dati. Quattordici anni di storico ordini contenevano 60.000 anagrafiche clienti, scese a 41.000 una volta uniti i duplicati, e riconciliarle ha richiesto undici settimane invece di quattro, per 52.000. L'esercizio parallelo ha aggiunto 18.000 perché l'amministrazione non ha dato il via libera finché due chiusure mensili complete non hanno coinciso. La spesa finale è stata di 141.000, il diciassette per cento in più, e tutto lo sforamento si è concentrato nelle due voci che il budget iniziale trattava come arrotondamenti.
Quantifica il lavoro sui dati prima della piattaforma. Se nessuno sa dirti quanti record esistono e quanti di questi sono duplicati, non hai un budget ma una supposizione.
Dipende dall'approccio e dalle dimensioni del sistema. Un big-bang di uno strumento piccolo può chiudersi in settimane, mentre una migrazione strangler fig di un sistema critico di solito dura 2 o 3 volte di più in tempo di calendario ma consegna la prima funzione entro 3 o 4 mesi. La maggior parte delle migrazioni legacy aziendali dura da 12 a 24 mesi.
Gli approcci a fasi come lo strangler fig sono molto più sicuri per tutto ciò che è critico. Il big-bang sostituisce l'intero sistema in una volta, e un report Standish Group del 2025 stima al 67% il tasso di sforamento di budget per le grandi sostituzioni. Una migrazione a fasi tiene attivo il vecchio sistema mentre sposti una funzione alla volta, così un problema non blocca mai tutta l'azienda.
I dati. I sistemi legacy accumulano record incoerenti e non documentati per anni, e una migrazione legacy vive o muore sulla pulizia di quei dati. Verifica e pulisci i dati per primi, esegui la pipeline di migrazione più volte in un ambiente di test e riconcilia origine e destinazione prima di qualsiasi passaggio in produzione.
Parte della nostra guida completa: Trasformazione Digitale →
Questo articolo fa parte del nostro knowledge hub su digital transformation. Leggi la guida completa per un framework strategico completo.
Il nostro team aiuta le aziende a implementare i framework e le strategie trattate in questo articolo.
Contattaci