techone --pruvodce=migrace-do-cloudu
Migrace do cloudu: kdy dává smysl a co rozhoduje o výsledku
Samotný přesun serverů úsporu nezaručí. Předem je potřeba porovnat architekturu, provoz, bezpečnost a celkové náklady.
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. Tato rozhodnutí zpřesní rozsah, rizika a odhad nákladů.
- Kdy Azure
- Azure dává smysl zvážit, když potřebujete cloud-native služby, elastické škálování nebo integraci s Microsoft 365 či Dynamics 365. Data residency a compliance se ověřují pro konkrétní služby a architekturu.
- Kdy vlastní servery
- Vlastní nebo vyhrazená infrastruktura může vyjít lépe u stálé zátěže či zvláštních požadavků na hardware, latenci a kontrolu provozu. Rozhoduje srovnání celkových nákladů a schopností týmu.
- Hybridní scénář
- Kombinace cloudu a vlastních serverů může být vhodná: cloud pro elastické služby a integrace, vyhrazené servery pro stálou zátěž. Rozhoduje TCO, bezpečnost, latence a provozní schopnosti týmu.
- Jak určit termín
- Délku nelze spolehlivě určit jen podle zvolené strategie. Závisí na počtu aplikací a integrací, kompatibilitě, objemu dat, požadavcích na odstávku, testování a připravenosti provozu.
Proč migrace do cloudu selže, když se řeší jen jako stěhování
Cloud se často prodává jako úspora, samotný přesun serverů ji ale nezaručí. Výsledek závisí na architektuře aplikace, provozním modelu a průběžném řízení nákladů.
Následující tři přístupy pomáhají popsat rozsah změny. Nejsou žebříčkem kvality: vhodná varianta se vybírá podle požadavků, rizik a celkových nákladů.
Přesun 1:1 (cloud-hosted)
Aplikace se přesune na cloudovou infrastrukturu bez zásadní změny architektury. Dostupnost, zálohování ani obnova tím nevzniknou automaticky; musí být navržené a placené podle požadavků. Přesun může být dočasným krokem i dlouhodobým řešením, pokud jeho provozní a finanční model vychází.
Využití spravovaných služeb (replatform)
Část infrastruktury nahradí spravované služby, například webová platforma, databáze nebo objektové úložiště. Mohou zjednodušit některé provozní úkoly, jejich rozsah ale závisí na konkrétní službě, úrovni a nastavení. Úpravy kompatibility mohou být malé i podstatné.
Změna architektury (refactor nebo nový vývoj)
Aplikace je navržená pro cloud: může používat serverless, událostmi řízenou komunikaci a horizontální škálování. Spotřební model lépe kopíruje proměnlivou zátěž, ale cenu ovlivňuje architektura, minimální kapacity i datové přenosy. Cloud-native není podmínkou pro AI služby; přes zabezpečené API je může využívat také hostovaná aplikace nebo aplikace ve vlastní infrastruktuře. Více v průvodci automatizací dokumentů.
Riziko přesunu bez provozního návrhu
Pokud se virtuální stroje pouze přesunou a nikdo předem nenavrhne jejich velikost, dostupnost, zálohy a řízení nákladů, může nový provoz stát víc bez odpovídajícího přínosu. Problém pak není samotný cloud, ale chybějící návrh a následná správa.
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 to v praxi vyhodnocujeme, popisuje služba migrace do cloudu.
Přesun 1:1 (rehost)
Přesun aplikace na cloudovou infrastrukturu bez zásadní změny. Často omezuje zásah do aplikace, není však automaticky nejrychlejší ani nejlevnější: kompatibilitu, síť, zabezpečení a provoz je stále nutné vyřešit. Hodí se například při ukončení datacentra nebo jako mezikrok před náhradou systému.
Replatform (lift-and-reshape)
Přesun s využitím vybraných spravovaných služeb, například databáze nebo webové platformy. Rozsah úprav určí kompatibilita aplikace. Zálohy, dostupnost a škálování se řídí možnostmi zvolené služby, úrovní a konfigurací; nejsou automatickou vlastností každého nasazení.
Refactor (re-architect)
Úprava architektury tak, aby aplikace využila vybrané cloudové služby. Monolit lze rozdělit na služby, VM nahradit kontejnery nebo serverless funkcemi a některé integrace převést na event-driven komunikaci. Je to náročnější varianta; její přínos a provozní náklady je potřeba ověřit proti ceně změny.
Repurchase (nahrazení SaaS)
Místo stěhování staré aplikace se vybere služba SaaS, například nové CRM nebo ERP. Odpadne vývoj samotného základu produktu, obvykle ale zůstává konfigurace, migrace dat, integrace a řízení změny. Smysl dává, pokud dostupný produkt splní procesní i ekonomické požadavky.
Retire (vypnutí)
Audit může odhalit nepoužívané nebo duplicitní aplikace. Rozsah je potřeba ověřit z inventáře, provozních dat a s vlastníky systémů. Bezpečné vyřazení takové aplikace je plnohodnotný krok migrační strategie.
Retain (ponechat v současném prostředí)
Důvodem může být vazba na hardware, regulatorní omezení, latence nebo nepřiměřené náklady na změnu. Ponechání systému je legitimní strategie, pokud jsou zároveň vyřešené jeho podpora, bezpečnost a návaznosti na migrované aplikace.
Z čeho se skládají cloudové náklady
Náklady cloudu nejsou jen cena za výpočetní výkon. Podle architektury do nich vstupují databáze, úložiště, síťový provoz, dostupnost, zálohy, licence, monitoring, podpora i práce provozního týmu. Kalkulace proto musí vycházet z konkrétní zátěže a požadované úrovně služby.
Spravovaná databáze: kdy má smysl
Spravovaná databáze může převzít část patchování, zálohování a zajištění dostupnosti. Přesný rozsah odpovědnosti i obnovitelnost dat závisí na službě, úrovni a nastavení. Volbu nelze odvodit jen z velikosti databáze; porovnáváme požadované SLA, kompetence týmu a celkové náklady.
Egress: data jdoucí ven z cloudu
Poskytovatelé často účtují především data odcházející z cloudu, ale ceny se liší podle služby, směru a regionu. Analytiku, přesuny mezi regiony, zálohy i veřejný provoz je proto potřeba promítnout do konkrétní kalkulace.
Úložiště: poplatky za operace a stahování
Objektová úložiště mohou účtovat uložený objem, operace a přenosy odlišně podle služby a úrovně. Archivní vrstvy mívají delší dobu obnovy, minimální dobu uložení nebo poplatky za přístup. Konkrétní pravidla je nutné ověřit v aktuálním ceníku poskytovatele.
Soft delete a snapshoty tiše rostou
Soft delete a pravidelné snapshoty chrání data, ale zabírají úložiště navíc. Dopad na účet závisí na objemu změn, frekvenci a retenci, proto je vhodné jej předem spočítat v cenové kalkulaci poskytovatele.
Ceník je jen vstup. Před migrací je potřeba vytvořit model zátěže, ověřit jej kalkulačkou poskytovatele a po spuštění nastavit rozpočty, upozornění a pravidelnou kontrolu skutečné spotřeby.
Cloud, vlastní servery, nebo hybrid: co vybrat podle toho, co potřebujete
Cloud není jedna služba ani jeden provozní model. Veřejný cloud, vyhrazené servery i vlastní infrastruktura mají jiné náklady a odpovědnosti; lze je také kombinovat. Rozhodnutí má vycházet z potřeb aplikace, ne z toho, která varianta působí moderněji.
U proměnlivé zátěže porovnáváme výhody elastických služeb v Azure, AWS nebo Google Cloud. U stálé výpočetní a datové zátěže může být ekonomičtější vyhrazený server, pokud tým započítá správu, dostupnost, zálohování a obnovu. Rozhodnutí proto stavíme na celkových nákladech, požadovaném SLA a rizicích. Jak pravidelná správa obou prostředí vypadá, popisuje průvodce správou cloudu a serveru.
Azure, když potřebujete cloud-native
Azure je silný kandidát, pokud aplikace využije App Service, Functions, Cosmos DB, Event Grid nebo Service Bus a potřebuje elastické škálování či integraci s Microsoft 365 nebo Dynamics 365. Požadavky na compliance a data residency je nutné posoudit pro konkrétní služby a porovnat i s alternativami.
Vyhrazený server, když platíte za výkon, ne za elasticitu
U stálé výpočetní nebo datové zátěže může pevná konfigurace přinést předvídatelnější účet. Do porovnání ale patří také licence, konektivita, energie, obnova, dohled, náhradní kapacita a práce týmu. Výsledek proto ověřujeme výpočtem celkových nákladů.
Hybrid: Azure pro frontend, vyhrazený server pro datové úložiště
Možná kombinace pro firmy, které mají velká data a zároveň potřebují elastický frontend. Webová aplikace může běžet v Azure App Service, autentizace přes Entra ID a datová vrstva na vyhrazeném serveru propojeném přes VPN. Ekonomiku ovlivní egress, latence, dostupnost i náklady na správu.
Kdy cloud není správná volba
Starší aplikace, kterou nedává smysl přepisovat, běží na stabilním hardwaru a její provoz je předvídatelný. Pokud by migrace stála víc, než může přinést, je ponechání v současném prostředí legitimní variantou. 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í
- Dostupná cloudová služba, region a certifikace lépe odpovídají požadovaným kontrolám
- 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 omezit zásah do aplikace nebo ukončit datacentrum | Stejná aplikace na nové infrastruktuře; provozní opatření se navrhují zvlášť |
| Replatform | Aplikace může využít vybrané spravované služby | Část provozu přebírá poskytovatel v rozsahu zvolené služby a konfigurace |
| Refactor | Současná architektura omezuje požadované změny nebo provoz | Upravená architektura s přínosy a náklady, které je nutné ověřit |
| Repurchase | Dostupná služba SaaS splní procesní požadavky | Nový produkt, konfigurace, migrace dat a integrace |
| Retire | Aplikaci nikdo nepoužívá nebo je duplicitní | Řízené vypnutí včetně archivace a retenčních povinností |
| Retain | Regulatorní nebo hardwarové omezení | Zůstává v současném prostředí a další postup se znovu posoudí podle potřeby |
posuňte pro zobrazení celé tabulky
Často kladené otázky
Jak dlouho trvá migrace do cloudu?
Termín stanovujeme podle inventáře aplikací a integrací, kompatibility, objemu dat, požadované odstávky, bezpečnostních kontrol a rozsahu testování. U Helvetie trval přepis rozsáhlé desktopové aplikace ve VB6 do .NET a její migrace do Azure 18 měsíců; nejde však o obecný odhad pro jiný projekt.
Bude cloud levnější než provoz ve vlastní infrastruktuře?
Může být i nemusí. Přesun 1:1 sám o sobě úsporu nezaručuje. Replatform nebo refactor mohou změnit provozní náklady, ale je potřeba porovnat celé TCO: vývoj, licence, infrastrukturu, správu, dostupnost, datové přenosy i ukončení služby.
Proč mohou být databáze a úložiště v cloudu drahé?
Cena se může skládat z rezervované kapacity či spotřeby, dostupnosti, záloh, uloženého objemu, počtu operací a datových přenosů. U velké nebo nevhodně navržené zátěže mohou tyto položky převážit. Řešením není automaticky přepis aplikace ani hybrid; nejprve je potřeba změřit zátěž a porovnat varianty včetně nákladů na správu.
Dává smysl kombinovat cloud a vlastní servery?
Ano. Hybrid může dávat smysl, když jedna část řešení potřebuje elasticitu či cloudové integrace a jiná má stálou výpočetní nebo datovou zátěž. O výsledku rozhoduje celkové TCO, egress, latence, dostupnost, bezpečnost a schopnost obě prostředí spravovat.
Co znamená cloud-native versus cloud-hosted?
Cloud-hosted aplikace běží na cloudové infrastruktuře bez zásadní změny architektury. Cloud-native aplikace je navržená pro využití cloudových služeb, například serverless, event-driven komunikace, spravovaných databází nebo horizontálního škálování. Neznamená to automaticky nižší cenu; obě varianty je potřeba porovnat podle konkrétní zátěže a provozního modelu.
Jak řešit EU Data Boundary a GDPR v Azure?
Microsoft dokončil hlavní fáze EU Data Boundary v únoru 2025 (viz oficiální dokumentace Microsoft Learn). Nejde ale o automatickou GDPR shodu celé architektury. U každé použité služby je potřeba ověřit region, podmínky zpracování, případné výjimky a datové toky; zvláštní pozornost vyžadují globální, AI a analytické služby.
Jaké máte reference na rozsáhlejší migrace do cloudu?
Naší nejrozsáhlejší migrací do cloudu je Helvetia: desktopová aplikace ve VB6 přepsaná do .NET a nasazená do Azure pro 7 evropských trhů. Přepis a migrace trvaly 18 měsíců. Po nasazení jsme přešli do dlouhodobé podpory a rozvoje; celková spolupráce trvá přes 3 roky a pokračuje. Dlouhodobý provoz cloudu po migraci řeší průvodce správou cloudu a serveru.
Nevíte, kterou cestou jít?
Projdeme vaše aplikace a navrhneme, které varianty stojí za technické a ekonomické ověření.
Nezávazná konzultace