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ý a pružný, nebo drahý a pomalý. Rozhoduje příprava před migrací.
Ve zkratce
- Hlavní rozhodnutí
- Každá aplikace potřebuje vlastní rozhodnutí: přesunout 1:1, přepsat, vyměnit za hotové řešení, nebo nestěhovat. Bez tohohle rozhodnutí migrace 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 vlastní servery
- 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 cloudu a vlastních serverů je reálná volba: Azure pro elastické služby a compliance, dedicated servery 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ěží. Dobře napsaná cloud-native aplikace má výrazně lepší ekonomiku provozu než stejná funkcionalita běžící v režimu "jen jsme to tam přesunuli".
Úroveň 1: Přesun 1:1 (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. Cloud-native foundation je zároveň podmínka pro AI služby a automatizaci, detail v průvodci automatizací dokumentů.
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 vyšší než dřív, nic se nezrychlilo a nic se neškáluje. Závěr: "cloud je drahý". Ve skutečnosti chyba leží v přístupu k migraci.
Jak se rozhodnout u každé aplikace
První krok dobré migrace není "vyberme si Azure regiony", ale rozhodnutí, co s každou aplikací udělat. Některé patří do cloudu 1:1, jiné potřebují přepis, některé vyměnit za hotové řešení a některé nestěhovat vůbec. Jak tohle vyhodnotíme v praxi popisuje naše služba migrace do cloudu.
Přesun 1:1 (rehost)
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á, dostanete hotovou 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.
Z čeho se skládají cloudové náklady
Náklady cloudu nejsou jen cena za CPU. Hlavní položky bývají úložiště, spravovaná databáze a datový provoz ven. Kdo si tyto tři věci spočítá předem, má reálnou kalkulaci.
Spravovaná databáze: kdy má smysl
Spravovaná databáze (Azure SQL, RDS) přebírá patchování, zálohy a high availability. Pro menší databáze a týmy bez DBA dává smysl. Pro větší databáze s nepřetržitým provozem stojí za úvahu, zda správu řešit interně.
Egress: data jdoucí ven z cloudu
Data dovnitř cloudu jsou zdarma, data ven se účtují per GB. U analytiky, přesunů mezi regiony, záloh ven a veřejného webu se to sčítá. Pravidelný export do BI nebo zálohy do externího úložiště je položka, která se vyplatí promítnout do kalkulace.
Úložiště: poplatky za operace a stahování
Object storage (Azure Blob, S3) účtuje zvlášť uložení a operace (LIST, GET, PUT). Skripty, které procházejí všechny objekty, generují operace navíc. Archivní úroveň je vhodná pro long-term retention, ale má minimální retenci a poplatky za přístup.
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.
Cloud, vlastní servery, nebo hybrid: co vybrat podle toho, co potřebujete
Cloud není jedna věc. Cloud a vyhrazené servery ř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 provideři vyhrazených serverů 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.
Vyhrazený server, 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. Vyhrazený server s pevnou konfigurací dává předvídatelné náklady bez ohledu na využití. Pokud tu aplikaci nedává smysl přepisovat do cloud-native, vyhrazený server je racionální volba.
Hybrid: Azure pro frontend, vyhrazený server 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 vlastním serveru, kde za stejný výkon platíte zlomek. Propojení přes VPN.
Kdy cloud není správná volba
Starší 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á starší 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 firmy | 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í. Přesun 1:1 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í, pokud je dobře postavený.
Proč je cloud drahý na storage a databáze?
Hlavní cenové driver bývají spravované databáze, object storage a egress (data jdoucí ven z cloudu). Pro velká data a velké databáze to může být největší položka cloudové faktury. Řešením je buď cloud-native architektura (cache, CDN, tiering), hybridní scénář s vlastním serverem pro úložiště, nebo posouzení, zda migrace vůbec dává smysl.
Dává smysl kombinovat cloud a vlastní servery?
Ano, a u některých projektů je to optimální. Cloud poskytuje elastické služby, compliance a integraci. Vlastní servery poskytují výkon za zlomek ceny, pokud je 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 vlastním serveru. 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 bývá výrazný při stejné funkcionalitě.
Jak řešit EU Data Boundary a GDPR v Azure?
Microsoft dokončil EU Data Boundary v únoru 2025 (viz oficiální dokumentace Microsoft Learn). 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. EU Data Boundary v Azure je významný faktor pro GDPR-citlivé workloady.
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ý přepis aplikace, nikoliv prostý přesun 1:1, 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í (cloud plus vlastní servery) řešíme průběžně u klientů s produkčními systémy. Dlouhodobý provoz cloudu po migraci řeší průvodce správou cloudu a serveru.
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