--- title: "Migrace stovek starších aplikací do AWS bez zadrhnutí" description: "Praktická metoda, jak přesunout stovky starších aplikací z virtuálních strojů do AWS: inventura, upgrade či přestavba, týmy po blocích, přepnutí a návrat zpět." canonical: https://sdk.enterprises/cs/insights/migrating-hundreds-of-apps-to-aws language: cs --- # Migrace stovek starších aplikací do AWS bez zadrhnutí Aktualizováno: 2026-09-25 > Migrace stovek starších aplikací z virtuálních strojů (VM) do AWS funguje, když ji vedete jako výrobní linku, a ne jako stovky samostatných projektů: každou aplikaci zinventarizujte a zařaďte, u každé rozhodněte o upgradu nebo přestavbě a celé portfolio rozdělte do bloků, které vlastní malé týmy. Sdílená kostra aplikace, otestované kroky pro přepnutí a návrat zpět a provozní postupy (runbooky), podle kterých může pracovat kterýkoli tým, udrží stálou kvalitu i s rostoucím objemem. ## Začněte inventurou, která ukáže, co každá aplikace skutečně potřebuje Než se kdokoli dotkne AWS, sepište všechny aplikace běžící na starých VM a zaznamenejte fakta, která určují náročnost migrace. Na začátek stačí sdílená tabulka. Důležité je, aby každá aplikace měla řádek, vlastníka a stejné sloupce. Pak každou aplikaci zařaďte do jedné z několika málo cest, například upgrade, přestavba a vyřazení. Týmy pak mohou plánovat podle cest, místo aby o každé aplikaci debatovaly od nuly. - Verze běhového prostředí a frameworku, s označením všeho, co je po konci podpory - Databáze, sdílená úložiště souborů a plánované úlohy, na kterých aplikace závisí - Příchozí a odchozí integrace, včetně natvrdo zapsaných názvů hostitelů a IP adres - Způsob autentizace a všechny tajné klíče uložené na VM - Obchodní vlastník, míra využívání a přijatelné okno odstávky ## O upgradu, nebo přestavbě rozhodujte u každé aplikace zvlášť, ne jednou za celý program Na stovky aplikací nesedí jediná strategie. Některým stačí upgrade frameworku, vyčlenění konfigurace a nový cíl nasazení. Jiné nesou tolik mrtvého kódu nebo zamotané struktury, že přestavba na čistém základu je rychlejší než oprava. Rozhodujte podle sepsaných kritérií, aby různé týmy došly ke stejné odpovědi. Užitečné pravidlo: pokud převedení aplikace na standardní kostru stejně znamená přepsat většinu jejích controllerů a přístupu k datům, přestavte ji. Pokud se obchodní logika dá převést z větší části beze změny, upgradujte ji. Program Crédit Agricole, který přesunul 600+ interních aplikací ze starých VM do AWS, použil obě cesty. Aplikace byly přestavěny na interní kostře banky v CodeIgniteru, některé upgradem, jiné od nuly. - Upgrade, když je kód čitelný, jeho chování jasné a rozdíl ve verzích frameworku malý - Přestavba, když je obchodní logika všude promíchaná s prezentační vrstvou nebo aplikace závisí na odstraněných funkcích jazyka - Vyřazení, když je využití téměř nulové a obchodní vlastník souhlasí, protože nejlevnější migrace je ta, kterou vynecháte ## Rozdělte portfolio do bloků a každý blok svěřte jednomu týmu V tomto měřítku se jediný centrální tým stane úzkým hrdlem. Model rozdělení do bloků přiděluje dávku souvisejících aplikací jednomu malému týmu, který je vlastní od analýzy až po přepnutí. Bloky seskupujte podle sdílených závislostí, ne podle abecedy. Aplikace, které sdílejí databázi nebo se navzájem volají, by se měly stěhovat společně, jinak se stejná integrační práce opakuje v několika týmech. Bloky také dělají postup měřitelným. Každý tým hlásí u každé aplikace stejné stavy, například analyzováno, migrováno, otestováno, přepnuto a vyřazeno z provozu, a přehled programu je součtem těchto stavů. Tak běžel program Crédit Agricole a SDK Enterprises v něm jako součást programového týmu dodalo 50+ migrací aplikací. ## Postavte jednu standardní kostru a každou aplikaci na ni převeďte Standardní kostra aplikace je to, co ze stovek migrací dělá opakovatelný proces. Fixuje rozhodnutí, která by se neměla dělat znovu u každé aplikace: strukturu adresářů, konfiguraci z proměnných prostředí, formát logů, health checky, napojení na autentizaci a pipeline nasazení. Každá migrovaná aplikace se pak liší jen svou obchodní logikou. Revidující vědí, kam se dívat, provozní týmy dostávají jednotné logy a alarmy a oprava v kostře se dostane do každé aplikace, která na ní stojí. Kostru udržujte malou a verzovanou. Pokud přeroste ve vlastní framework, týmy ji začnou obcházet. ## Přepnutí a návrat zpět naplánujte před první migrací Každá aplikace potřebuje plán přepnutí, který říká, jak se přesune provoz, jak se přesunou data a jak se vrátit zpět. Rozhodněte o tom dřív, než se přesune první aplikace. Improvizovaný návrat zpět uprostřed incidentu je přesně to, čím migrační programy ztrácejí důvěru byznysu. - Okno zmrazení: s obchodním vlastníkem se dohodněte, od kdy se na starém VM přestanou dělat změny - Synchronizace dat: data migrujte předem a v okně přepnutí proveďte závěrečnou rozdílovou synchronizaci - Přepnutí provozu: změňte směrování v DNS nebo v load balanceru, s nízkými DNS TTL nastavenými několik dní předem - Smoke testy: krátká skriptovaná kontrola přihlášení, klíčových obrazovek a integrací hned po přepnutí - Spouštěč návratu zpět: jmenovitě určená osoba a sepsané podmínky pro přepnutí zpět - Starý VM ponechaný: zastavte ho, ale nemažte, dokud aplikace dohodnutou dobu nepoběží v AWS bez problémů ## Pište runbooky, podle kterých může kterýkoli tým pracovat od prvního dne Runbook je kontrolní seznam pro jednu opakovatelnou operaci: přípravu aplikace, její přepnutí, návrat zpět, vyřazení VM. Každý napište jednou, otestujte ho na prvních několika aplikacích a aktualizujte ho pokaždé, když tým něco překvapí. Dobré runbooky jmenují příkazy, odpovědné osoby a očekávané výsledky, ne záměry. „Zkontrolovat, že aplikace funguje“ není krok. „Přihlásit se jako testovací uživatel a ověřit, že dashboard načte data účtu“ krokem je. Runbooky jsou také cestou, jak se inženýři, kteří nastoupí uprostřed programu, rychle zapracují. Specialista, který přijde v šestém týdnu, by měl po jednom společném sezení dokázat přepnout aplikaci podle dokumentů. ## Kde má ve velké migraci místo externí tým Velké programy často potřebují na vymezenou dobu kapacitu navíc, aniž by předávaly kontrolu. V rámci větších programů přebíráme migrační bloky a pracujeme na kostře, runboocích a nástrojích klienta, s našimi inženýry a prověřenými freelance specialisty v rámci jedné smlouvy. ## Hlavní body - Než začnete migrovat, zinventarizujte a zařaďte všechny aplikace, aby se práce dala plánovat podle cest. - O upgradu, přestavbě nebo vyřazení rozhodujte u každé aplikace podle sepsaných kritérií, která každý tým uplatňuje stejně. - Rozdělte portfolio do bloků souvisejících aplikací, z nichž každý od začátku do konce vlastní jeden malý tým. - Malá, verzovaná kostra aplikace dělá stovky migrací jednotnými a snadno revidovatelnými. - Nikdy nepřepínejte aplikaci bez otestované cesty zpět a bez starého VM, který je stále k dispozici. ## Časté dotazy ### Jak dlouho trvá migrace stovek aplikací do AWS? Záleží na počtu aplikací, podílu těch, které potřebují přestavbu, počtu souběžných týmů a oknech pro přepnutí, která byznys přijme. Odhadujte až po zařazení: změřte čas u několika aplikací z každé cesty, vynásobte velikostí každé cesty a vydělte kapacitou týmů. ### Máme starší aplikace nejdřív přesunout metodou lift and shift a modernizovat později? Lift and shift je nejrychlejší, když aplikace už běží na podporovaném běhovém prostředí a cílem je opustit datové centrum. U aplikací na běhových prostředích po konci podpory jejich přesun beze změny přenese stará rizika na novou platformu, takže upgrade nebo přestavba během přesunu vyjde celkově často levněji. ### Co je migrace rozdělená do bloků? Migrace rozdělená do bloků dělí velké portfolio aplikací na dávky souvisejících aplikací a každou dávku přiděluje jednomu týmu, který ji vlastní od analýzy až po přepnutí. Odstraňuje centrální úzké hrdlo a usnadňuje sledování postupu napříč mnoha týmy. ## Související služby - [Migrace do cloudu](https://sdk.enterprises/cs/services/cloud-infrastructure)