Pomůžeme vám bezpečně modernizovat kritický systém, který už firmu brzdí.
Nezačínáme velkým přepisem naslepo. Nejdřív odhalíme rizika, rozkryjeme realitu systému a teprve potom navrhneme bezpečný další krok bez chaosu a bez ohrožení provozu.
Rychlé pojmenování rizika
Jasný další krok místo dohadů
Bezpečnější rozhodnutí pro IT i management
Cesta od prvního zjištění až po delivery
Spustit Legacy Risk Check
15 otázek. První obraz o rizikovosti systému. Doporučení dalšího kroku bez závazku.
Pokračovat s dalšími otázkamiPro IT manažery, kteří cítí, že starý systém firmu dusí
Každá změna je pomalá, drahá a nervózní. Nikdo si není jistý, co se kde rozbije. Modernizaci už nejde dlouho odkládat, ale zároveň nechcete podepsat projekt, který spolkne rozpočet a po cestě ochromí provoz.
Přesně proto je naše nabídka postavená jako bezpečná cesta od rizika k výsledku.
Neprodáváme jen vývoj. Prodáváme bezpečný další krok.
Začínáme tím, co klient potřebuje nejvíc: jasno. Pak přidáváme mapu reality, plán modernizace, pilotní ověření a teprve potom samotnou modernizaci.
Kontrola rizik systému
Rychle zjistíte, jak moc je starý systém rizikový a kde hrozí největší problém.
Mapa systému a slabých míst
Rozkryjeme, jak systém opravdu funguje, kde jsou závislosti a co vás dnes nejvíc brzdí.
Bezpečný plán modernizace
Dostanete jasný postup, co řešit teď, co později a jak modernizovat bez chaosu.
Pilotní ověření řešení
Nejdřív ověříme přístup na menší části systému, než se pustíte do většího kroku.
Postupná modernizace systému
Převádíme kritický systém do moderního řešení po etapách a bez zbytečného rizika.
Stabilizace po spuštění
Po release vás v tom nenecháme. Stabilizujeme provoz, rychle řešíme incidenty a pomáháme vašemu týmu zvládnout přechod bez zbytečného stresu.
Za nás mluví naše výsledky
Zjistěte za pár minut, jak moc je váš legacy systém rizikový
Kontrola rizik systému vám ukáže, jestli váš software představuje jen technický dluh, nebo už problém, který firmě zdražuje změny, zpomaluje vývoj a zvyšuje nejistotu.
Skóre rizika, pojmenování slabých míst a doporučení, kde začít.
Nejde o další teorii. Jde o jasný další krok bez závazku.
- Manažerské shrnutí pro vedení firmy
- Navazující hodinová konzultace
- E-book 7 nejdražších chyb při modernizaci
7 nejdražších chyb při modernizaci legacy systému
Zjistěte, jakým chybám se vyhnout při modernizaci legacy systému. Stačí zadat e-mail.
Tohle jsou nejčastější z obav, pro které naši klienti odkládají modernizaci systému
„Bojíme se, že modernizace rozbije provoz.“
Právě proto nezačínáme slepým přepisem. Nejdřív mapujeme realitu, rizika a návaznosti. Cílem je řízený postup, ne skok do tmy.
„Náš systém je moc specifický. Nikdo zvenku to nepochopí.“
Tohle slýcháme často. U legacy systémů je specifické skoro všechno. Důležité je umět systém rozebrat, pochopit a převést do moderní podoby bez zjednodušování reality.
„Nejdřív to musíme perfektně popsat interně.“
Ne vždy. Právě s tímhle často pomáháme. Umíme jít od nejasného a nepřehledného stavu k jasnému plánu.
„Nemáme kapacitu to interně řídit.“
I to je běžná situace. Právě proto dává smysl mít partnera, který ponese kus analytické i realizační odpovědnosti.
Často kladené otázky
Modernizace legacy systému nemusí znamenat kompletní přepis. A často by ani neměla. U kritických systémů je bezpečnější nejprve zjistit jejich skutečný stav, závislosti a nejslabší místa a teprve potom rozhodnout, co zachovat, co refaktorovat a co nahradit.
V Eluvii proto legacy system modernization začínáme analýzou současného řešení. Podle výsledku může následovat postupný refactoring, výměna jednotlivých komponent, migrace nebo kompletní přepis. Cílem je modernizovat systém po zvládnutelných krocích a minimalizovat riziko výpadků nebo problémů v běžném provozu.
Firemní aplikace napsané v Delphi mohou spolehlivě fungovat řadu let. Problém obvykle nastane ve chvíli, kdy je stále těžší najít Delphi programátora, systém zná jen jeden člověk nebo je aplikace závislá na starších verzích knihoven, databází či dalších technologií.
Takový systém není nutné automaticky přepisovat. Umíme převzít existující Delphi aplikaci, zmapovat její stav a pomoci s její další údržbou i rozvojem. Pokud už dává větší smysl modernizace, navrhneme postupný přechod tak, aby nebyl ohrožen běžný provoz firmy.
Někdy ano, ale microservices nejsou automaticky správným řešením každého staršího monolitu. Monolith to microservices migration dává smysl především tehdy, když současná architektura výrazně komplikuje další vývoj, škálování nebo samostatné nasazování jednotlivých částí systému.
Nejdříve proto posuzujeme, kde jsou skutečná omezení současné aplikace. Výsledkem nemusí být rozdělení celého systému na desítky služeb. Často je bezpečnější postupně oddělovat pouze části, u kterých to přinese reálný užitek. Modernizace má odstranit problém, ne jen nahradit starou architekturu módnější.
Ano. U legacy systémů je naopak běžné, že původní dodavatel už není k dispozici, vývojový tým se změnil nebo dokumentace neodpovídá skutečnému stavu aplikace.
Při převzetí nejprve zmapujeme zdrojový kód, architekturu, infrastrukturu, integrace a kritické závislosti. Teprve potom doporučíme další postup. Může jít jen o stabilizaci a převzetí správy, postupnou modernizaci aplikace, refactoring jejích částí nebo migraci na nové řešení.
Nemusíte tedy předem vědět, zda potřebujete opravu, modernizaci nebo kompletní přepis. Právě to je jedna z věcí, které má úvodní analýza zjistit.
COBOL stále pohání řadu kritických podnikových systémů. Rizikem proto nebývá samotný jazyk, ale spíš rostoucí závislost na malém počtu lidí, chybějící dokumentace a obtížné napojování systému na nové aplikace.
Pokud vám chybí COBOL programátor nebo chcete snížit závislost firmy na historické technologii, prvním krokem by mělo být zmapování aplikace a jejích vazeb. Podle výsledku lze systém dále bezpečně provozovat, oddělit od něj některé funkce nebo připravit postupnou migraci. Kompletní přepis je až jedna z možností – ne výchozí řešení.
Ne každý legacy systém potřebuje nový začátek. Pokud je základ aplikace zdravý a problém představují jen některé části kódu, může být legacy code refactoring rychlejší, levnější a bezpečnější než kompletní přepis.
Jindy už ale další opravy pouze prodlužují život řešení, které je drahé na údržbu a omezuje další rozvoj. Rozhodujeme proto podle konkrétního stavu kódu, architektury, používaných technologií, testů, dokumentace a kritických závislostí. Výsledkem může být refactoring, postupná náhrada problematických částí nebo plán kompletní modernizace.
Legacy system migration nemusí proběhnout jedním velkým přepnutím ze starého systému na nový. U kritických aplikací je většinou bezpečnější postupovat po částech.
Nejdříve zmapujeme systém, data, integrace a závislosti. Potom navrhneme cílové řešení a způsob migrace. Jednotlivé části lze převádět postupně a po určitou dobu provozovat staré a nové řešení souběžně. Snižuje se tím riziko, že jeden problém při spuštění ohrozí celý provoz firmy.
Konkrétní postup vždy závisí na systému – právě proto nezačínáme migraci přepisováním kódu, ale pochopením současného stavu.
PHP 5 je již řadu let bez oficiální bezpečnostní podpory. Aplikace, která na něm stále běží, tak může představovat bezpečnostní i provozní riziko a zároveň komplikovat aktualizaci frameworků, knihoven, databází nebo infrastruktury.
PHP 5 upgrade přitom nemusí znamenat kompletní přepis aplikace. Nejprve je potřeba zjistit, jaký kód a které závislosti brání přechodu na podporovanou verzi PHP. Podle stavu aplikace pak lze připravit postupný upgrade, refactoring problematických částí nebo širší modernizaci systému.
Důležité je neřešit jen samotnou verzi PHP, ale i vše, co je na ni navázané.
Starý systém nemusí firmu brzdit navždy. Nejnebezpečnější je čekat naslepo.
Začněte Kontrolou rizik systému. Zjistíte, co je dnes největší problém, co vás opravdu brzdí a kde začít bezpečně.