techone --pruvodce=migrace-do-cloudu
Migrace do cloudu: kdy se vyplatí a jak ji postavit, aby cloud nebyl drahý
Cloud může být levný, pružný a bezpečný, nebo drahý, pomalý a přebujelý. Rozhoduje o tom jedna věc: kolik úsilí věnujete tomu, než cokoliv začnete stěhovat.
Aktualizováno:
Ve zkratce
- Hlavní rozhodnutí
- 6 R strategií: rehost, replatform, refactor, repurchase, retire, retain. Každá aplikace ve firmě patří do jedné z nich. Kdo to nerozhodne předem, utrácí zbytečně.
- Kdy Azure
- Když aplikace umí cloud-native funkce, potřebujete elastické škálování, compliance EU Data Boundary a integraci s Microsoft 365 nebo Dynamics 365.
- Kdy Hetzner
- Když potřebujete stálý vysoký výkon, velké databáze, předvídatelné náklady a aplikace, kterou nedává smysl přepisovat do cloud-native.
- Hybridní scénář
- Kombinace Azure a Hetzner je reálná volba: Azure pro elastické služby a compliance, Hetzner pro výpočetně náročné části a datová úložiště, kde by Azure cena rostla lineárně s objemem.
- Kolik to trvá
- Rehost malé aplikace: týdny. Replatform: 2-4 měsíce. Plný refactor monolitu do cloud-native: 6-12 měsíců u větších aplikací i déle, podle rozsahu.
Proč cloud migrace zklame, když se k ní přistupuje jako ke stěhování
Cloud se prodává jako úspora. Realita je, že většina firem, která migraci označí za "zklamání", si ji zklamala sama. Ne technologií, ale tím, že k ní přistoupila jako ke stěhování serverů, místo aby se na ni dívala jako na změnu architektury a provozního modelu.
Cloud má tři úrovně kvality. Čím výše se aplikace v této škále dostane, tím více z cloudu skutečně těží. A tím méně za něj platí, protože dobře napsaná cloud-native aplikace je násobně levnější než stejná funkcionalita běžící v režimu "jen jsme to tam přesunuli".
Úroveň 1: Lift-and-shift (cloud-hosted)
Aplikace běží v cloudu, ale neví o tom. Je to stará VM, která místo ve vašem datacentru běží v cloudovém datacentru. Získáváte pár provozních výhod (zálohy, dostupnost), ale platíte za infrastrukturu, kterou nevyužíváte. Hodí se jako přechodný krok, ne jako cíl.
Úroveň 2: Cloud-ready (replatform)
Aplikace byla upravena, aby používala spravované služby: App Service místo VM, Azure SQL místo vlastního SQL serveru, Azure Storage místo lokálního disku. Získáte automatické škálování a předvídatelné náklady. Stále to ale není cloud-native.
Úroveň 3: Cloud-native (refactor nebo rewrite)
Aplikace je navržená pro cloud: serverless, event-driven, horizontálně škálovatelná. Platíte jen za to, co skutečně využíváte. Tohle je místo, kde cloud dává smysl z ekonomického pohledu, ne jen z provozního.
Kde se dělají nejdražší chyby
Firma si koupí Azure, přestěhuje tam staré VM 1:1, vypne původní servery. Účet za cloud je 3x větší než dřív, nic se nezrychlilo a nic se neškáluje. Závěr: "cloud je drahý". Závěr je špatný. Chyba byla v přístupu, ne v cloudu.
6 R strategií: jak se rozhodnout u každé aplikace
Standardní framework pro migraci do cloudu se nazývá 6 R. Popisuje šest způsobů, jak s každou aplikací naložit. První krok dobré migrace není "vyberme si Azure regiony", ale rozřazení každé aplikace ve firmě do jedné z těchto kategorií. Některé aplikace patří do cloudu, některé ne. A některé má smysl zrušit úplně. Jak tohle vyhodnotíme v praxi popisuje naše služba migrace do cloudu.
Rehost (lift-and-shift)
Přesun aplikace do cloudu beze změny. Nejrychlejší, nejlevnější na implementaci, ale cloud přitom nevyužíváte. Má smysl jako dočasný krok, aby se vyprázdnilo datacentrum, nebo pro aplikace, u kterých víte, že je za rok nahradíte.
Replatform (lift-and-reshape)
Přesun s drobnými úpravami: vlastní SQL server nahradíte Azure SQL, vlastní webový server nahradíte App Service. Aplikace se nemusí přepisovat, získáváte managed služby, zálohy, škálování. Typický kompromis pro aplikace, které jsou v pořádku, ale nemá smysl je přepisovat.
Refactor (re-architect)
Přepsání aplikace tak, aby využila cloud naplno. Monolit se rozloží na služby, VM se nahradí kontejnery nebo serverless funkcemi, pevně propojené integrace se nahradí event-driven komunikací. Nejdražší volba, ale dlouhodobě nejlevnější provoz a nejvyšší hodnota.
Repurchase (nahrazení SaaS)
Místo stěhování staré aplikace se nahradí hotovou SaaS službou. Staré CRM nahradíte cloudovým CRM jako Dynamics 365 Sales. Vlastní účetnictví nahradíte cloudovým ERP. Vývoj odpadá, získáváte standardní funkcionalitu. Je to nejrychlejší cesta, pokud proces, který aplikace řeší, není vaše konkurenční výhoda.
Retire (vypnutí)
Audit obvykle ukáže, že 10-20 % aplikací v datacentru nikdo už nepoužívá, nebo jejich funkci pokrývá jiný systém. Nejlevnější migrace je ta, kterou nemusíte udělat. Vypnutí je plnohodnotný krok migrační strategie.
Retain (ponechat on-premise)
Některé aplikace do cloudu nepatří. Starší systémy s hardwarovou vazbou, aplikace s regulatorními omezeními, nebo systémy, kde by migrace stála víc, než kolik by ušetřila. Zůstávají tam, kde jsou, dokud jejich funkci nenahradí něco nového.
Kolik cloud skutečně stojí: úložiště, databáze, egress a ostatní bolavá místa
Ceník cloudu vypadá jednoduše, dokud nedorazí první faktura. Co dělá cloud drahým, není cena za CPU. Drahé je úložiště, drahá je spravovaná databáze a nejvíc drahý je datový provoz ven z cloudu. Kdo tyto tři věci neodhadne předem, překvapí ho účet.
Spravovaná databáze je 2-3x dražší než DB na VM
Azure SQL Database vás osvobodí od patchování a záloh, ale za stejný výkon platíte zhruba dvakrát až třikrát víc než za stejně dimenzovaný SQL Server na VM. Pro malé DB se to vyplatí. U velkých databází s nepřetržitým provozem roste cena rychle a bývá to obvykle největší jednotlivá položka na cloudové faktuře.
Egress: platíte za data, která jdou ven z cloudu
Data dovnitř cloudu jsou zdarma. Data ven stojí kolem 0,087 USD za GB. U analytiky, přesunů mezi regiony, záloh ven a veřejného webu se to sčítá rychle. Jeden noční export do BI systému může zdvojnásobit měsíční účet.
Úložiště má skryté poplatky za operace a stahování
Azure Blob Storage účtuje zvlášť uložení a zvlášť operace (LIST, GET, PUT). Noční skript, který prochází všechny bloby, může stát víc než samotné úložiště. Archivní úroveň je levná na uložení, ale drahá při stahování dat a má minimální retenci: předčasné smazání nebo přesun se penalizuje.
Soft delete a snapshoty tiše rostou
Soft delete a pravidelné snapshoty chrání data, ale zabírají úložiště navíc. Bez kontroly nastavení a retence umí zdvojnásobit nebo ztrojnásobit účet za úložiště, aniž by se změnilo cokoliv v datech.
Tyto náklady nejsou skryté ve zlém smyslu. Jsou dokumentované. Ale málokdo je čte předem a málokdo je promítá do kalkulace ROI. Proto se migrace opakovaně pouští s očekáváním, které realita nemůže naplnit.
Azure, Hetzner, nebo hybrid: co vybrat podle toho, co potřebujete
Cloud není jedna věc. Azure a Hetzner řeší každý jinou úlohu a nejlepší architektury je často kombinují. Rozhodnutí nestojí na tom, co je "moderní", ale na tom, co vaše aplikace opravdu potřebuje a jak jsou navržené.
Pravidlem, kterým se řídíme, je: elastické a prudce škálující služby patří do Azure, AWS nebo Google Cloud. Výpočetně stálé a datově intenzivní části patří tam, kde za ně nebudete platit jako za prémiové cloudové služby, pokud je umíte spravovat sami. Pro druhé jsou Hetzner a podobní provideři výrazně levnější. Medicalface takhle provozujeme a obě strany dlouhodobě spravujeme. Jak taková pravidelná správa cloudu a serverů vypadá, popisuje průvodce správou cloudu a serveru.
Azure, když potřebujete cloud-native
Aplikace, která umí App Service, Functions, Cosmos DB, Event Grid, Service Bus. Potřebujete elastické škálování podle zátěže, globální dostupnost, integraci s Microsoft 365 nebo Dynamics 365, a compliance pokrytou EU Data Boundary. Pro tento profil je Azure nejen nejlepší, ale často jediná rozumná volba.
Hetzner, když platíte za výkon, ne za elasticitu
Aplikace, která potřebuje silný a stálý výkon: velké databáze, výpočetně náročné zpracování, datová úložiště s velkými objemy. Hetzner EX44 má 64 GB RAM, 14 jader a za srovnatelný výkon v Azure zaplatíte násobně víc. Pokud tu aplikaci nedává smysl přepisovat do cloud-native, Hetzner je racionální volba.
Hybrid: Azure pro frontend, Hetzner pro datové úložiště
Praktická kombinace pro firmy, které mají velká data, ale zároveň potřebují elastický frontend. Webová aplikace běží v Azure App Service, uživatelé přistupují přes CDN, autentizace jde přes Entra ID. Datové úložiště a analytická databáze jsou na Hetzneru, kde za stejný výkon platíte zlomek. Propojení přes VPN.
Kdy cloud není správná volba
Legacy aplikace, kterou nedává smysl přepisovat, běží na stabilním hardware a provoz je předvídatelný. Migrace by stála víc, než kolik ušetří. V tomto případě je retain validní strategií. Do cloudu nepatří všechno.
Pro koho má migrace smysl a pro koho zatím ne
Ne každá firma potřebuje migraci do cloudu hned. Tady jsou situace, kdy je to správný krok, a kdy dává smysl počkat.
Dobrý kandidát
- Datacentrum nebo serverovna dochází kapacitou
- Rozsáhlá legacy aplikace, která brání dalšímu růstu
- Potřeba globální dostupnosti nebo elastického škálování
- Compliance požadavky, které on-premise nepokryje
- Migrace na nový ERP, který je stejně v cloudu
- Po fúzi nebo akvizici se sjednocuje infrastruktura
Zatím ne
- On-premise funguje, náklady jsou předvídatelné
- Aplikace jsou staré a nedává smysl je přepisovat
- Tým nemá kapacitu na projekt vedle běžného provozu
- Chybí stabilní vedení projektu po straně klienta
| Strategie | Typická situace | Výsledek |
|---|---|---|
| Rehost | Potřebujete vyprázdnit datacentrum rychle | Aplikace v cloudu, žádné provozní zlepšení |
| Replatform | Aplikace je funkční, ale chcete managed služby | Auto-scaling, zálohy, patchování zahrnuty |
| Refactor | Monolit, který brání růstu, hodnotná část byznysu | Cloud-native provoz, dlouhodobá úspora |
| Repurchase | Proces není konkurenční výhoda | Nahrazeno SaaS, žádný vlastní vývoj |
| Retire | Aplikaci nikdo nepoužívá nebo je duplicitní | Vypnuto, nulové provozní náklady |
| Retain | Regulatorní nebo hardwarové omezení | Zůstává on-premise, migruje se až bude třeba |
posuňte pro zobrazení celé tabulky
Často kladené otázky
Jak dlouho trvá migrace do cloudu?
Záleží na rozsahu a strategii. Rehost malé aplikace trvá týdny. Replatform středně velké aplikace 2-4 měsíce. Plný refactor monolitu do cloud-native běžně 6-12 měsíců a u větších aplikací i déle. Pro Helvetii jsme přepisovali rozsáhlou desktopovou VB6 aplikaci do .NET Azure a dělali jsme na tom přes rok. Nejčastější chyba je plánovat podle časového plánu pro rehost a pak zjistit, že replatform nebo refactor zabere násobně víc.
Bude cloud levnější než náš současný on-premise?
Může být i nemusí. Lift-and-shift obvykle nevede k úspoře, často naopak. Skutečná úspora přichází s replatformem a refactorem, kde aplikace využívají managed služby a platíte za skutečné využití. Spolu s odstraněním režie na správu hardware a fakturu za elektřinu se cloud vyplatí po 12-24 měsících, pokud je dobře postavený.
Proč je cloud drahý na storage a databáze?
Spravované služby jsou násobně dražší než vlastní správa. Azure SQL Database stojí 2-3x víc než SQL Server na VM, Azure Blob Storage na prémiové úrovni stojí kolem 0,115 USD/GB měsíčně a egress ven stojí cca 0,087 USD/GB. Pro velká data a velké databáze to je významná položka. Řešením je buď cloud-native architektura (cache, CDN, tiering), hybridní scénář s Hetznerem pro úložiště, nebo zvážit, jestli vůbec migrovat.
Dává smysl kombinovat Azure a Hetzner?
Ano, a u některých projektů je to optimální. Azure poskytuje cloud-native služby, compliance a integraci. Hetzner poskytuje výkon za zlomek ceny, pokud ho umíte spravovat. Typický hybridní scénář: Azure App Service nebo Functions pro frontend a API, Azure Entra ID pro autentizaci, databáze a velká úložiště na Hetzneru. Propojení přes VPN. Vyžaduje to zkušený DevOps tým, ale ekonomicky to často dává smysl.
Co znamená cloud-native versus cloud-hosted?
Cloud-hosted aplikace běží v cloudu, ale neví o tom. Je to stará aplikace na virtuálním serveru. Cloud-native aplikace je navržená pro cloud od začátku: používá serverless, event-driven komunikaci, managed databáze, horizontální škálování. Platíte jen za to, co skutečně využíváte. Rozdíl v nákladech mezi cloud-hosted a cloud-native může být pětinásobný i víc při stejné funkcionalitě.
Jak řešit EU Data Boundary a GDPR v Azure?
Microsoft dokončil EU Data Boundary v únoru 2025 (oficiální Microsoft oznámení). Zákaznická data, diagnostická data i servisní data zůstávají v EU regionech. Pro GDPR compliance je to stěžejní. Při migraci je klíčové vybrat správný region (typicky West Europe nebo North Europe) a nastavit data residency u všech služeb. U některých služeb, typicky AI a analytics, je potřeba ověřit, co se děje mimo EU. Tohle je zároveň klíčová výhoda Azure oproti AWS a Google Cloud pro evropský enterprise segment.
Jaké máte reference na velké cloud migrace?
Naše nejrozsáhlejší cloud migrace byla Helvetia: desktopová VB6 aplikace přepsaná do .NET a nasazená do Azure. Byl to plný refactor (přepis), nikoliv lift-and-shift, a pracovali jsme na něm přes rok. Aplikace běží v Azure řadu let a my ji spravujeme dál. Menší migrace a hybridní nasazení na Azure a Hetzner řešíme průběžně u klientů s produkčními systémy. Pro dlouhodobý provoz cloudu po migraci viz průvodce správou cloudu a serveru.
Kam dál
Správa cloudu a serveru
Jak vypadá dlouhodobá profylaxe infrastruktury po migraci. Monitoring, zálohy, bezpečnostní záplaty.
IT partner pro mezinárodní firmy
Audit a převzetí cloudové implementace, Azure pro pobočkové firmy, compliance napříč trhy.
Proč Dynamics 365 BC
Srovnání ERP systémů, cenový rozbor a rozhodovací matice.
Nevíte, kterou cestou jít?
Projdeme s vámi aplikace ve firmě a řekneme, co patří do cloudu a co ne.
Nezávazná konzultace