Pokud systém stále zajišťuje důležité procesy a uchovává potřebná data, kompletní přepsání by nemělo být první reakcí. Nejprve je třeba určit, kde skutečně vzniká problém: v celé architektuře, jednom modulu, datovém modelu, integraci nebo způsobu nasazování změn.
Vývoj od nuly dává smysl, když nelze důležité části bezpečně zachovat nebo když omezení starého řešení brání splnění podstatného obchodního cíle. V řadě jiných případů je vhodnější začít stabilizací, výměnou nejproblematičtějšího modulu nebo řízenou migrací po etapách.
Konečné rozhodnutí musí vycházet z konkrétního kódu, dat a provozního procesu. Samotné stáří aplikace ani název použité technologie nestačí.
„Přepíšeme všechno“ zní jednodušeji, než ve skutečnosti je
Starý systém může být zdrojem každodenních potíží. Nasazení trvá dlouho, jedna oprava naruší jinou funkci a dokumentace už neodpovídá skutečnému provozu. Nová aplikace slibuje pořádek, ale spolu s nepořádkem mohou zmizet i obchodní pravidla, která nikdo nezapsal, přestože se o ně zaměstnanci a zákazníci každý den opírají.
Je také nutné porozumět datům, oprávněním, reportům, integracím a výjimkám, které se dnes řeší ručně. Pokud se odhalí až během realizace, může být nové řešení technicky čistší, ale pro firmu méně použitelné.
Nový kód nemá hodnotu jen proto, že je nový. Musí řešit konkrétní problém: snížit riziko, usnadnit další změny, zlepšit stabilitu nebo zjednodušit práci uživatelů.
Čtyři možné směry
| Směr | Kdy o něm uvažovat | Co je nutné zabezpečit |
|---|---|---|
| Stabilizace a další rozvoj | Jádro systému funguje a poruchy či nákladné změny se soustředí do několika míst. | Kritické procesy, zálohy, testy nejdůležitějších scénářů, nasazování a přehled o chybách. |
| Postupná výměna modulu | Jedna část brání rozvoji, ale zbytek aplikace má stále hodnotu. | Hranice dat a integrací a období, kdy starý a nový modul fungují souběžně. |
| Řízená migrace | Stará platforma nebo datový model mají zásadní omezení, přechod však lze rozdělit na etapy. | Porovnání dat, pořadí přepínání procesů, kontinuitu provozu a možnost návratu. |
| Vývoj od nuly | Hodnotné části nelze zachovat nebo jejich omezení znemožňují dosažení cíle. | Celý rozsah funkcí, skrytá pravidla vzniklá během let, migraci dat, souběžný provoz a ukončení starého systému. |
Tabulka pomáhá rozhovor uspořádat, ale nenahrazuje audit. Stejný příznak, například pomalé nasazování změn, může způsobovat architektura, chybějící testy, nespolehlivý proces vydávání nebo několik problémů současně.
Čtyři otázky před rozhodnutím
- Zajišťuje systém stále správně klíčové procesy a data?
- Které části způsobují nejvíce poruch, ruční práce nebo nákladných oprav?
- Dostává použitá technologie bezpečnostní aktualizace a může běžet v udržovaném prostředí?
- Lze moduly oddělit a měnit bez zastavení celé firmy?
Pokud se problém týká jedné oblasti, není důvod automaticky znovu vytvářet celou aplikaci. Nový vývoj je rozumnější tehdy, když systém nelze spolehlivě spustit v opakovatelném prostředí, klíčové závislosti už nejsou podporované a data ani moduly nelze bezpečně oddělit.
Pokud rozhodnutí urychlila kritická zranitelnost PHP, nejprve oddělte naléhavou aktualizaci prostředí od další modernizace. Pořadí kroků vysvětluje návod „Kritické zranitelnosti PHP z října 2026: co dělat se starou aplikací?“.
Co prověřit před volbou řešení
Posouzení se nemůže omezit jen na kód. Je třeba zjistit:
- které procesy nesmějí být přerušeny;
- kde jsou data uložena a jak se zálohují;
- které externí systémy si s aplikací vyměňují informace;
- jaké role a oprávnění se skutečně používají;
- jak dnes fungují testy, nasazení, monitoring a návrat k předchozí verzi;
- které provizorní postupy se staly součástí běžné práce;
- jaký měřitelný výsledek má přinést první etapa.
Bez těchto odpovědí lze snadno porovnat cenu opravy několika viditelných problémů s cenou neúplné verze nového systému. Takové srovnání není férové. Nové řešení musí zahrnout také migraci, integrace, zachování dat, přechodné období a převzetí nejdůležitějších procesů.
Kdy je modernizace vhodnější
Postupná modernizace má dobrý základ, pokud systém stále funguje, obsahuje hodnotná data, má aktivní uživatele a dovoluje vymezit hranice mezi moduly. Nejdříve lze stabilizovat kritická místa, chránit důležité chování testy a zlepšit přehled o chybách.
Poté se nahrazují části, které firmu omezují nejvíce. Každá etapa má mít vlastní rozsah, kritéria převzetí a plán návratu. Další rozhodnutí pak vycházejí ze skutečných poznatků o systému, ne pouze z předpokladů na začátku projektu.
Kdy dává smysl vývoj od nuly
Novou aplikaci je vhodné vážně zvážit, pokud současná platforma už není podporovaná, datový model neumožňuje potřebný rozvoj, požadavky firmy se zásadně změnily nebo by bezpečné oddělení staré aplikace stálo více než její řízená náhrada.
Ani tehdy není nutné vše přepnout v jediný den. Nejprve lze převést jeden proces, porovnat výsledky a teprve potom rozšiřovat rozsah. Migrace dat, souběžný provoz a cesta zpět jsou součástí projektu, nikoli úkoly, které se doplní těsně před spuštěním.
Příklad z portfolia: různé etapy vývoje Tempus
Portfolio Domin Software dokumentuje několik oblastí práce pro obchod Tempus. Patřilo mezi ně čištění existujícího kódu a vývoj vlastních modulů, aktualizace platformy a grafické vrstvy i migrace ze sStore na PrestaShop s převodem produktů a zákazníků.
To neznamená, že každá aplikace má projít stejnou cestou. Příklad ukazuje, že volba mezi rozvojem a přepsáním nemusí být jedním rozhodnutím pro celou životnost systému. V jedné etapě může mít smysl oprava a další rozvoj, v jiné řízený přechod na nový základ.
Popsaný rozsah najdete v portfoliu Domin Software. Nepředstavujeme jej jako důkaz konkrétního obchodního výsledku ani jako hotový návod pro jinou firmu.
OBIBOOK: oprava před přestavbou
V projektu OBIBOOK jsme nejprve opravili import CSV a fungování na mobilních zařízeních. Úplná přestavba katalogu knih následovala později jako samostatná etapa. Příklad ukazuje, proč oprava potřebná dnes a rozhodnutí o dalším rozvoji nemusí mít stejný rozsah.
Most místo jednoho velkého skoku
Při větší změně mohou staré a nové řešení po určitou dobu fungovat vedle sebe. Vybrané procesy se převedou do nového modulu, data se přesouvají po částech a výsledky se porovnají před rozšířením rozsahu. Uživatelé mohou přecházet po skupinách místo změny celého pracovního prostředí v jediný den.
Tento přístup odpovídá vzoru Strangler Fig, který popsal Martin Fowler. Složitý projekt díky němu nebude automaticky jednoduchý, ale lze omezit riziko jednorázové náhrady všeho a ověřovat jednotlivé etapy.
Kde může pomoci DominPress
Pokud se změna týká veřejných stránek, obsahu, formulářů nebo nových webových modulů, lze DominPress přidat jako novou vrstvu bez okamžité výměny celého firemního zázemí. Není však automatickou odpovědí na každý starší systém. Volba musí vycházet z procesů, dat, integrací a plánu další údržby.
Co uvést v první zprávě
Pro úvodní rozhovor si připravte:
- stručný popis systému a jeho uživatelů;
- nejdůležitější proces, který nelze přerušit;
- konkrétní problém, který brání rozvoji nebo způsobuje chyby;
- použitou technologii a verzi, pokud je znáte;
- seznam nejdůležitějších integrací;
- očekávaný výsledek první etapy;
- informaci, zda existují aktuální zálohy, testovací prostředí a dokumentace.
Neposílejte hesla, klíče, kopii produkční databáze ani skutečná data zákazníků. Na začátku stačí popis problému a kontext, podle něhož lze odlišit konkrétní úkol, technické posouzení nebo první etapu modernizace.
Pokud modernizace souvisí se změnou dodavatele, přečtěte si také, jak začít s převzetím aplikace novým vývojářem. Popisujeme informace potřebné před předáním kódu a účtů.
Zvolme správný směr pro stávající systém
Nepředpokládáme, že aplikaci je nutné přepsat. Nejprve zjišťujeme, co má stále hodnotu, co firmu skutečně omezuje a jak snížit riziko změny. Rozsah takové práce popisuje naše služba modernizace systémů.
Chcete-li začít konkrétním případem, popište problém ve stávajícím systému.