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.
No toda migración de sistemas legacy debe usar el mismo manual. Los cuatro enfoques siguientes cambian velocidad por riesgo. Para la mayoría de los sistemas críticos gana el patrón strangler fig, pero una herramienta interna de bajo riesgo puede justificar una vía más rápida.
| Enfoque | Riesgo | Inactividad | Coste relativo | Cuándo usarlo |
|---|---|---|---|---|
| Big Bang | Alto | Horas o días en el cambio | Bajo al inicio, alto si falla | Sistemas pequeños y bien conocidos que puedes permitirte repetir |
| Strangler Fig | Bajo | Ninguna (redirección gradual) | Mayor en total, repartido en el tiempo | Sistemas críticos que deben seguir activos |
| Parallel Run | Muy bajo | Ninguna (ambos a la vez) | El más alto (dos sistemas a la vez) | Sistemas financieros o de cara al cliente donde un número erróneo es inaceptable |
| Por fases / modular | Medio | Breve por módulo | Moderado | Sistemas que se dividen limpiamente en módulos independientes |
Presupuesta entre el 15% y el 40% de lo que costaría reconstruir el sistema desde cero. El reparto casi nunca coincide con el de la estimación inicial. Las licencias y la infraestructura, la partida sobre la que se construye casi cualquier presupuesto, quedan al final de la lista, mientras que el trabajo con los datos y el periodo de ejecución en paralelo ocupan los dos primeros puestos.
| Partida de coste | Porcentaje habitual del presupuesto | Qué la dispara |
|---|---|---|
| Extracción, limpieza y conciliación de datos | del 30% al 40% | Esquemas sin documentar, registros duplicados, años de parches improvisados |
| Construcción o configuración de la nueva plataforma | del 25% al 35% | Los flujos de trabajo a medida en torno a los que creció el sistema heredado |
| Ejecución en paralelo | del 10% al 20% | Cada mes adicional pagando por mantener los dos sistemas |
| Rehacer las integraciones | del 10% al 15% | Las herramientas posteriores que leen directamente de la base de datos heredada |
| Formación y acompañamiento al cambio | del 5% al 10% | El personal que lleva una década usando las mismas pantallas |
| Licencias e infraestructura | del 5% al 10% | Rara vez la sorpresa, y rara vez la partida más alta |
Un distribuidor de 40 personas que sustituía un sistema de gestión de pedidos de 2009 presupuestó 120.000 euros en nueve meses. La construcción de la plataforma se quedó cerca del plan, en 38.000. El desvío vino de los datos. Catorce años de histórico de pedidos contenían 60.000 fichas de cliente que se redujeron a 41.000 al fusionar los duplicados, y conciliarlas llevó once semanas en lugar de cuatro, por 52.000. La ejecución en paralelo sumó 18.000 porque administración no dio el visto bueno hasta que dos cierres mensuales completos cuadraron. El gasto final fue de 141.000, un diecisiete por ciento por encima, y todo el desvío se concentró en las dos partidas que el presupuesto inicial trataba como redondeos.
Cuantifica el trabajo con los datos antes que la plataforma. Si nadie sabe decirte cuántos registros existen y cuántos de ellos son duplicados, no tienes un presupuesto sino una suposición.
Depende del enfoque y del tamaño del sistema. Un big-bang de una herramienta pequeña puede terminar en semanas, mientras que una migración strangler fig de un sistema crítico suele durar 2 o 3 veces más en tiempo de calendario pero entrega la primera función en 3 o 4 meses. La mayoría de las migraciones legacy empresariales duran de 12 a 24 meses.
Los enfoques por fases como el patrón strangler fig son mucho más seguros para cualquier cosa crítica. El big-bang cambia todo el sistema a la vez, y un informe de Standish Group de 2025 situó en el 67% la tasa de sobrecoste de las grandes sustituciones. Una migración por fases mantiene el sistema antiguo en marcha mientras mueves una función cada vez, de modo que un problema nunca tumba todo el negocio.
Los datos. Los sistemas legacy acumulan registros inconsistentes y sin documentar durante años, y una migración legacy depende por completo de migrar esos datos con limpieza. Audita y limpia los datos primero, ejecuta la tubería de migración varias veces en un entorno de prueba y reconcilia origen y destino antes de cualquier cambio a producción.
Parte de nuestra guía completa: Transformación Digital →
Este artículo forma parte de nuestro knowledge hub sobre digital transformation. Lee la guía completa para un marco estratégico completo.
Nuestro equipo ayuda a las empresas a implementar los marcos y estrategias tratados en este artículo.
Contáctanos