„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: Třídění rozsahu před zahájením
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: Nejdřív datový model, UI nakonec
V 3měsíčním rewrite je lákavé start frontendem — je to to, co klient uvidí. Ale když data model musíte později změnit, přepíšete 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: Souběžný provoz 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: Den přepnutí — návrat zpět je nepovinný, ale připravený
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: První týden po spuštění = sprint na opravy chyb
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žijete
- 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áte dobře, 3 měsíce stačí.