Odstranění legacy systémů krok za krokem: Strangler Pattern, paralelní provoz a konzistence dat při nasazování

Jedna nahrazení zastaralého systému zřídkakdy selže při „vytváření“ nového řešení; selhává spíše při přechodu: data musí zůstat správná, rozhraní se nesmí přerušit a provoz musí během přechodu běžet dál. V mnoha podnicích proto není Big-Bang-Cutover možností – závislosti jsou příliš rozsáhlé, náklady na výpadek příliš vysoké a zpětné vrácení příliš složité.

V praxi se osvědčuje krokový přístup se Strangler Pattern (funkční části se postupně „přesměrovávají“), paralelním provozem (starý i nový systém běží dočasně vedle sebe) a jasnými pravidly pro konzistenci dat. Tento článek ukazuje, jak tyto stavební kameny kombinovat tak, aby byly v každodenní praxi IT vedení, administrace a projektové odpovědnosti udržitelné – včetně typických chybových vzorců, provozních důsledků a rozhodovacích míst při rolloutu.

Proč je krok za krokem často realistické řešení náhrady legacy systému

Legacy systémy zřídkakdy znamenají „pouze jednu aplikaci“. Obvykle jsou na nich napojeny: dávkové úlohy, souborová rozhraní (SFTP-ordner, síťové jednotky), tiskové a skenovací procesy, lokální nástroje, BI-extrakty, E-Mail-Relays, Shadow-IT-vývody a manuální obcházení. Při Big Bang musí všechny tyto cesty fungovat ve stejném víkendu – a to včetně oprávnění, základních dat, historie a zvláštních případů.

Krokový přístup riziko snižuje, ale nezřídka jej automaticky nepřenáší „níže“. Dělá rizika viditelnějšími a lépe zvládnutelnými, vyžaduje však čistá architektonická a provozní rozhodnutí: Kam se směruje provoz? Kdo je zdrojem pravdy pro data? Jaká konzistence je odborně nezbytná a kde stačí časové zpoždění? A jak zabráníte tomu, aby paralelní provoz nezůstal trvalým stavem?

Strangler Pattern v podnikové realitě: nejde o „Microservices“, ale o jasné hranice rozhraní

Strangler Pattern znamená: vyvíjíte nové funkce vedle starého systému a provoz postupně přesměrováváte, dokud stará část není nadbytečná. Důležité: nejde o architektonický náboženský spor („Monolith vs. Microservices“), ale o migrační vzor. Funguje i v případě, že cílová architektura zůstane monolitická – pouze modernější, lépe udržovatelná a lépe integrovatelná.

Nejdůležitější rozhodnutí: Řežte podle procesů, ne podle tabulek

V mnoha náhradách se řeže datově („Nejprve vezmeme tabulky pro zákazníky a objednávky“). To často vede k bolestivému paralelnímu provozu, protože procesy zasahují napříč těmito daty. Lepší je procesně orientované dělení, např. „vytváření nabídky“, „příjem zboží“, „řešení reklamací“ nebo „servisní ticket až fakturace“.

Pravidlo z praxe: etapa Strangler by měla pokrývat odborně uzavřený tok, který lze v novém systému provozovat a monitorovat end-to-end. Patří sem vstupy (UI, API, import), zpracování (business-pravidla) a výstupy (tisk, export, zaúčtování, notifikace).

Strangler potřebuje „přesměrovač“: brána, proxy nebo směrovací vrstva

Aby uživatelé a napojené systémy nemuseli pokaždé znát nové endpointy, používá se často směrovací vrstva. V závislosti na výchozí situaci to může být: reverse proxy před webovými aplikacemi, API‑Gateway pro servisní endpointy nebo integrační vrstva, která konsoliduje souborová rozhraní a události. Rozhodující je provozuschopnost: centrální konfigurace, jasné logy, monitorování a řízený rollback.

Pro administrátory je důležité, aby se tato vrstva nestala černou skříňkou. Potřebují sledovatelná routování (který request šel kam), korelaci přes logy (např. Request-ID) a definovaná časová omezení a pravidla opětovného pokusu, aby se chyby „nelepily“.

Paralelní provoz je provozní režim – není to „projektový trik“

Paralelní provoz znamená: staré a nové komponenty běží po určitou dobu současně produktivně. To je normální, ale nákladné – především v provozu. Máte více pohyblivých částí, více monitoringu, vyšší potenciál incidentů a složitější odpovědnosti. Proto musí být paralelní provoz naplánován jako časově omezený provozní režim, včetně kritérií pro ukončení.

Typické modely paralelního provozu (a kdy se hodí)

• Přepínání podle uživatelských skupin (pilotní skupina → vlny): vhodné, když jsou uživatelské role jasně oddělitelné a procesy neprobíhají přes skupiny.
• Přepínání podle mandantů/lokací: dobré pro pobočkové/závodní struktury, pokud jsou datové toky mezi lokacemi omezené.
• Přepínání podle kroků procesu: např. „zadávání nově, účtování zatím staré“ – riskantní, pokud existuje mnoho zpětných vazeb, ale někdy nevyhnutelné.
• Přepínání podle typu objektu: např. nové dlouhodobé majetky v novém systému, historické zůstatky ve starém – může fungovat, pokud existují jasná pravidla pro historii/reporting.

Z pohledu provozu byste měli navrhnout paralelní režim tak, aby zóny chyb zůstaly malé: porucha v nové komponentě nesmí strhnout legacy systém (např. blokující rozhraní nebo zámky v databázi) a naopak nesmí legacy svými nespolehlivými exporty sabotovat všechny nové toky.

Feature Flags a routingová pravidla: kontrola místo „nasadíme a doufáme“

Feature Flags jsou přepínače, kterými cíleně aktivujete/deaktivujete funkce – bez nového nasazení. Pro IT vedení a odpovědné za projekt není rozhodující technický detail, ale governance: kdo smí přepínat? Jak se dokumentuje, proč byla změna provedena? Jak rychle lze vrátit zpět? Jaké závislosti to vytváří (např. když už byla data generována v novém formátu)?

Dobrou praxí je malý change protokol (Decision Log) pro každou akci přepnutí: čas, owner, dotčená uživatelská skupina, očekávaný efekt, monitoringové indikátory, podmínka rollbacku. To zabraňuje klasickému „nikdo už neví, proč je to takto routováno“.

Konzistence dat při rolloutu: jádro, na kterém mnoho přechodů stojí

Konzistence dat znamená, že data jsou věcně správná, úplná a dostupná v očekávaném pořadí. V paralelním provozu se to komplikuje, protože dva systémy zapisují současně nebo si alespoň oba nárokují „pravdu“. Zde se rozhoduje, zda náhrada legacy systému bude působit stabilně, nebo zda budete měsíce provádět porovnávání delty.

Nejprve ujasnit: Kdo je „System of Record“ pro každou oblast dat?

Pro každou datovou oblast (např. odběratelé, položky, ceny, objednávky, pohyby na skladě, doklady) potřebujete rozhodnutí, který systém je vedoucí. To není čistě architektonická záležitost, ale provozní:

• Kde se provádějí opravy v případu podpory?
• Kde je umístěn proces schvalování (princip čtyř očí, SoD/oddělení funkcí)?
• Jaké auditní stopy jsou požadovány (kdo kdy co změnil)?
• Jak se zabrání dodatečným pracím při měsíční závěrce?

V raných fázích Strangleru je často rozumné nechat legacy nejprve vést data a novou komponentu pouze konzumovat. Později otočíte vedení. Tento přechod vedení je samostatný milník a vyžaduje jasné okno pro cutover, stejně jako komunikační a akceptační plán.

Vzory synchronizace: Dual Write, CDC a události – s realistickými očekáváními

Existuje několik způsobů, jak synchronizovat data mezi starým a novým systémem. Žádný není „bez nákladů“.

• Dual Write: Jedna akce zapisuje do obou systémů (např. vytvoření objednávky → Legacy a nový systém). Výhoda: rychlá dostupnost. Nevýhoda: chybové stavy jsou složité (co když systém A zapíše, systém B ne?), navíc vznikají závislosti a často rizika výkonu.
• Change Data Capture (CDC): Změny se extrahují z databázového logu nebo přes triggery/replikaci jako delta. Výhoda: odděluje aplikaci a synchronizaci. Nevýhoda: replikujete i „technické“ změny a musíte rekonstruovat obchodní události; navíc jsou změny schématu v legacy najednou integračním rizikem.
• Eventově založená integrace: Systém publikuje obchodní události (např. „objednávka schválena“), které jiné systémy konzumují. Výhoda: jasná obchodní sémantika. Nevýhoda: vyžaduje čisté definice událostí, idempotenci (opakované zpracování bez škod) a robustní provozní koncept pro messaging.

Pro rozhodovatele je klíčové: konzistence dat není binární. Některé procesy vyžadují silnou konzistenci (okamžitě správné, např. schvalování plateb), jiné tolerují eventuální konzistenci (krátké zpoždění, např. vyhledávací index, reporting, oznámení). Toto zařazení by mělo být brzy koordinováno s business oddělením a revizí/auditem.

Konflikty a duplicity: Explicitně naplánujte „ošklivou cestu“

Při paralelním provozu vznikají konflikty typicky takto: Dva systémy upravují tentýž objekt, ale podle odlišných pravidel. Nebo import poběží dvakrát, protože retry přišel „příliš brzy“. Nebo uživatel opraví data v Legacy, zatímco nové rozhraní už bylo přepnuto.

Potřebujete pro to závazná pravidla:

• Řešení konfliktů: „Last write wins“ je zřídka odborně správné. Lepší jsou priority (vedoucí systém vyhrává) nebo odborná pravidla slučování (např. základní kontaktní údaje vs. podmínky).
• Idempotence: Každá integrace by měla zvládnout vícenásobné zpracování bez duplikátů (např. stejné číslo dokladu, stejná externí reference).
• Dead-Letter/karanténa: Nezpracovatelné delty musí být dohledatelné, s jasnou odpovědností a možností opětovného spuštění.

Bez těchto pravidel sklouzne konzistence dat do „porovnávání v Excelu“ a manuálních oprav – s odpovídajícím frustrem a těžko měřitelnými následnými náklady.

Návrh rolloutu: vlny, akceptace a návrat bez přetížení provozu

Dobrý rollout je víc než „Deployment + Schulung“. Při paralelním provozu musíte propojit rollout a provoz: Kdo zajišťuje první úroveň podpory při chybách? Které logy jsou okamžitě dostupné? Jak se eskaluje? Které procesy nesmějí být v rámci vlny přepínány (např. měsíční uzávěrka, inventarizace, změna cen)?

Plánování vln s přísnými kritérii

Osvědčilo se plánování vln s jasnými vstupními kritérii, nikoli jen s termíny. Příklady přísných kritérií:

• Monitoring dashboardy a alerting pro novou komponentu jsou v provozu a otestované (včetně redukce „šumu alarmů“).
• Runbooky pro typické incidenty existují (timeouty, zahlcení fronty, chybné importy, chyby oprávnění).
• Porovnání delt je automatizované a dává srozumitelné reporty (rozdíly podle typu objektu, časového okna, třídy příčiny).
• Rollback mechanismus je procvičen (alespoň realisticky proveden ve Staging/Pre-Prod).

Zejména poslední bod se podceňuje: rollback není „prostě přepneme zpět“. Pokud nové systémy již vygenerovaly data, musíte vědět, jak budou tato data viditelná v Legacy nebo jak korektně migrovat/neutralizovat vygenerovaná data.

Cutover – mini-cutovery místo Big Bangu

I u Strangler Pattern jsou cutovery – jen menší. Typicky jsou mini-cutovery při změně kroku procesu nebo při přepnutí vedení dat. Každý mini-cutover potřebuje:

• Zamrznutí dat (krátké, ale závazné): Kdo během něj smí co měnit?
• Porovnání: Co se změnilo od poslední synchronizace?
• Přepnutí: směrování/feature flagy, joby, časové plány, oprávnění.
• Ověření: funkční smoke testy (např. vytvoření objednávky → dodací list → faktura), plus technické kontroly (fronty, chybovost, zátěž DB).

Pro IT vedení je důležité, aby byly tyto kroky zdokumentovány jako opakovatelný proces a personálně zajištěny. Jinak závisí úspěch projektu na jednotlivcích, kteří „vědí, jak na to“.

Nejdřív stabilizujte rozhraní: podceňované základy nahrazování legacy systémů

Mnoho Legacy systémů komunikuje přes narostlá rozhraní: CSV exporty do složek, noční joby, přímé přístupy do databáze třetími nástroji, workflowy založené na e-mailu. Postupná náhrada je výrazně jednodušší, pokud nejprve provedete inventarizaci rozhraní a konsolidujete je na několika místech.

Prakticky to znamená: Identifikujte systémově kritické integrační body (např. finanční účetnictví, expedice, výrobní hlášení, identity/oprávnění) a vybudujte tam jasné smlouvy. „Smlouva“ zde neznamená právní dokument, ale technickou stabilitu: verzování, jednoznačná pole, stabilní ID, zdokumentované zpracování chyb, definovaná SLA pro dodávku dat.

Pokud zavedete interní model API-/integrační governance (Owner, Deprecation-Regeln, Test-/Staging-Pfade), klesne riziko, že změna v legacy náhle paralyzuje vaši novou komponentu. Vhodným tematickým bodem pro interní prolinkování by byl např. článek o API-governance a strategiích deprekování.

Bezpečnost, oprávnění a audit: paralelní provoz problém prohlubuje

V paralelním provozu často existují zdvojené modely uživatelů a rolí. To vede ke stínovým oprávněním: uživatel je v novém systému správně omezený, ale v legacy má stále rozsáhlá práva – a nakonec zvolí „snazší cestu“. K tomu přistupují technické účty (Service Accounts) pro synchronizaci, importy, fronty a batch úlohy.

Konkrétní body, které byste měli vyjasnit co nejdříve:

• Zdroj identit: Odkud pochází uživatelé a skupiny? AD/Entra ID? Vlastní IAM? Důležité je, aby provisionování bylo dohledatelné.
• Mapování rolí: Pokud role nepřecházejí 1:1, je třeba přechodné role, které jsou časově omezené a podléhají recertifikaci.
• Service Accounts: Minimální práva, rotace secretů, spolehlivé protokolování. Zejména synchronizační účty jsou jinak vstupní branou a těžko auditovatelné.
• Auditní stopy: Když se změní vedení dat, musí být jasné, kde je důkaz o změnách uložen a jak je možné jej vyhledat napříč oběma systémy.

Důležité pro rozhodovatele: Bezpečnost zde není „dodatečný Scope“, ale ovlivňuje proveditelnost nasazení. Pozdější dohánění oprávnění v paralelním provozu je zpravidla dražší než dřívější, pragmatické vymezení rolí a servisních účtů.

Monitoring, Logging a předání provozu: Bez observability bude paralelní provoz slepý

V paralelním provozu jsou obrazce chyb často nepřímé: delta se zasekne, opětovný pokus běží donekonečna, fronta se hromadí, nebo časově kritická úloha koliduje s databázovým zámkem. Pokud to vidíte jen přes uživatelské tikety, je pozdě. Proto potřebujete od začátku minimum observability: monitoring (stav), logging (události) a – kde dává smysl – tracing (řetězec přes systémy).

Praktické, dobře provozovatelné signály jsou například:

• Synchronizační backlog (kolik změn „čeká“), plus stáří nejstarší položky.
• Míra chyb pro rozhraní a třídu chyby (validace, timeout, autentizace, konflikt dat).
• Latence na procesní krok (např. objednávka uvolněna až do vytvoření příkazu k odeslání).
• Ukazatele kvality dat (míra duplicit, chybějící povinná pole, neočekávané hodnoty NULL).

Při předání provozu je méně rozhodující, který nástroj se používá, a více to, zda jsou jasné odpovědnosti a runbooky. Pokud máte on-call nebo pohotovostní službu, musí být provoz při typických poruchách schopný jednat bez detektivní práce vývojářů.

Kdy Strangler Pattern nevyhovuje (nebo jen s jasnými omezeními)

Existují situace, ve kterých postupná náhrada funguje jen omezeně:

• Extrémně těsné transakční provázání: Pokud téměř každý proces probíhá napříč všemi moduly a vyžaduje tvrdou konzistenci, stane se paralelní provoz rychle neovladatelným.
• Přímé přístupy k databázi ze strany třetích systémů: Pokud několik nástrojů čte/zapisuje přímo do legacy tabulek, je třeba tento „divoký“ stav nejprve ukončit nebo zpřísnit kontrolu.
• Nejasná datová odpovědnost: Pokud nelze jednoznačně určit, kdo vede data, jsou konflikty zaručené – a náhrada se stane spíše politickou než technickou záležitostí.
• Chybějící provozní disciplína: Bez čistých prostředí, reprodukovatelných nasazení a monitoringu se každý mezikrok stává rizikem.

To neznamená, že jste nuceni k Big Bangu. Musíte ale změnit pořadí: nejprve stabilizovat integrační body, centralizovat přístupy k datům, vyjasnit role a odpovědnost – a teprve poté provádět Strangler Pattern.

Praktický plán pro postupnou náhradu legacy v etapách

Jako orientace pro projektově odpovědné se osvědčil postup ve vymezených etapách. Konkrétní podoba závisí na systému a odvětví, ale logika je robustní:

1. Inventar & Abhängigkeiten: Rozhraní, úlohy, toky dat, uživatelské skupiny, kritická časová okna (uzávěrka, inventura).
2. Schnittkanten definieren: Procesní moduly, datové vedení pro jednotlivé oblasti, integrační smlouvy.
3. Routing & Schalter bauen: Gateway/Proxy, Feature Flags, centrální protokolování.
4. Datenpfad festlegen: CDC/Event/Dual Write, pravidla konfliktů, karanténa, zprávy o srovnání.
5. Pilot mit echter Last: ne jen demo, ale s reálnými případy včetně výjimek.
6. Wellenrollout: Vstupní kritéria, cutover-checklisty, cvičení rollbacku.
7. Abschalten & Aufräumen: Deaktivovat staré cesty, odstranit úlohy, odebrat oprávnění, aktualizovat dokumentaci.

Poslední bod je zásadní: Mnohé organizace nechávají legacy komponenty „pro jistotu“ dál běžet. Výsledek: dvojnásobné náklady, nejasné riziko, nikdo se neodváží vypnout. Naplánujte vyřazení z provozu jako dílčí projekt s termínem, odpovědnými a důkazy (např. „žádné přístupy od X týdnů“, „všechny exporty přesměrovány“, „splněny auditní požadavky“).

Závěr: Postupná náhrada znamená, že konzistenci a provoz je třeba považovat za produkt

Postupná náhrada legacy krok za krokem není automaticky jednodušší – ale v mnoha společnostech je to jediná realistická varianta. Strangler Pattern funguje, pokud pro každou etapu definujete jasné procesní rozhraní, naplánujete paralelní provoz jako reálný stav provozu a nenecháte konzistenci dat náhodě. Klíčové jsou časné rozhodnutí o datovém vedení, robustní synchronizační vzory s pravidly pro konflikty a návrh rolloutu s vlnami, akceptacemi a procvičeným návratem do předchozího stavu.

Pokud plánujete výměnu a chcete strukturovaně projednat hranice integrace, paralelní provoz nebo koncepci konzistence dat, kontaktujte nás přes .

Projednat projekt nebo modernizační záměr s Net-Base.