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 z rewrite, 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čí.