Náhrada legacy enterprise systému za 3 měsíce: kompromisy, které fungují

„Máme starý systém, ale migrace je nereálná, big bang nepůjde.“ Slyšíme to často. Důvod je zdravý strach zrewrite, který končí jako 18měsíční projekt bez funkčního výstupu. Pro JUST jsme měli opačný problém: starý systém přestával fungovat a měli jsme 3 měsíce na celou náhradu, protože licence legacy systému končila.

Stihli jsme to. Tady je, jak — a co jsme záměrně nedodali v první verzi, aby to šlo.

Pravidlo 1: Scope triage před kickoff

Starý systém JUSTu uměl ~120 business use cases. Plná replikace by byla 9-12 měsíců. Za 3 měsíce jdeme, pokud scope stáhneme namust-have k Day 1 produkce.

Triage proběhla tak, že jsme s CFO a IT manažerem sedli a kategorizovali každou funkci:

• Day 1 MUST (40 %): bez toho nejede byznys. Provize, objednávky prodejců, core CRM.
• Day 30 OK (25 %): chybí, ale admin umí udělat ručně 30 dní. Reporting dashboardy, některé admin UI, historical comparisons.
• Day 90 OK (20 %): nikdo by si toho nevšiml 3 měsíce. Bulk export funkce, některé integrace s third parties.
• Day 360 MAYBE (15 %): nikdo je vlastně nepoužívá. Legacy features ze starého systému, zbytky z let minulých.

Výsledek: dodáváme 40 % funkcionality v Day 1, 65 % do měsíce, 85 % do čtvrt roku. 15 % se nikdy nedodalo — nikdo o ně nepožádal.

Pravidlo 2: Core data model první, UI poslední

V 3měsíčním rewrite je lákavé start frontendem — je to to, co klient uvidí. Ale když data model musíš později změnit, přepíšeš taky frontend. Ztráta času.

My pro JUST:

• Týden 1-2: data model (SQL schema) + migrace legacy dat
• Týden 3-5: business logika (provize, objednávky, sdílené workflows) jako pure funkce + unit tests
• Týden 6-8: API nad business logikou
• Týden 9-11: UI (React admin + prodejní portál)
• Týden 12: UAT, dual run, cutover

Frontend poslední znamená, že core logika je hotová a otestovaná, než někdo napíše první button. Pokud se v UAT ukáže, že něco v byznys logice je špatně, fix je jednorázový — nemá co cascade-ovat napříč UI.

Pravidlo 3: Parallel run minimálně 2 týdny

Před DNS switchem / uživatel-cutoverem musí oba systémy běžet vedle sebe a přijímat stejné transakce. Detaily:

• Nový systém dostává kopii každé transakce ze starého systému (read replica nebo event sourcing)
• Uživatelé stále pracují ve starém
• Každou noc porovnání — jsou stavy v obou systémech konzistentní?
• Odchylka > 0,1 % = alert, nezapínáme cutover

Pro JUST jsme v parallel run odhalili 4 case, kde se systémy lišily. 3 byly naše bugy, 1 byl bug v legacy, který byznys nikdy neviděl. Cutover se odehrál, když deltové byly pod 0,05 %.

Pravidlo 4: Cutover day — rollback je nepovinný, ale řešený

Cutover day pro JUST:

• Pátek 22:00 — freeze starého systému, read-only režim
• 22:15 — poslední delta dat z legacy do new
• 22:30 — DNS switch + uživatelé přesměrováni na nový
• 22:45 — smoke testy (login, vytvořit objednávku, zobrazit provize)
• 23:00 — signal „live“ nebo rollback trigger

Rollback trigger: pokud do 22:55 smoke testy selžou, DNS flipne zpět na legacy, migration reset. Legacy běží v read-only přes weekend, znovu cutover v pondělí. Ve 3měsíčním projektu s kritickým termínem musí rollback plán existovat — ale my ho nikdy nepotřebovali. Dobrá příprava to eliminuje.

Pravidlo 5: Week 1 post-launch = bug-fixing sprint

Produkce se liší od staging. I po důkladném UAT se objevují bugy — edge cases, které nikdo netestoval. První týden jsme rezervovali 100 % kapacity týmu na bug fixing. Žádný development, žádné nové featury, jen hot-fixes.

Z praxe: 10-20 bugů první týden, 3-5 druhý, 1-2 třetí. Ve 4. týdnu se vrátíme k roadmap. Kdo si naplánuje na týden 1 nové featury, udělá chaos.

Co jsme nedodali a nikdy nedodali

Z 15 % „Day 360 MAYBE“ věcí:

• Custom report pro starou kvartální strukturu, která se změnila v 2019 (nikdo to neřekl; byznys ji nepotřebuje)
• Integrace na ERP, který klient nahradil v průběhu projektu
• 3 specifické bonusy pro top 5 prodejců, které se daly nahradit manualem

Legacy systém nabobtnal 15 let featurami, které kdysi někdo potřeboval a později ne. Rewrite je šance to zjednodušit. Nezopakovat ten cyklus = nedělat featury, o které si byznys výslovně nezažádá.

Co si z toho vzít

3měsíční legacy replacement je možný, když:

• Scope triage s business je na začátku, ne v půlce
• Data model → business logic → API → UI, ne naopak
• Parallel run > 2 týdny bez deltaz
• Cutover day má rollback plán, i když ho nepoužiješ
• Week 1 post-launch = bug-fixing sprint, ne roadmap

Klientů, kterým tohle sedí, je víc, než se říká. Strach z rewrite je často z jiné story — 12měsíční projekt, který selhal kvůli absenci triage. Když triage uděláš dobře, 3 měsíce stačí.