Sustitución de sistemas heredados paso a paso: Strangler Pattern, operación en paralelo y consistencia de datos en el despliegue

Una sustitución de sistemas heredados raramente fracasa por el “construir” de la nueva solución, sino en la transición: los datos deben mantenerse correctos, las interfaces no deben romperse y la operación debe continuar durante la migración. En muchas empresas un Big-Bang-Cutover, por eso, no es una opción: las dependencias son demasiado grandes, los costes de inactividad demasiado altos y la reversión demasiado compleja.

En la práctica resulta eficaz un enfoque gradual con Strangler Pattern (las partes funcionales se van “traspasando” progresivamente), funcionamiento en paralelo (el sistema antiguo y el nuevo funcionan temporalmente uno al lado del otro) y reglas claras para la consistencia de datos. Este artículo muestra cómo combinar estos elementos de modo que sean sostenibles en el día a día de la dirección de TI, la administración y la responsabilidad de proyecto —incluye patrones de error típicos, consecuencias operativas y puntos de decisión en el despliegue.

Por qué el enfoque paso a paso suele ser la sustitución de sistemas heredados realista

Los sistemas heredados rara vez son “solo una aplicación”. Por lo general están conectados a: procesos por lotes, interfaces de archivos (carpetas SFTP, unidades de red), procesos de impresión y escaneo, herramientas locales, extractos de BI, relés de correo electrónico, hardware especializado, salidas de Shadow IT y soluciones manuales. Con un Big Bang todos estos canales deben funcionar el mismo fin de semana —incluyendo permisos, datos maestros, historiales y casos especiales.

El enfoque paso a paso reduce el riesgo, pero no lo elimina automáticamente. Lo hace más visible y manejable, y exige decisiones limpias de arquitectura y operación: ¿dónde se enruta? ¿Quién es el responsable de los datos? ¿Qué consistencia es obligatorio desde el punto de vista funcional y dónde basta una demora temporal? ¿Y cómo evitar que el funcionamiento en paralelo se convierta en una obra permanente?

Strangler Pattern en la realidad empresarial: no „Microservices“, sino interfaces claramente definidas

El Strangler Pattern significa: se implementan nuevas funciones junto al sistema legado y se redirige el tráfico de forma gradual hasta que la parte antigua queda obsoleta. Importante: no se trata de una guerra religiosa de arquitecturas („Monolith vs. Microservices“), sino de un patrón de migración. Funciona igualmente si la arquitectura objetivo sigue siendo un monolito —simplemente más moderna, mantenible y mejor integrable.

La decisión más importante: corte por procesos, no por tablas

En muchas sustituciones se segmenta impulsado por los datos („empezamos por las tablas de clientes y pedidos“). Esto suele derivar en un funcionamiento paralelo doloroso porque los procesos atraviesan esos datos. Es mejor un corte orientado a procesos, p. ej. „generación de ofertas“, „recepción de mercancías“, „gestión de reclamaciones“ o „desde el ticket de servicio hasta la factura“.

Regla práctica: Una etapa Strangler debe cubrir un flujo funcionalmente cerrado que pueda operarse y supervisarse de extremo a extremo en el nuevo sistema. Esto incluye entradas (UI, API, importación), procesamiento (reglas de negocio) y salidas (impresión, exportación, contabilización, notificación).

El Strangler necesita un „desvío“: Gateway, Proxy o capa de enrutamiento

Para que los usuarios y los sistemas conectados no tengan que aprender nuevos endpoints cada vez, con frecuencia se emplea una capa de enrutamiento. Según la situación inicial puede ser: un Reverse Proxy delante de aplicaciones web, un API-Gateway para endpoints de servicio o una capa de integración que centralice interfaces de archivos y eventos. Lo decisivo es la operatividad: configuración central, logs claros, monitorización y un rollback controlado.

Para los administradores es importante que esta capa no se convierta en una caja negra. Necesitan enrutamientos trazables (qué request fue a dónde), correlación a través de los registros (p. ej. Request-ID) y timeouts/reglas de reintento definidos, para que los errores no se “peguen”.

La operación en paralelo es un estado operativo – no un „truco de proyecto“

Operación en paralelo significa: componentes antiguos y nuevos funcionan simultáneamente en producción durante un tiempo. Es normal, pero caro —especialmente en operación. Tendrá más componentes en movimiento, más monitorización, más potencial de incidentes y responsabilidades más complejas. Por eso la operación en paralelo debe planificarse como un modo operativo con duración limitada, incluyendo criterios de interrupción.

Modelos típicos de operación en paralelo (y cuándo encajan)

• Cambio por grupos de usuarios (grupo piloto → oleadas): adecuado cuando los roles de usuario son claramente separables y los procesos no atraviesan grupos.
• Cambio por mandantes/ubicaciones: apropiado en estructuras de sucursales/plantas cuando los flujos de datos entre ubicaciones son limitados.
• Cambio por pasos de proceso: p. ej. „captura nueva, facturación aún en el sistema antiguo“ – arriesgado si existen muchos bucles de retroalimentación, pero a veces imprescindible.
• Cambio por tipo de objeto: p. ej. activos nuevos en el sistema nuevo, saldos históricos en el antiguo – puede funcionar si existen reglas claras para el histórico/informes.

Desde la perspectiva operativa debe diseñar la operación en paralelo de modo que los dominios de fallo se mantengan pequeños: un defecto en el componente nuevo no debe arrastrar al sistema legacy (p. ej. por interfaces bloqueantes o bloqueos de base de datos), y a la inversa el legacy no debe sabotear todos los flujos nuevos mediante exportaciones inestables.

Feature Flags y reglas de enrutamiento: control en lugar de „desplegamos y esperamos“

Feature Flags son interruptores con los que puede activar/desactivar funciones de forma selectiva —sin un nuevo despliegue. Para la dirección de TI y los responsables de proyecto no es el detalle técnico lo decisivo, sino la gobernanza: ¿Quién puede accionar el interruptor? ¿Cómo se documenta por qué se realizó el cambio? ¿Con qué rapidez se puede revertir? ¿Qué dependencias surgen (p. ej. si ya se han generado datos en el nuevo formato)?

Una práctica sensata es un pequeño protocolo de cambios (Decision Log) por cada acción de conmutación: momento, Owner, grupo de usuarios afectado, efecto esperado, indicadores de monitorización, condición de rollback. Esto evita el clásico “ya nadie sabe por qué está enrutado así”.

Consistencia de datos en el despliegue: el núcleo del que dependen muchas migraciones

La consistencia de datos significa que los datos están correctos desde el punto de vista funcional, completos y disponibles en el orden esperado. En funcionamiento paralelo esto se complica, porque dos sistemas escriben al mismo tiempo o al menos ambos reclaman ser la «verdad». De ello depende si la sustitución del sistema heredado es estable o si acabará haciendo conciliaciones de deltas durante meses.

Aclarar primero: ¿Quién es el „System of Record“ por cada área de datos?

Necesita por cada área de datos (p. ej. deudores, artículos, precios, pedidos, movimientos de almacén, documentos) una definición de qué sistema es el líder. Esto no es solo un tema de arquitectura, sino operativo:

• ¿Dónde se realizan las correcciones en caso de soporte?
• ¿Dónde reside el proceso de aprobación (Vier-Augen, SoD/separación de funciones)?
• ¿Qué rastros de auditoría son necesarios (quién cambió qué y cuándo)?
• ¿Cómo se evitan retrabajos en el cierre mensual?

En las etapas iniciales del patrón Strangler suele ser aconsejable dejar al sistema heredado como líder de datos y que el nuevo componente „solo“ consuma. Más adelante invertirá la responsabilidad. Este cambio de liderazgo es un hito por sí mismo y requiere una ventana de cutover clara, así como un plan de comunicación y de aceptación.

Patrones de sincronización: Dual Write, CDC y eventos – con expectativas realistas

Hay varias formas de sincronizar datos entre lo antiguo y lo nuevo. Ninguna es „gratuita“.

• Dual Write: Una acción escribe en ambos sistemas (p. ej., crear pedido → sistema heredado y sistema nuevo). Ventaja: disponibilidad rápida. Desventaja: el manejo de errores es complejo (¿qué pasa si el Sistema A escribe y el Sistema B no?), además genera dependencias y a menudo riesgos de rendimiento.
• Change Data Capture (CDC): Los cambios se extraen del log de la base de datos o mediante triggers/replicación como deltas. Ventaja: desacopla la aplicación de la sincronización. Desventaja: también replica cambios „técnicos“ y hay que reconstruir los eventos funcionales; además, los cambios de esquema en el sistema heredado se convierten repentinamente en un riesgo de integración.
• Integración basada en eventos: El sistema publica eventos funcionales (p. ej., „pedido aprobado“) que consumen otros sistemas. Ventaja: semántica funcional clara. Desventaja: requiere definiciones de eventos limpias, idempotencia (procesamiento múltiple sin causar efectos) y un concepto operacional de mensajería robusto.

Para los decisores es clave: la consistencia de datos no es binaria. Algunos procesos requieren consistencia fuerte (inmediata y correcta, p. ej., aprobaciones de pago), otros toleran la consistencia eventual (pequeña demora, p. ej., índice de búsqueda, reporting, notificaciones). Esta clasificación debe acordarse pronto con el área de negocio y con revisión/auditoría.

Conflictos y duplicados: planifique explícitamente el „camino feo“

En funcionamiento en paralelo, los conflictos suelen surgir así: dos sistemas modifican el mismo objeto, pero con reglas diferentes. O una importación se ejecuta dos veces porque un reintento llegó «demasiado pronto». O un usuario corrige datos en el sistema heredado mientras la nueva interfaz ya se ha cambiado.

Necesita reglas vinculantes para ello:

• Resolución de conflictos: «la última escritura prevalece» rara vez es correcta desde el punto de vista funcional. Mejor son prioridades (gana el sistema principal) o reglas de fusión basadas en la lógica del negocio (p. ej., datos maestros de contacto frente a condiciones).
• Idempotencia: cada integración debe soportar procesamientos múltiples sin duplicados (p. ej., mismo número de documento, misma referencia externa).
• Dead-Letter/Cuarentena: los deltas no procesables deben poder localizarse, con responsabilidad clara y posibilidad de reintento.

Sin estas reglas, la consistencia de los datos deriva en „conciliaciones en Excel“ y trabajos manuales posteriores, con la consiguiente frustración y costes secundarios difíciles de medir.

Diseño del despliegue: oleadas, aprobaciones y reversión sin sobrecargar la operación

Un buen despliegue es más que «despliegue + formación». En operación en paralelo debe entrelazarse despliegue y operación: ¿quién atiende el soporte de primer nivel ante errores? ¿Qué logs están disponibles de inmediato? ¿Cómo se escalan las incidencias? ¿Qué procesos no deben cambiarse durante una oleada (p. ej., cierre mensual, inventario, ajuste de precios)?

Planificación por oleadas con criterios estrictos

Ha sido efectivo planificar por oleadas con criterios de entrada claros, no solo con fechas. Ejemplos de criterios estrictos:

• Los dashboards de monitorización y el alerting para el nuevo componente están en producción y probados (incluyendo reducción del ruido de alertas).
• Existen runbooks para incidentes típicos (timeouts, congestión de colas, importaciones erróneas, errores de permisos).
• La conciliación de deltas está automatizada y entrega informes comprensibles (diferencias por tipo de objeto, intervalos temporales, clase de causa).
• El mecanismo de reversión está ensayado (al menos reproducido de forma realista en Staging/Pre-Prod).

Precisamente este último punto suele subestimarse: la reversión no es «volvemos a activar lo anterior». Si el nuevo sistema ya ha generado datos, debe saber cómo esos datos serán visibles en el sistema heredado o cómo migrarlos/neutralizarlos correctamente.

Mini-cutovers en lugar de Big Bang

Incluso con el patrón Strangler hay cutovers, solo que más pequeños. Son típicos los mini-cutovers al cambiar un paso del proceso o al modificar la responsabilidad de los datos. Cada mini-cutover requiere:

• Congelación de datos (corta, pero obligatoria): ¿quién puede modificar qué durante ese periodo?
• Conciliación: ¿qué se ha modificado desde la última sincronización?
• Conmutación: enrutamiento/feature flags, tareas, cronogramas, permisos.
• Verificación: pruebas de humo funcionales (p. ej., crear pedido → albarán → factura), más comprobaciones técnicas (colas, tasa de errores, carga de la base de datos).

Para la dirección de TI es importante que estos pasos estén documentados como un proceso repetible y respaldados a nivel de personal. De lo contrario, el éxito del proyecto depende de individuos que «saben cómo hacerlo».

Estabilizar primero las interfaces: el fundamento subestimado de la sustitución del sistema heredado

Muchos sistemas heredados se comunican mediante interfaces acumuladas: exportaciones CSV a carpetas, tareas nocturnas, accesos directos a la base de datos por herramientas de terceros, flujos de trabajo basados en correo electrónico. Una sustitución gradual resulta considerablemente más fácil si primero inventariza el panorama de interfaces y lo consolida en unos pocos puntos.

Prácticamente esto significa: Identifique los puntos de integración críticos para el sistema (p. ej., contabilidad financiera, envío, notificaciones de producción, identidades/privilegios) y establezca allí contratos claros. «Contrato» aquí no se refiere a lo jurídico, sino a la estabilidad técnica: versionado, campos inequívocos, IDs estables, manejo de errores documentado, SLAs definidos para la entrega de datos.

Si para ello establece un modelo interno de gobernanza de API/integración (propietario (Owner), reglas de deprecación, rutas de test/staging), disminuye el riesgo de que un cambio en el legacy deje paralizada su nueva componente. Un punto de enlace interno apropiado sería, por ejemplo, un artículo sobre gobernanza de API y estrategias de deprecación.

Seguridad, permisos y auditoría: la operación en paralelo agrava el tema

En la operación en paralelo suelen coexistir modelos duplicados de usuarios y roles. Eso conduce a permisos en la sombra: un usuario está correctamente restringido en el sistema nuevo, pero todavía tiene amplios derechos en el legacy y acaba utilizando el «camino más sencillo». Además existen cuentas técnicas (Service Accounts) para sincronización, importaciones, colas y jobs por lotes.

Puntos concretos que debería aclarar pronto:

• Fuente de identidad: ¿De dónde provienen usuarios y grupos? ¿AD/Entra ID? ¿Un IAM propio? Es importante que la provisión sea comprobable.
• Mapeo de roles: Si los roles no encajan 1:1, hacen falta roles de transición con duración limitada que se recertifiquen.
• Cuentas de servicio (Service Accounts): privilegios mínimos, rotación de secretos, registro limpio. Especialmente las cuentas de sincronización suelen ser una vía de entrada y difíciles de auditar.
• Trazas de auditoría (Audit-Trails): Cuando cambia la autoridad de los datos, debe quedar claro dónde reside la evidencia de los cambios y cómo puede investigarse a través de ambos sistemas.

Importante para los decisores: la seguridad aquí no es un «alcance adicional», sino que afecta la viabilidad del despliegue. Añadir permisos más tarde durante la operación en paralelo suele ser más caro que una definición temprana y pragmática de roles y cuentas de servicio.

Monitorización, registro y traspaso operativo: sin observabilidad la operación en paralelo queda a ciegas

En la operación en paralelo los patrones de error suelen ser indirectos: un delta se queda atascado, un retry se ejecuta indefinidamente, una cola se acumula, o un job crítico en tiempo choca con un bloqueo de base de datos. Si solo lo detecta mediante tickets de usuarios, llega tarde. Por eso necesita desde el principio un mínimo de observabilidad: monitorización (estado), logging (eventos) y —donde proceda— tracing (cadena entre sistemas).

Señales prácticas y operables son, por ejemplo:

• Backlog de sincronización (cuántos cambios «esperan»), además de la antigüedad de la entrada más antigua.
• Tasas de error por interfaz y por clase de error (validación, timeout, autenticación, conflicto de datos).

Para la transferencia al equipo de operación importa menos la herramienta utilizada y más que las responsabilidades y los runbooks estén claros. Si dispone de On-Call o guardias, la operación debe ser capaz de actuar ante incidencias habituales sin necesidad de labores detectivescas por parte de los desarrolladores.

Cuándo el Strangler Pattern no encaja (o solo con restricciones claras)

Existen situaciones en las que la sustitución gradual funciona solo de forma limitada:

• Acoplamiento transaccional extremadamente estrecho: si prácticamente cada operación atraviesa todos los módulos y exige consistencia estricta, la operación en paralelo se vuelve rápidamente ingobernable.
• Accesos directos a la BD por sistemas externos: si varias herramientas escriben/leen directamente en tablas legacy, primero hay que detener o controlar ese desorden.
• Indefinición de la titularidad de los datos: si no se puede establecer quién es el propietario de los datos, los conflictos están garantizados y la sustitución se convertirá en una cuestión política en lugar de técnica.
• Falta de disciplina operativa: sin entornos limpios, despliegues reproducibles y monitorización, cada paso intermedio se convierte en un riesgo.

Esto no significa que esté obligado a un Big Bang. Pero entonces debe cambiar el orden: primero estabilizar los puntos de integración, centralizar los accesos a datos, aclarar roles y la titularidad de los datos, y solo después aplicar el strangling.

Un plan de trabajo práctico para la sustitución por fases del legacy

Como orientación para responsables de proyecto, ha demostrado su eficacia un proceso dividido en etapas claras. La forma exacta depende del sistema y del sector, pero la lógica es sólida:

1. Inventario & dependencias: interfaces, Jobs, flujos de datos, grupos de usuarios, ventanas de tiempo críticas (cierre, inventario).
2. Definir puntos de corte: módulos de proceso, titularidad de datos por área, contratos de integración.
3. Construir enrutamiento & conmutadores: Gateway/Proxy, Feature Flags, registro centralizado.
4. Definir la ruta de datos: CDC/Event/Dual Write, reglas de conflicto, cuarentena, informes de conciliación.
5. Piloto con carga real: no solo una demo, sino con casos reales, incluidas las excepciones.
6. Despliegue en olas: criterios de entrada, Cutover-Checklisten, ejercicios de rollback.
7. Apagado & limpieza: desactivar rutas antiguas, eliminar Jobs, revocar permisos, actualizar la documentación.

El último punto es esencial: muchas organizaciones mantienen componentes legacy «por seguridad». Resultado: costes duplicados, riesgo indeterminado, nadie se atreve a apagarlo. Planifique el decommissioning como subproyecto con fecha, responsables y evidencias (p. ej., «sin accesos desde hace X semanas», «todas las exportaciones migradas», «requisitos de auditoría cumplidos»).

Conclusión: sustituir por etapas significa tratar la consistencia y la operación como un producto

Una sustitución del legacy paso a paso no es automáticamente más sencilla, pero en muchas empresas es la única opción realista. El Strangler Pattern funciona si por cada etapa define límites claros de proceso, planifica el funcionamiento en paralelo como un estado operativo real y no deja la consistencia de datos al azar. Son decisivos los acuerdos tempranos sobre la titularidad de los datos, patrones de sincronización robustos con reglas de conflicto, así como un diseño de rollout con olas, aceptaciones y procedimientos de fallback practicados.

Si planifica una sustitución y desea tratar de forma estructurada las interfaces, el funcionamiento en paralelo o el concepto de consistencia de datos, puede ponerse en contacto con nosotros a través de .

Analizar proyecto o iniciativa de modernización con Net-Base.