Legacy-afvikling trin for trin: Strangler-mønster, parallelkørsel og datakonsistens ved udrulning

En Legacy-udskiftning mislykkes sjældent på grund af det at „bygge“ den nye løsning, men på overgangsfasen: data skal forblive korrekte, grænseflader må ikke briste, og driften skal fortsætte under omlægningen. I mange virksomheder er et Big-Bang-Cutover derfor ikke en mulighed – afhængighederne er for store, nedetidsomkostningerne for høje, og tilbagerulningen for vanskelig.

I praksis viser et trinvis forløb sig at være effektivt med Strangler Pattern (funktionelle dele flyttes gradvist), Parallelbetrieb (gammelt og nyt system kører midlertidigt parallelt) og klare regler for Datakonsistenz. Denne artikel viser, hvordan du kombinerer disse byggesten, så de er bæredygtige i den daglige drift for IT-ledelse, administration og projektansvar – inklusive typiske fejlscenarier, driftskonsekvenser og beslutningspunkter i rollout.

Warum der Schritt-für-Schritt-Ansatz oft die realistische Legacy-Ablösung ist

Legacy-systemer er sjældent „kun en applikation“. Ofte er der tilknyttet: batchkørsler, filgrænseflader (SFTP-mapper, netværksdrev), udskrifts- og scanneprocesser, lokale værktøjer, BI-ekstrakter, e-mail-relæer, specialhardware, Shadow-IT-udløb og manuelle workarounds. Ved et Big Bang skal alle disse spor fungere samme weekend – inklusive rettigheder, stamdata, historik og særtilfælde.

Trin-for-trin-tilgangen reducerer risikoen, men flytter den ikke automatisk „ned“. Den gør risici mere synlige og håndterbare, men kræver til gengæld klare arkitektur- og driftsbeslutninger: Hvor routes der? Hvem er dataansvarlig? Hvilken konsistens er fagligt påkrævet, hvor er tidsmæssig forsinkelse acceptabel? Og hvordan undgår I, at paralleldrift bliver et permanent byggeprojekt?

Strangler Pattern in der Unternehmensrealität: nicht „Microservices“, sondern klare Schnittkanten

Det Strangler Pattern betyder: I bygger nye funktioner ved siden af det gamle system og omdirigerer trafikken gradvist, indtil den gamle del er overflødig. Vigtigt: Det er ikke en arkitektur-religionskrig („Monolith vs. Microservices“), men et Migrationsmuster. Det fungerer også, hvis målarkitekturen fortsat er en monolit – bare mere moderne, vedligeholdelsesvenlig og lettere at integrere.

Die wichtigste Entscheidung: Schneiden Sie nach Prozessen, nicht nach Tabellen

I mange udskiftninger skæres der datadrevet („Wir nehmen zuerst die Tabellen für Kunden und Aufträge“). Det fører ofte til smertefuld paralleldrift, fordi processer går på tværs af disse data. Bedre er et prozessorientierter Schnitt, f. eks. „Angebotserstellung“, „Wareneingang“, „Reklamationsabwicklung“ oder „Service-Ticket bis Rechnung“.

Praksisregel: En Strangler-etape bør dække et fagligt sammenhængende forløb, som kan drives og overvåges ende-til-ende i det nye system. Det omfatter indgange (UI, API, import), behandling (forretningsregler) og udgange (udskrift, eksport, bogføring, notifikation).

Strangler har brug for en „Umlenker“: Gateway, Proxy eller Routing-Schicht

For at brugere og tilsluttede systemer ikke konstant skal lære nye endepunkter, bruges ofte et routinglag. Afhængig af udgangssituationen kan det være: en Reverse Proxy foran webapplikationer, et API-Gateway for serviceendepunkter eller et integrationslag, der samler filgrænseflader og events. Det centrale er driftsmuligheden: central konfiguration, klare logs, monitoring og en kontrolleret rollback.

Det er vigtigt for administratorer, at dette lag ikke bliver en Blackbox. De har brug for efterviselige routings (hvilken Request gik hvor), korrelation via logs (f.eks. Request-ID) og definerede Timeouts/Retry-Regeln, så fejl ikke „klistrer sig fast“.

Paralleldrift er en driftsmæssig tilstand – ikke et „Projekttrick“

Paralleldrift betyder: gamle og nye komponenter kører samtidigt i produktion i en periode. Det er normalt, men dyrt – især i driften. I har flere bevægelige dele, mere monitoring, større incident-potentiale og mere komplekse ansvarsforhold. Derfor skal paralleldrift planlægges som en tidsbegrænset driftsmode, inklusive afbrydelseskriterier.

Typiske paralleldriftsmodeller (og hvornår de passer)

• Skift efter brugergrupper (pilotgruppe → bølger): egnet, når brugerroller er klart adskilte og processer ikke går på tværs af grupper.
• Skift efter mandant/placering: velegnet ved filial-/fabriksstrukturer, når dataflows mellem lokationer er begrænsede.
• Skift efter procestrin: f.eks. „Erfassung neu, Abrechnung noch alt“ – risikabelt, hvis der findes mange tilbagemeldingssløjfer, men nogle gange uden alternativ.
• Skift efter objekttyper: f.eks. nye anlægsaktiver i det nye system, restbeholdning i det gamle – kan fungere, hvis der findes klare regler for historik/reporting.

Fra driftsmæssigt perspektiv bør I designe paralleldrift, så fejldomænerne forbliver små: En defekt i den nye komponent må ikke trække legacy-systemet med (f.eks. gennem blokerende Schnittstellen eller databaselocks), og omvendt må legacy ikke sabotere alle nye forløb gennem ustabile eksporter.

Feature Flags und Routing-Regeln: Kontrolle statt „wir rollen aus und hoffen“

Feature Flags er kontakter, som giver mulighed for selektivt at aktivere/deaktivere funktioner – uden nyt Deployment. For IT-ledelse og projektansvarlige er det ikke de tekniske detaljer, der er afgørende, men Governance: Hvem må skifte? Hvordan dokumenteres, hvorfor der blev skiftet? Hvor hurtigt kan I rulle tilbage? Hvilke afhængigheder opstår (f.eks. hvis data allerede er blevet genereret i det nye format)?

En fornuftig praksis er et lille change-protokol (Decision Log) per skifteaktion: tidspunkt, Owner, berørt brugergruppe, forventet effekt, monitoring-kendetegn, rollback-betingelse. Det forhindrer det klassiske „Niemand weiß mehr, warum es so geroutet ist“.

Datakonsistens i rollout: Der Kern, an dem viele Ablösungen hängen

Datakonsistens betyder, at data er fagligt korrekte, komplette og tilgængelige i den forventede rækkefølge. I parallel drift bliver det vanskeligt, fordi to systemer skriver samtidigt eller i hvert fald begge gør krav på at være „Wahrheit“. Her afgøres det, om udfasningen af legacy-systemet virker stabil, eller om I skal køre delta-sammenligninger i månedsvis.

Klarlæg først: Hvem er „System of Record“ for hvert dataområde?

I skal for hvert dataområde (z. B. Debitoren, Artikel, Preise, Aufträge, Lagerbewegungen, Belege) fastlægge, hvilket system er førende. Det er ikke kun et arkitekturspørgsmål, men operationelt:

• Hvor foretages korrektioner i supporttilfælde?
• Hvor hører frigivelsesprocessen hjemme (Vier-Augen, SoD/Trennung von Funktionen)?
• Hvilke Audit-Spuren er påkrævede (wer hat wann was geändert)?
• Hvordan undgås efterarbejde i Monatsabschluss?

I de tidlige Strangler-etaper er det ofte fornuftigt først at lade Legacy være datafører og lade den nye komponent „nur“ konsumere. Senere vender I føringen. Dette førerskifteværk er en selvstændig milepæl og kræver et klart Cutover-Fenster samt en kommunikations- og abnahmeplan.

Synchronisationsmuster: Dual Write, CDC und Events – mit realistischen Erwartungen

Der er flere måder at synkronisere data mellem Alt og Neu på. Ingen er „kostenlos“.

• Dual Write: En handling skriver til begge systemer (z. B. Auftrag anlegen → Legacy und neues System). Fordel: hurtig tilgængelighed. Ulempe: fejltilfælde er komplekse (hvad hvis System A skriver, System B ikke?), derudover opstår afhængigheder og ofte performance-Risiken.
• Change Data Capture (CDC): Ændringer udtrækkes fra databasens log eller over Trigger/Replication som Deltaer. Fordel: adskiller Anwendung og Synchronisation. Ulempe: I replikerer også „technische“ ændringer og må rekonstruere faglige hændelser; desuden bliver Schemaänderungen i Legacy pludselig en integrationsrisiko.
• Event-basierte Integration: Systemet publicerer faglige Ereignisse (z. B. „Auftrag freigegeben“), som andre systemer konsumerer. Fordel: klar faglig semantik. Ulempe: kræver rene Ereignisdefinitionen, Idempotenz (Mehrfachverarbeitung ohne Schaden) og et robust Messaging-Betriebskonzept.

For beslutningstagere er det afgørende: Datakonsistens er ikke binær. Nogle processer kræver stærk konsistens (øjeblikkelig korrekt, z. B. Zahlungsfreigaben), andre tolererer eventual consistency (kort forsinkelse, z. B. Suchindex, Reporting, Benachrichtigungen). Denne inddeling bør tidligt aftales med Fachbereich und Revision/Audit.

Konflikte und Dubletten: Planen Sie den „hässlichen Pfad“ explizit

I parallel drift opstår konflikter typisk sådan: To systemer ændrer det samme objekt, men efter forskellige regler. Eller et importkørsel kører dobbelt, fordi et retry kom „for tidligt“. Eller en bruger retter data i legacy, mens den nye grænseflade allerede var taget i brug.

I har brug for bindende regler til dette:

• Konfliktløsning: „Last write wins“ er sjældent fagligt korrekt. Bedre er prioriteter (det førende system vinder) eller faglige merge-regler (fx kontaktstamdata vs. betingelser).
• Idempotenz: Hver integration bør kunne håndtere flerfoldig behandling uden dubletter (fx samme registreringsnummer, samme eksterne reference).
• Dead-Letter/karantæne: Ubehandlelige deltas skal kunne findes, med klar ansvarlighed og mulighed for genkørsel.

Uden disse regler glider datakonsistensen over i „Excel-afstemning“ og manuel efterbearbejdning – med tilsvarende frustration og svært målbare følgeomkostninger.

Rollout-design: bølger, godkendelser og tilbagefald uden at overbelaste driften

Et godt rollout er mere end „Deployment + oplæring“. I parallel drift skal I sammenkæde rollout og drift: Hvem håndterer første linje ved fejl? Hvilke logs er straks tilgængelige? Hvordan eskaleres der? Hvilke processer må ikke ændres i en bølge (fx månedsafslutning, inventaroptælling, prisændring)?

Bølgeplanlægning med hårde kriterier

Det har vist sig effektivt med en bølgeplanlægning med klare indtrædelseskriterier, ikke kun datoer. Eksempler på hårde kriterier:

• Overvågningsdashboards og alerting for den nye komponent er live og testet (inklusive reduceret „alarm-støj“).
• Runbooks for typiske hændelser findes (timeouts, køophobning, fejlbehæftede imports, autorisationsfejl).
• Delta-afstemning er automatiseret og leverer forståelige rapporter (differencer efter objekttype, tidsvindue, årsagsklasse).
• Rollback-mekanisme er øvet (mindst realistisk gennemspillet i Staging/Pre-Prod).

Især det sidste punkt undervurderes ofte: Rollback er ikke „vi skifter bare tilbage“. Hvis det nye system allerede har produceret data, skal I vide, hvordan disse data bliver synlige i legacy, eller hvordan I korrekt migrerer/neutraliserer de producerede data.

Cutover — mini-cutovers i stedet for Big Bang

Også ved Strangler Pattern er der cutovers – blot mindre. Typisk er mini-cutovers ved skift af et procestrin eller ved ændring af dataejerskab. Hver mini-cutover kræver:

• Datafreeze (kort, men bindende): Hvem må ændre hvad i denne periode?
• Afstemning: Hvad er ændret siden sidste sync?
• Omskiftning: routing/feature flags, jobs, tidsplaner, rettigheder.
• Verifikation: Faglige smoke-tests (fx oprettelse af ordre → følgeseddel → faktura), plus tekniske checks (køer, fejlrater, DB-belastning).

For IT-ledelsen er det vigtigt, at disse trin er dokumenteret som en gentagelig proces og personelt sikret. Ellers hviler projektsuccesen på enkeltpersoner, som „ved, hvordan det gøres“.

Stabiliser grænsefladerne først: Det undervurderede fundament for afvikling af legacy

Mange legacy-systemer kommunikerer via voksede grænseflader: CSV-eksporter til mapper, natlige jobs, direkte databaseadgange fra tredjepartsværktøjer, e-mail-baserede arbejdsgange. En trinvis afvikling bliver betydeligt lettere, hvis I først inventariserer grænsefladelandskabet og konsoliderer det på få steder.

Praktisk betyder det: Identificer systemkritiske integrationspunkter (f.eks. finansbogholderi, forsendelse, produktionsreturmeldinger, identiteter/rettigheder) og etabler klare kontrakter dér. „Kontrakt“ betyder her ikke juridisk, men teknisk stabilitet: versionering, entydige felter, stabile ID’er, dokumenteret fejlbehandling, definerede SLAs for datalevering.

Hvis I dertil etablerer en intern API-/Integrations-Governance-model (Owner, Deprecation-Regeln, Test-/Staging-Pfade), mindskes risikoen for, at en legacy-ændring pludselig lammer jeres nye komponent. Et passende internt linkpunkt kunne f.eks. være et indlæg om API-Governance og Deprecation-Strategien.

Sikkerhed, rettigheder og audit: Paralleldrift forstærker udfordringen

I paralleldrift opstår ofte dobbelte bruger- og rollemodeller. Det fører til skyggerettigheder: En bruger er i det nye system korrekt begrænset, men har i legacy stadig vidtrækkende rettigheder – og ender med at bruge den „nemmere vej“. Hertil kommer tekniske konti (Service Accounts) til synkronisering, imports, køer og batchjobs.

Konkrete punkter, I bør afklare tidligt:

• Identitetskilde: Hvor kommer brugere og grupper fra? AD/Entra ID? Et eget IAM? Det er vigtigt, at provisioneringen er efterviselig.
• Rollenmapping: Hvis roller ikke passer 1:1, skal der være overgangsroller, som er tidsbegrænsede og bliver recertificeret.
• Service Accounts: Minimale rettigheder, secrets-rotation, korrekt logføring. Især synkroniseringskonti er ellers et indgangssted og svære at auditere.
• Audit-Trails: Når dataeierskab skifter, skal det være klart, hvor beviset for ændringer ligger, og hvordan det kan undersøges på tværs af begge systemer.

Vigtigt for beslutningstagere: Sikkerhed er her ikke „ekstra scope“, men påvirker gennemførligheden af rolloutet. Et senere efterslæb vedrørende rettigheder i paralleldrift er som regel dyrere end et tidligt, pragmatisk snit for roller og servicekonti.

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

I paralleldrift er fejlbilleder ofte indirekte: Et delta hænger, et retry kører i ring, en kø hober sig op, eller et tidskritisk job kolliderer med en databaselås. Hvis I kun ser det via brugersager, er I for sent. I har derfor brug for fra starten et observability-minimum: Monitoring (tilstand), Logging (hændelser) og – hvor det er relevant – Tracing (kæde på tværs af systemer).

Praktiske, godt driftbare signaler er for eksempel:

• Synchronisations-Backlog (hvor mange ændringer „venter“), plus alderen på den ældste post.
• Fejlrate pr. grænseflade og fejlklasse (Validierung, Timeout, Auth, Datenkonflikt).

For drifts‑overdragelsen er det mindre vigtigt, hvilket værktøj der bruges, og mere om ansvar og Runbooks er klare. Hvis I har On-Call eller beredskab, skal driften ved typiske fejl kunne handle uden udvikler‑detektivarbejde.

Hvornår Strangler Pattern ikke passer (eller kun med klare begrænsninger)

Der er situationer, hvor trinvis udfasning kun virker begrænset:

• Ekstremt tæt transaktionskobling: Hvis næsten hver eneste proces går på tværs af alle moduler og kræver hård konsistens, bliver paralleldrift hurtigt uoverskuelig.
• Direkte DB‑adgang fra tredjepartssystemer: Hvis flere værktøjer læser/skriver direkte i legacy‑tabeller, må denne vildtvoksende tilstand først stoppes eller kontrolleres.
• Uklart dataejerskab: Hvis det ikke kan fastlægges, hvem der fører data, er konflikter garanteret – og udfasningen bliver politisk fremfor teknisk.
• Manglende driftsdisciplin: Uden rene miljøer, reproducerbare deployments og overvågning bliver hvert mellemtrin en risiko.

Det betyder ikke, at I er tvunget til et Big Bang. Men I må så ændre rækkefølgen: Stabiliser integrationspunkterne først, centralisér dataadgang, klarlæg roller og ownership – og begynd først derefter at stranglen.

En praksisegnet handlingsplan for legacy‑udfasning i etaper

Som orientering for projektansvarlige har en fremgang i klare etaper vist sig effektiv. Den præcise udformning afhænger af system og branche, men logikken er robust:

1. Inventar & Afhængigheder: Grænseflader, jobs, dataflows, brugergrupper, kritiske tidsvinduer (afslutning, lageroptælling).
2. Definer snitflader: Procesmoduler, dataejerskab pr. område, integrationskontrakter.
3. Byg routing & skiftere: Gateway/Proxy, Feature Flags, central protokollering.
4. Fastlæg datapath: CDC/Event/Dual Write, konfliktregler, karantæne, afstemningsrapporter.
5. Pilot med reel belastning: ikke kun demo, men med reelle sager, inklusive undtagelser.
6. Bølgeudrulning: Indtrædelseskriterier, Cutover‑tjeklister, rollback‑øvelser.
7. Slukning & oprydning: Deaktiver gamle stier, fjern jobs, tilbagekald rettigheder, opdater dokumentationen.

Det sidste punkt er essentielt: Mange organisationer lader legacy‑komponenter køre „for en sikkerheds skyld“. Resultat: dobbelte omkostninger, uklart risiko‑billede, ingen tør slukke. Planlæg dekommissionering som et delprojekt med deadline, ansvarlige og beviser (f.eks. „ingen adgang i X uger“, „alle eksporter omstillet“, „audit‑krav opfyldt“).

Konklusion: Trinvist udskifte betyder at behandle konsistens og drift som et produkt

En trinvis legacy‑udfasning er ikke automatisk nemmere – men i mange virksomheder den eneste realistiske mulighed. Strangler Pattern virker, når I for hver etape definerer klare proces‑snitflader, planlægger paralleldrift som en reel driftsform og ikke overlader datakonsistens til tilfældet. Afgørende er tidlige beslutninger om dataejerskab, robuste synkroniseringsmønstre med konfliktregler samt et rollout‑design med bølger, godkendelser og øvet rollback.

Hvis I planlægger en udskiftning og ønsker at gennemgå grænsefladerne, paralleldriften eller konceptet for datakonsistens på en struktureret måde, kan I kontakte os via .

Drøft projekt eller moderniseringsprojekt med Net-Base.