Substitució de sistemes legats pas a pas: Strangler Pattern, operació paral·lela i consistència de dades en el Rollout

Una substitució de sistemes legats rara vegada fracassa per «construir» la nova solució, sinó per la transició: les dades han de romandre correctes, les interfícies no s’han de trencar i l’explotació ha de continuar durant la transformació. En moltes empreses, per això, un Big-Bang-Cutover no és una opció: les dependències són massa grans, els costos d’aturada massa alts i la reversió massa complicada.

En la pràctica funciona un enfocament pas a pas amb Strangler Pattern (parts funcionals s’aniran «redireccionant» una a una), Parallelbetrieb (el sistema antic i el nou coexisteixen temporalment) i regles clares per a la consistència de dades. Aquest article mostra com combinar aquests blocs perquè siguin sostenibles en el dia a dia de la direcció IT, l’administració i els responsables de projecte —incloent-hi patrons d’errors típics, conseqüències operatives i punts de decisió en el rollout.

Per què l’enfocament pas a pas sovint és la substitució de legacy realista

Els sistemes legats rarament són «només una aplicació». Sovint hi estan connectats: execucions per lots, interfícies de fitxers (carpetes SFTP, unitats de xarxa), processos d’impressió i escaneig, eines locals, extractes per BI, relés de correu electrònic, maquinari especial, sortides de Shadow-IT i solucions manuals. En un Big Bang, tots aquests camins han de funcionar el mateix cap de setmana —incloent permisos, dades mestres, historials i casos especials.

L’enfocament pas a pas redueix el risc, però no el relega automàticament cap avall. Fa els riscos més visibles i manejables, però exigeix decisions netes d’arquitectura i d’operació: on es fa el ruteig? Qui és el responsable de les dades? Quina consistència és exigible des del punt de vista funcional i on és acceptable un retard temporal? I com evitar que el funcionament en paral·lel es converteixi en una obra permanent?

Strangler Pattern en la realitat empresarial: no «Microservices», sinó interfícies clares

El Strangler Pattern significa: es construeixen noves funcionalitats al costat del sistema antic i es redirigeix el trànsit pas a pas fins que la part antiga queda obsoleta. Important: això no és una guerra religiosa d’arquitectura («Monolith vs. Microservices»), sinó un patró de migració. Funciona també quan l’arquitectura objectiu continua sent un monòlit —només que més moderna, més mantenible i més fàcil d’integrar.

La decisió més important: segmentar segons processos, no segons taules

En moltes substitucions es segmenta guiats per les dades («Comencem amb les taules de clients i comandes»). Això sovint comporta un funcionament en paral·lel dolorós perquè els processos travessen aquestes dades. És millor un tall orientat a processos, p. ex. «Creació d’ofertes», «Recepció de mercaderies», «Gestió de reclamacions» o «Ticket de servei fins a factura».

Regla pràctica: Una etapa Strangler hauria de cobrir un flux funcional tancat que es pugui operar i monitoritzar de principi a fi en el nou sistema. Això inclou entrades (UI, API, importació), processament (regles de negoci) i sortides (impressió, exportació, comptabilització, notificació).

Strangler necessita un «derivador»: Gateway, proxy o capa de ruteig

Per tal que els usuaris i els sistemes connectats no hagin d’aprendre cada vegada nous punts finals, sovint s’implanta una capa de ruteig. Depenent de la situació pot ser: un reverse proxy davant d’aplicacions web, un API-Gateway per punts finals de servei o una capa d’integració que aglutini interfícies de fitxers i esdeveniments. El que importa és la capacitat d’operació: configuració centralitzada, logs clars, monitoratge i un rollback controlat.

Per als administradors és important que aquesta capa no es converteixi en una caixa negra. Necessiten rutes traçables (quina petició va anar on), correlació a través dels logs (p. ex. Request-ID) i timeouts/regrles de reintent definits, perquè els errors no quedin „enganxats“.

El funcionament paral·lel és un estat operatiu – no un «truc de projecte»

Funcionament paral·lel vol dir: components antics i nous treballen simultàniament en producció durant un període. Això és normal, però costós, sobretot en operació. Teniu més elements mòbils, més monitoratge, més potencial d’incidents i responsabilitats més complexes. Per això cal planificar el funcionament paral·lel com un mode operatiu temporalment limitat, incloent criteris d’aturada.

Models típics de funcionament paral·lel (i quan s’ajusten)

• Canvi segons grups d’usuaris (grup pilot → ones): adequat quan els rols d’usuari són clarament separables i els processos no travessen grups.
• Canvi per clients/ubicacions: bo en estructures de sucursals/fàbriques, quan els fluxos de dades entre ubicacions són limitats.
• Canvi per passos de procés: p. ex. «captura nova, facturació encara antiga» — arriscat si hi ha moltes retroalimentacions, però a vegades sense alternativa.
• Canvi segons tipus d’objecte: p. ex. actius nous en el nou sistema, registres antics en l’antic — pot funcionar si existeixen regles clares per a l’històric i l’informe.

Des del punt de vista d’operació heu de dissenyar el funcionament paral·lel perquè les dominis d’errors siguin petits: un defecte en la nova component no ha de arrossegar el sistema legacy (p. ex. per interfícies bloquejants o bloquejos de base de dades), i a l’inrevés el legacy no ha d’esabotar tots els processos nous amb exportacions inestables.

Feature Flags i regles de ruteig: control en comptes de «despleguem i esperem»

Les Feature Flags són interruptors amb els quals activeu/desactiveu funcionalitats de manera dirigida —sense desplegament nou. Per a la direcció IT i els responsables de projecte no és el detall tècnic el decisori, sinó la governança: qui pot canviar l’estat? Com es documenta per què es va fer el canvi? Amb quina rapidesa es pot revertir? Quines dependències es generen (p. ex. si ja s’han generat dades en el nou format)?

Una pràctica raonable és un petit registre de canvis (Change-Protokoll, Decision Log) per a cada acció de commutació: moment, responsable, grup d’usuaris afectat, efecte esperat, indicadors de monitoratge, condició de rollback. Això evita el clàssic «ningú no sap ja per què està rutejat d’aquesta manera».

Consistència de dades en el desplegament: el nucli del qual depenen moltes migracions

La consistència de dades significa que les dades són correctes des del punt de vista funcional, completes i disponibles en l’ordre esperat. En funcionament en paral·lel això es complica, perquè dos sistemes poden escriure simultàniament o, com a mínim, ambdós reclamar ser la «veritat». D’aquí depèn que la substitució del sistema legacy sigui estable o que passeu mesos realitzant conciliacions de deltes.

Primer cal aclarir: quin és el «System of Record» per a cada àmbit de dades?

Per a cada àmbit de dades (p. ex. deutors, articles, preus, comandes, moviments d’emmagatzematge, documents) cal determinar quin sistema és líder. Això no és només una qüestió d’arquitectura, sinó operativa:

• On es corregeixen els errors en cas de suport?
• On resideix el procés d’aprovació (quatre ulls, SoD/separació de funcions)?
• Quines traces d’auditoria es requereixen (qui va canviar què i quan)?
• Com s’eviten retralls i treballs addicionals durant el tancament mensual?

En les primeres etapes de la tàctica Strangler sovint té sentit deixar que el sistema legacy sigui provisionalment el responsable de les dades i que el nou component només consumeixi. Més endavant invertireu la responsabilitat. Aquest canvi de lideratge és un hit independenent i requereix una finestra de cutover clara així com un pla de comunicació i d’acceptació.

Patrons de sincronització: Dual Write, CDC i Events — amb expectatives realistes

Hi ha diverses maneres de sincronitzar dades entre l’antic i el nou sistema. Cap no és «gratuita».

• Dual Write: una acció escriu en ambdós sistemes (p. ex. crear comanda → legacy i nou sistema). Avantatge: disponibilitat ràpida. Inconvenient: el cas d’error és complex (què passa si el sistema A escriu i el sistema B no?) i sovint genera dependències i riscos de rendiment.
• Change Data Capture (CDC): els canvis s’extreuen del log de la base de dades o mitjançant triggers/replicació com a deltes. Avantatge: desacobla l’aplicació i la sincronització. Inconvenient: es repliquen també canvis «tècnics» i cal reconstruir els esdeveniments de domini; a més, els canvis d’esquema en el legacy es converteixen de sobte en un risc d’integració.
• Integració basada en esdeveniments: el sistema publica esdeveniments de domini (p. ex. «comanda aprovada») que altres sistemes consumeixen. Avantatge: semàntica de negoci clara. Inconvenient: requereix definicions d’esdeveniments netes, idempotència (reprocessar sense causar dany) i un concepte d’operació de missatgeria resistent.

Per als decisors és fonamental: la consistència de dades no és binària. Alguns processos necessiten consistència forta (correcte immediatament, p. ex. aprovacions de pagament), altres toleren la consistència eventual (petit retard, p. ex. índexs de cerca, reporting, notificacions). Aquesta classificació s’ha d’acordar aviat amb l’àrea funcional i amb la revisió/auditoria.

Conflictes i duplicats: planifiqueu explícitament el «camí més problemàtic»

En el funcionament en paral·lel, els conflictes solen sorgir així: dos sistemes modifiquen el mateix objecte, però amb regles diferents. O bé una importació s’executa doblement perquè un reintents va arribar «massa aviat». O un usuari corregeix dades en el Legacy mentre la nova interfície ja s’ha posat en marxa.

Necessiteu regles vinculants per a això:

• Resolució de conflictes: «Last write wins» rarament és correcte des del punt de vista funcional. Millor són prioritats (guanya el sistema principal) o regles de fusió funcionals (p. ex. dades mestres de contacte vs. condicions).
• Idempotència: Cada integració hauria de tolerar processaments múltiples sense duplicats (p. ex., mateix número de document, mateixa referència externa).
• Dead-Letter/Quarantäne: Les deltes no processables han d’estar localitzables, amb una responsabilitat clara i mecanismes de reexecució.

Sense aquestes regles, la consistència de les dades deriva cap a la «conciliació a Excel» i treball manual — amb la frustració corresponent i costos derivats difícils de mesurar.

Disseny del rollout: ones, acceptacions i reversions, sense sobrecarregar l’explotació

Un bon rollout és més que «Deployment + formació». En el funcionament en paral·lel cal entrellaçar rollout i explotació: qui fa el primer nivell en cas d’errors? Quins logs estan disponibles de forma immediata? Com s’escalen les incidències? Quins processos no es poden canviar durant una ona (p. ex., tancament mensual, inventari, canvi de preus)?

Planificació d’ones amb criteris estrictes

Ha demostrat ser eficient una planificació d’ones amb criteris d’entrada clars, no només dates. Exemples de criteris estrictes:

• Els dashboards de monitoratge i l’alerting per al nou component estan actius i provats (inclosa la reducció del «soroll d’alarma»).
• Existeixen runbooks per a incidents típics (timeouts, acumulació a les cues, imports defectuosos, errors d’autorització).
• La reconciliació de deltes està automatitzada i genera informes entenedors (diferències per tipus d’objecte, finestra temporal, classe de causa).
• El mecanisme de rollback està assajat (com a mínim provat de manera realista en Staging/Pre-Prod).

Justament aquest últim punt s’infravalora: rollback no és «simplement tornar enrere». Si el nou sistema ja ha generat dades, cal saber com aquestes dades seran visibles en el Legacy o com migrar/neutralitzar correctament les dades generades.

Cutover — mini-cutovers en lloc d’un Big Bang

Fins i tot amb l’Strangler Pattern hi ha cutovers — simplement més petits. Tipus són els mini-cutovers en el canvi d’un pas de procés o en l’ajust de la governança de dades. Cada mini-cutover necessita:

• Congelació de dades (breu, però vinculant): qui pot modificar què durant aquest període?
• Reconciliació: Què s’ha modificat des de l’última sincronització?
• Commutació: enrutament/feature flags, tasques programades, horaris, permisos.
• Verificació: proves funcionals bàsiques (p. ex., crear comanda → albarà → factura), més comprovacions tècniques (cues, percentatge d’errors, càrrega de la base de dades).

Per a la direcció d’IT és important que aquests passos estiguin documentats com a procés repetible i que tinguin cobertura de personal. Si no, l’èxit del projecte depèn d’individus que «saben com es fa».

Estabilitzar primer les interfícies: el fonament infravalorat del reemplaçament del Legacy

Molts sistemes Legacy es comuniquen mitjançant interfícies fruit de l’evolució: exportacions CSV a carpetes, processos nocturns, accés directe a la base de dades per eines de tercers, fluxos de treball basats en correu electrònic. Un reemplaçament gradual és molt més senzill si primer inventarieu el panorama d’interfícies i el consolideu en pocs punts.

Pràcticament això vol dir: identifiqueu punts d’integració crítics per al sistema (p. ex. Finanzbuchhaltung, Versand, Produktionsrückmeldungen, Identitäten/Berechtigungen) i establiu-hi contractes clars. „Contracte“ no fa referència al jurídic, sinó a l’estabilitat tècnica: versionament, camps inequívocs, IDs estables, maneig d’errors documentat, SLAs definits per al lliurament de dades.

Si establiu per això un model intern de governança d’API/integracions (Owner, Deprecation-Regeln, Test-/Staging-Pfade), minvarà el risc que un canvi en el legacy deixi sobtadament la vostra nova component inoperativa. Un punt temàtic adequat per a enllaç intern seria, per exemple, un article sobre API-Governance i estratègies de Deprecation.

Seguretat, permisos i auditoria: l’operativa en paral·lel agreuja la qüestió

En l’operativa en paral·lel sovint existeixen models d’usuaris i rols duplicats. Això condueix a permisos en l’ombra: un usuari pot estar correctament restringit al sistema nou, però encara tenir permisos extensos al legacy — i acabar fent servir la via „més fàcil“. A més s’hi afegeixen comptes tècnics (Service Accounts) per a sincronització, imports, cues i processos per lots.

Punts concrets que s’haurien d’aclarir aviat:

• Identity-Quelle: D’on provenen els usuaris i els grups? AD/Entra ID? Un IAM propi? És important que el provisionament sigui rastrejable.
• Rollenmapping: Si els rols no encaixen 1:1, calen rols de transició que siguin temporals i que es recertifiquin.
• Service Accounts: Privilegis mínims, rotació de secrets, registració clara. Especialment els comptes de sincronització poden esdevenir una porta d’entrada i són difícils d’auditar si no es gestionen bé.
• Audit-Trails: Quan la responsabilitat sobre les dades canvia, ha d’estar clar on es troba l’evidència dels canvis i com es manté consultable a través dels dos sistemes.

Important per a decisors: la seguretat aquí no és un „scope“ addicional, sinó que condiciona la factibilitat del rollout. Apostar per ajustar permisos en paral·lel més endavant sol ser més car que definir aviat un tall pragmàtic de rols i comptes de servei.

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

En l’operativa en paral·lel els patrons d’error són sovint indirectes: un delta es queda encallat, un retry s’executa indefinidament, una cua s’embossa, o un job crític en temps xoca amb un bloqueig a la base de dades. Si ho detecteu només a través d’entrades d’usuari (tickets), ja és massa tard. Per això necessiteu des del primer dia un mínim d’observabilitat: Monitoring (estat), Logging (esdeveniments) i —allà on sigui pertinent— Tracing (cadena entre sistemes).

Senŀals pràctics i operables podrien ser, per exemple:

• Backlog de sincronització (quantes modificacions „esperen“), i l’antiguitat de l’entrada més antiga.
• Taxa d’errors per interfície i per classe d’error (validació, timeout, autenticació, conflicte de dades).

Per al traspàs d’operacions importa menys quina eina s’utilitzi i més que les responsabilitats i els runbooks estiguin clars. Si disposeu d’On-Call o servei de guàrdia, l’operació ha de ser capaç d’actuar davant d’incidències típiques sense haver de recórrer a feina detectivesca dels desenvolupadors.

Quan el Strangler Pattern no s’adiu (o només amb restriccions clares)

Hi ha situacions en què la substitució gradual només funciona de manera limitada:

• Acoblament transaccional extremadament estret: Si pràcticament cada operació travessa tots els mòduls i requereix consistència rígida, l’operació en paral·lel esdevé ràpidament incontrolable.
• Accés directe a la BD per sistemes de tercers: Si diverses eines llegeixen/escriuen directament a les taules legacy, cal aturar o controlar primer aquesta proliferació.
• Indefinició de la propietat de les dades: Si no es pot determinar qui té la responsabilitat de liderar les dades, els conflictes són garantits — i la substitució esdevé política en lloc de ser tècnica.
• Manca de disciplina operativa: Sense entorns nets, desplegaments reproduïbles i monitoratge, cada pas intermig es converteix en un risc.

Això no vol dir que estigueu obligats a un Big Bang. Però cal que canvieu l’ordre: primer estabilitzar punts d’integració, centralitzar els accessos a dades, aclarir rols i la propietat de les dades — i només després aplicar el Strangler Pattern.

Un pla d’execució pràctic per a la substitució del legacy per etapes

Com a orientació per a responsables de projecte, ha demostrat ser útil un procediment en etapes clares. La forma exacta depèn del sistema i del sector, però la lògica és sòlida:

1. Inventari & dependències: interfícies, jobs, fluxos de dades, grups d’usuaris, finestres temporals crítiques (tancament, inventari).
2. Definir les vores d’interfície: mòduls de procés, lideratge de dades per àrea, contractes d’integració.
3. Construir enroutament & commutadors: Gateway/Proxy, Feature Flags, registre centralitzat.
4. Establir el camí de dades: CDC/Event/Dual Write, regles de conflicte, quarantena, informes de conciliació.
5. Pilot amb càrrega real: no només demo, sinó amb casos reals, incloses les excepcions.
6. Rollout en ondes: criteris d’entrada, Cutover-Checklisten, exercicis de rollback.
7. Apagar & netejar: desactivar rutes antigues, eliminar jobs, revocar permisos, actualitzar la documentació.

L’últim punt és essencial: moltes organitzacions mantenen components legacy „per seguretat“. Resultat: costos dobles, risc confús, ningú s’atreveix a apagar-los. Planifiqueu el decommissioning com a subprojecte amb termini, responsables i proves (p. ex. „cap accés des de fa X setmanes“, „tots els exports reconfigurats“, „requisits d’auditoria complerts“).

Conclusió: Substituir pas a pas significa tractar la consistència i l’operació com un producte

Una substitució del legacy pas a pas no és automàticament més senzilla — però en moltes empreses és l’única opció realista. El Strangler Pattern funciona si per cada etapa definiu vores de procés clares, planifiqueu l’operació en paral·lel com un estat operatiu real i no deixeu la consistència de dades a l’atzar. Decisives són les decisions primerenques sobre la responsabilitat de les dades, patrons de sincronització robusts amb regles de conflicte, així com un disseny de rollout amb onades, aprovacions i procediments de rollback practicats.

Si planifiqueu una substitució i voleu tractar de manera estructurada les interfícies, l’operació en paral·lel o el concepte de consistència de dades, ens podeu contactar a través de .

Discutir un projecte o una iniciativa de modernització amb Net-Base.