Legacy-vervanging stap voor stap: Strangler Pattern, parallelle werking en gegevensconsistentie bij rollout

Een legacyvervanging faalt zelden aan het „bouwen“ van de nieuwe oplossing, maar aan de overgang: data moeten correct blijven, interfaces mogen niet breken, en de exploitatie moet tijdens de omschakeling doorgaan. In veel organisaties is een Big-Bang-cutover daarom geen optie – afhankelijkheden zijn te groot, de uitvalkosten te hoog, en terugdraaien te complex.

In de praktijk blijkt een stapsgewijze aanpak effectief met het Strangler Pattern (functionele delen worden na en na „overgezet“), parallelle exploitatie (oud en nieuw systeem draaien tijdelijk naast elkaar) en duidelijke regels voor dataconsistentie. Dit artikel laat zien hoe u deze bouwstenen zo combineert dat ze in het dagelijks werk van IT-leiding, administratie en projectverantwoordelijken houdbaar zijn – inclusief typische foutbeelden, operationele gevolgen en beslismomenten tijdens de rollout.

Waarom de stapsgewijze aanpak vaak de realistische legacyvervanging is

Legacy-systemen zijn zelden „slechts één applicatie“. Meestal zitten eraan gekoppeld: batchruns, bestandsinterfaces (SFTP-mappen, netwerkschijven), print- en scanprocessen, lokale tools, BI-extracten, e-mail-relays, speciale hardware, shadow-IT-omleidingen en handmatige workarounds. Bij een Big Bang moeten al deze paden hetzelfde weekend functioneren – en dat inclusief permissies, stamgegevens, historieken en uitzonderingsgevallen.

De stapsgewijze aanpak vermindert het risico, maar verschuift het niet automatisch naar „beneden“. Het maakt risico’s zichtbaarder en beheersbaar, verlangt daarvoor echter zuivere architectuur- en exploitatiebeslissingen: Waar wordt gerouteerd? Wie is gegevensverantwoordelijke? Welke consistentie is vakinhoudelijk verplicht, waar volstaat een tijdsvertraging? En hoe voorkomt u dat parallelle exploitatie een permanente bouwplaats wordt?

Strangler Pattern in de bedrijfsrealiteit: niet „Microservices“, maar duidelijke grensvlakken

Het Strangler Pattern betekent: u bouwt nieuwe functies naast het legacy-systeem en leidt het verkeer stapsgewijs om, totdat het oude deel overbodig is. Belangrijk: dit is geen architectuur-religieoorlog („Monolith vs. Microservices“), maar een migratiepatroon. Het werkt ook als de doelarchitectuur een monolith blijft – alleen moderner, onderhoudbaarder en beter te integreren.

De belangrijkste beslissing: snijd naar processen, niet naar tabellen

In veel vervangingsprojecten wordt er te datagedreven gesneden („We nemen eerst de Tabellen für Kunden und Aufträge“). Dat leidt vaak tot pijnlijke parallelle exploitatie, omdat processen dwars door deze data heen lopen. Beter is een procesgerichte snede, bijvoorbeeld „offerteopmaak“, „goederenontvangst“, „afhandeling van klachten“ of „service-ticket tot factuur“.

Praktijkregel: Een Strangler-etappe moet een vakmatig samenhangende workflow omvatten die in het nieuwe systeem end-to-end kan worden uitgevoerd en gemonitord. Daartoe horen ingangen (UI, API, Import), verwerking (businessregels) en uitgangen (afdruk, export, boeking, melding).

Strangler heeft een ‚omleider‘ nodig: Gateway, Proxy of routeringslaag

Zodat gebruikers en aangesloten systemen niet steeds nieuwe endpoints hoeven te leren, wordt vaak een routeringslaag ingezet. Afhankelijk van de uitgangssituatie kan dat zijn: een reverse proxy voor webapplicaties, een API-Gateway voor service-endpoints of een integratielaag die bestandsinterfaces en events bundelt. Cruciaal is de operationele geschiktheid: centrale configuratie, heldere logs, monitoring en een gecontroleerde rollback.

Voor beheerders is het belangrijk dat deze laag geen blackbox wordt. Ze hebben inzichtelijke routings nodig (welke request ging waarheen), correlatie via logs (bijv. Request-ID) en gedefinieerde Timeouts/Retry-Regeln, zodat fouten niet ‚vastplakken‘ worden.

Parallelle bedrijfsvoering is een bedrijfsmodus – geen ‚projecttruc‘

Parallelle bedrijfsvoering betekent: oude en nieuwe componenten werken voor een periode tegelijkertijd productief. Dat is normaal, maar duur – vooral in de operatie. U krijgt meer moving parts, meer monitoring, meer incidentpotentieel en complexere verantwoordelijkheden. Daarom moet parallelle bedrijfsvoering als tijdelijk begrensde bedrijfsmodus worden gepland, inclusief stopcriteria.

Typische modellen voor parallelle bedrijfsvoering (en wanneer ze passen)

• Umschakelen op gebruikersgroepen (pilotgroep → golven): geschikt wanneer gebruikersrollen duidelijk te scheiden zijn en processen niet dwars door groepen lopen.
• Umschakelen per mandant/vestiging: goed bij filiaal-/fabrieksstructuren, wanneer datastromen tussen locaties beperkt zijn.
• Umschakelen per processtap: bijv. ‚invoer nieuw, afrekening nog oud‘ – riskant als er veel terugkoppelingen zijn, maar soms onvermijdelijk.
• Umschakelen per objecttype: bijv. nieuwe vaste activa in het nieuwe systeem, oude voorraad in het oude – kan werken als er duidelijke regels voor historie/rapportage bestaan.

Vanuit operationeel perspectief moet u parallelle bedrijfsvoering zo ontwerpen dat de foutdomeinen klein blijven: een defect in de nieuwe component mag het legacy-systeem niet meesleuren (bijv. door blokkering van interfaces of databaselocks), en omgekeerd mag legacy niet alle nieuwe processen saboteren door instabiele exports.

Feature Flags en routeringsregels: controle in plaats van ‚we rollen uit en hopen‘

Feature Flags zijn schakelaars waarmee u functies gericht kunt activeren/deactiveren – zonder nieuwe deployment. Voor IT-Leitung en projectverantwoordelijken is niet het technische detail doorslaggevend, maar de Governance: wie mag schakelen? Hoe wordt vastgelegd waarom er geschakeld is? Hoe snel kunt u terug? Welke afhankelijkheden ontstaan (bijv. als data al in het nieuwe formaat zijn aangemaakt)?

Een zinvolle praktijk is een klein change-protocol (Decision Log) per schakelactie: tijdstip, Owner, getroffen gebruikersgroep, verwacht effect, monitoringindicatoren, rollback-voorwaarde. Dat voorkomt het klassieke ’niemand weet nog waarom het zo gerouteerd is‘.

Dataconsistentie bij Rollout: de kern waaraan veel migraties vastlopen

Gegevensconsistentie betekent dat gegevens inhoudelijk correct, compleet en in de verwachte volgorde beschikbaar zijn. In parallelbedrijf wordt dat lastig, omdat twee systemen gelijktijdig schrijven of in elk geval allebei de „waarheid“ opeisen. Hier beslist zich of de vervanging van het legacy-systeem stabiel werkt of dat u maandenlang delta-afstemmingen moet uitvoeren.

Eerst helder hebben: wie is per gegevensdomein het „System of Record“?

U heeft per gegevensdomein (bijv. debiteuren, artikelen, prijzen, orders, voorraadmutaties, documenten) een vaststelling nodig welk systeem leidend is. Dat is geen puur architectuurvraagstuk, maar operationeel:

• Waar worden correcties in het geval van support uitgevoerd?
• Waar is het goedkeuringsproces belegd (vier ogen, SoD/scheiding van functies)?
• Welke auditsporen zijn vereist (wie heeft wanneer wat gewijzigd)?
• Hoe worden nabewerkingen bij de maandafsluiting voorkomen?

In vroege Strangler-fasen is het vaak zinnig het legacy-systeem aanvankelijk leidend te laten en de nieuwe component „alleen“ te laten consumeren. Later draait u de leiding om. Deze omkering van de leiding is een eigen mijlpaal en vereist een duidelijk cutover-venster evenals een communicatie- en acceptatieplan.

Synchronisatiepatronen: Dual Write, CDC en Events – met realistische verwachtingen

Er zijn meerdere manieren om gegevens tussen oud en nieuw te synchroniseren. Geen enkele is „gratis“.

• Dual Write: Een actie schrijft in beide systemen (bijv. order aanmaken → legacy en nieuw systeem). Voordeel: snelle beschikbaarheid. Nadeel: foutafhandeling is complex (wat als systeem A schrijft en systeem B niet?), bovendien ontstaan afhankelijkheden en vaak prestatierisico’s.
• Change Data Capture (CDC): Wijzigingen worden uit het databaselog of via triggers/replicatie als delta geëxtraheerd. Voordeel: ontkoppelt applicatie en synchronisatie. Nadeel: u replikeert ook „technische“ wijzigingen en moet vakinhoudelijke gebeurtenissen reconstrueren; bovendien worden schemawijzigingen in het legacy-systeem plotseling een integratierisico.
• Event-gebaseerde integratie: Het systeem publiceert vakinhoudelijke gebeurtenissen (bijv. „order vrijgegeven“), die andere systemen consumeren. Voordeel: duidelijke vakinhoudelijke semantiek. Nadeel: vereist scherpe gebeurtenisdefinities, idempotentie (meerdere verwerkingen zonder schade) en een robuust operationeel messaging-concept.

Voor beslissers is cruciaal: gegevensconsistentie is niet binair. Sommige processen vereisen sterke consistentie (direct correct, bijv. betalingsgoedkeuringen), andere tolereren eventual consistency (korte vertraging, bijv. zoekindex, rapportage, notificaties). Deze indeling moet vroeg met de vakafdeling en revisie/audit worden afgestemd.

Conflicten en duplicaten: Plan expliciet het „lelijke pad“

In de parallelle operatie ontstaan conflicten typisch zo: twee systemen wijzigen hetzelfde object, maar volgens verschillende regels. Of een import draait dubbel omdat een retry „te vroeg“ kwam. Of een gebruiker corrigeert gegevens in het legacy-systeem, terwijl de nieuwe interface al was omgezet.

Daarvoor heeft u bindende regels nodig:

• Conflictoplossing: „Last write wins“ is zelden vakinhoudelijk correct. Beter zijn prioriteiten (leidend systeem wint) of vakinhoudelijke merge-regels (bijv. contactstamgegevens vs. condities).
• Idempotentie: Elke integratie moet meervoudige verwerking zonder duplicaten verdragen (bijv. hetzelfde documentnummer, dezelfde externe referentie).
• Dead-Letter/Quarantäne: Onverwerkbare deltas moeten vindbaar zijn, met duidelijke verantwoordelijkheid en mogelijkheid tot herstart.

Zonder deze regels vervalt de dataconsistentie in een „Excel-afstemming“ en handmatige nabehandeling – met bijbehorende frustratie en moeilijk meetbare vervolgkosten.

Rollout-ontwerp: golven, acceptaties en terugval, zonder de bedrijfsvoering te overbelasten

Een goede rollout is meer dan „Deployment + Schulung“. In de parallelle operatie moet u rollout en operatie verweven: wie doet first-level bij fouten? Welke logs zijn direct beschikbaar? Hoe wordt er geëscaleerd? Welke processen mogen in een golf niet worden omgezet (bijv. maandafsluiting, inventaris, prijsaanpassing)?

Planning in golven met harde criteria

Een golvenplanning met duidelijke toetredingscriteria heeft zich bewezen, niet alleen kalenderdata. Voorbeelden van harde criteria:

• Monitoring-dashboards en alerting voor de nieuwe component zijn live en getest (inclusief vermindering van „alarm-ruis“).
• Runbooks voor typische incidenten bestaan (timeouts, wachtrijopstopping, foutieve imports, machtigingsfouten).
• Delta-afstemming is geautomatiseerd en levert begrijpelijke rapporten (verschillen per objecttype, tijdvenster, oorzakencategorie).
• Rollback-mechanisme is geoefend (minimaal realistisch doorlopen in Staging/Pre-Prod).

Juist het laatste punt wordt onderschat: rollback is niet „we schakelen weer terug“. Als het nieuwe systeem al data heeft aangemaakt, moet u weten hoe die data in het legacy-systeem zichtbaar worden of hoe u de aangemaakte data correct migreert/neutraliseert.

Cutover — mini-cutovers in plaats van Big Bang

Ook bij het Strangler Pattern zijn er cutovers — maar dan kleiner. Typisch zijn mini-cutovers bij de wijziging van een processtap of bij het overschakelen van de data-eigendom. Elke mini-cutover heeft nodig:

• Datafreeze (kort, maar bindend): wie mag tijdens die periode wat wijzigen?
• Afstemming: wat is er sinds de laatste sync gewijzigd?
• Overschakelen: routing/feature flags, jobs, planningen, machtigingen.
• Verificatie: inhoudelijke smoke-tests (bijv. order aanmaken → pakbon → factuur), plus technische checks (wachtrijen, foutpercentages, DB-load).

Voor IT-leiding is het belangrijk dat deze stappen als herhaalbaar proces zijn gedocumenteerd en personeelsmatig zijn afgedekt. Anders hangt het projectsucces af van individuele personen die „weten hoe het moet”.

Interfaces eerst stabiliseren: het onderschatte fundament van de legacy-uitfasering

Veel legacy-systemen communiceren via gegroeide interfaces: CSV-exports naar mappen, nachtelijke jobs, directe databasetoegang door tools van derden, e-mailgebaseerde workflows. Een stapsgewijze uitfasering wordt aanzienlijk eenvoudiger als u het interface-landschap eerst inventariseert en op enkele punten consolideert.

Praktisch heißt das: Identifizieren Sie systemkritische Integrationspunkte (z. B. Finanzbuchhaltung, Versand, Produktionsrückmeldungen, Identitäten/Berechtigungen) und bauen Sie dort klare Verträge auf. „Vertrag“ meint hier nicht Juristisches, sondern technische Stabilität: Versionierung, eindeutige Felder, stabile IDs, dokumentierte Fehlerbehandlung, definierte SLAs für Datenlieferung.

Wenn Sie dazu ein internes API-/Integrations-Governance-Modell etablieren (Owner, Deprecation-Regeln, Test-/Staging-Pfade), sinkt das Risiko, dass eine Legacy-Änderung plötzlich Ihre neue Komponente lahmlegt. Ein passender thematischer Anknüpfungspunkt für interne Verlinkung wäre z. B. ein Beitrag zur API-Governance und zu Deprecation-Strategien.

Beveiliging, machtigingen en audit: parallelbedrijf verscherpt het onderwerp

Im Parallelbetrieb existieren oft doppelte Benutzer- und Rollenmodelle. Das führt zu Schattenrechten: Ein Benutzer ist im neuen System korrekt eingeschränkt, hat aber im Legacy noch weitreichende Rechte – und nutzt am Ende den „einfacheren Weg“. Dazu kommen technische Konten (Service Accounts) für Synchronisation, Importe, Queues und Batchjobs.

Konkrete Punkte, die Sie früh klären sollten:

• Identity-Quelle: Woher kommen Benutzer und Gruppen? AD/Entra ID? Ein eigenes IAM? Wichtig ist, dass die Provisionierung nachvollziehbar ist.
• Rollenmapping: Wenn Rollen nicht 1:1 passen, braucht es Übergangsrollen, die zeitlich befristet sind und rezertifiziert werden.
• Service Accounts: Minimale Rechte, Secrets-Rotation, saubere Protokollierung. Gerade Synchronisationskonten sind sonst ein Einfallstor und schwer zu auditieren.
• Audit-Trails: Wenn Datenführerschaft wechselt, muss klar sein, wo der Nachweis über Änderungen liegt und wie er über beide Systeme hinweg recherchierbar bleibt.

Wichtig für Entscheider: Security ist hier nicht „zusätzlicher Scope“, sondern beeinflusst die Machbarkeit des Rollouts. Ein späteres Nachziehen von Berechtigungen im Parallelbetrieb ist meist teurer als ein früher, pragmatischer Rollen- und Servicekonto-Schnitt.

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

Im Parallelbetrieb sind Fehlerbilder oft indirekt: Ein Delta hängt, ein Retry läuft endlos, eine Queue staut sich, oder ein zeitkritischer Job kollidiert mit einem Datenbanklock. Wenn Sie das nur über Benutzer-Tickets sehen, sind Sie zu spät. Sie brauchen deshalb von Anfang an ein Observability-Minimum: Monitoring (Zustand), Logging (Ereignisse) und – wo sinnvoll – Tracing (Kette über Systeme).

Praktische, gut betreibbare Signale sind beispielsweise:

• Synchronisations-Backlog (wie viele Änderungen „warten“), plus Alter des ältesten Eintrags.
• Fehlerquoten pro Schnittstelle und Fehlerklasse (Validierung, Timeout, Auth, Datenkonflikt).
• Latentie per processtap (bijv. Auftrag freigegeben bis Versandauftrag erstellt).
• Indicatoren voor datakwaliteit (duplicaatpercentage, ontbrekende verplichte velden, onverwachte null-waarden).

Voor de overdracht naar de exploitatie telt minder welk tool gebruikt wordt, maar of verantwoordelijkheden en Runbooks duidelijk zijn. Als u On-Call of een bereikbaarheidsdienst heeft, moet de exploitatie bij typische storingen zonder ontwikkelaars-detectivewerk direct handelingsbekwaam blijven.

Wanneer het Strangler Pattern niet past (of alleen met duidelijke beperkingen)

Er zijn situaties waarin gefaseerde vervanging slechts beperkt werkt:

• Extreem nauwe transactie-koppeling: Als vrijwel elke transactie dwars door alle modules loopt en harde consistentie vereist, wordt parallelle operatie snel onhoudbaar.
• Directe DB-toegangen door derde systemen: Als meerdere tools rechtstreeks naar Legacy-tabellen schrijven/lezen, moet deze wildgroei eerst worden beëindigd of gecontroleerd.
• Onduidelijk eigenaarschap van gegevens: Als niet kan worden vastgesteld wie de gegevens beheert, zijn conflicten gegarandeerd – en wordt de vervanging politiek in plaats van technisch.
• Ontbrekende bedrijfsdiscipline: Zonder schone omgevingen, reproduceerbare Deployments en monitoring wordt elke tussenstap een risico.

Dat betekent niet dat u tot een Big Bang gedwongen bent. Maar u moet dan de volgorde wijzigen: eerst integratiepunten stabiliseren, datatoegangen centraliseren, rollen en ownership vastleggen – en pas daarna het Strangler Pattern toepassen.

Een praktijkgericht stappenplan voor gefaseerde legacyvervanging

Als richtlijn voor projectverantwoordelijken heeft een verloop in duidelijke fasen zich bewezen. De precieze uitwerking hangt af van het systeem en de sector, maar de logica is robuust:

1. Inventaris & afhankelijkheden: interfaces, Jobs, datastromen, gebruikersgroepen, kritieke tijdsvakken (afsluiting, inventarisatie).
2. Koppelvlakken definiëren: procesmodules, gegevens-eigenaarschap per domein, integratieafspraken.
3. Routing & schakelaars bouwen: Gateway/Proxy, Feature Flags, centrale Protokollierung.
4. Datapad vastleggen: CDC/Event/Dual Write, conflictregels, quarantaine, afstemmingsrapporten.
5. Pilot onder echte belasting: niet alleen demo, maar met echte gevallen, inclusief uitzonderingen.
6. Gefaseerde rollout: ingangscriteria, Cutover-Checklisten, Rollback-Übungen.
7. Uitschakelen & opruimen: oude paden deactiveren, Jobs verwijderen, rechten intrekken, documentatie bijwerken.

Het laatste punt is essentieel: veel organisaties laten legacy-componenten „zur Sicherheit“ doorlopen. Resultaat: dubbele kosten, onduidelijk risico, niemand durft het uitschakelen aan. Plan het Decommissioning als deelproject met termijn, verantwoordelijken en bewijzen (z. B. „keine Zugriffe seit X Wochen“, „alle Exporte umgestellt“, „Audit-Anforderungen erfüllt“).

Conclusie: Gefaseerd vervangen betekent consistentie en exploitatie als product behandelen

Een gefaseerde legacyvervanging is niet per definitie eenvoudiger – maar in veel bedrijven de enige realistische optie. Het Strangler Pattern werkt wanneer u per fase duidelijke procetskoppelvlakken definieert, de parallelle operatie als een echte bedrijfsmodus plant en dataconsistentie niet aan het toeval overlaat. Doorslaggevend zijn vroege vastleggingen van gegevens-eigenaarschap, robuuste synchronisatiemodellen met conflictregels en een rollout-ontwerp met golven, acceptaties en geoefende fallback.

Als u een vervanging plant en de koppelvlakken, de parallelle bedrijfsvoering of het concept voor gegevensconsistentie eens gestructureerd wilt doornemen, kunt u ons bereiken via .

Project of moderniseringstraject met Net-Base bespreken.