techone --pruvodce=migrace-do-cloudu
Jak naplánovat migraci do cloudu
Nejdřív posoudíme provoz, data a závislosti každé aplikace. Podle výsledku určíme, co přesunout, upravit, přepsat, nahradit nebo ponechat v současném prostředí.
Ve zkratce
- Hlavní rozhodnutí
- U každé aplikace je potřeba rozhodnout, zda ji přesunout 1:1, upravit, přepsat, nahradit hotovým řešením, nebo ponechat na místě. Tím se zpřesní rozsah, rizika i odhad nákladů.
- Kdy Azure
- Azure má smysl prověřit, pokud aplikace využije spravované cloudové služby, pružné škálování nebo integraci s Microsoft 365 či Dynamics 365. Umístění dat a regulatorní požadavky se posuzují 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
- Termín určuje počet aplikací a integrací, jejich kompatibilita, objem dat, přijatelná odstávka, rozsah testování a připravenost provozu.
Co se může při migraci skutečně změnit
Rozsah migrace může sahat od změny provozního prostředí po přepis nebo nahrazení celé aplikace. Vhodnou variantu určuje její současný provoz, data, závislosti a důvod plánované změny.
Rozsah technické změny lze rozdělit do tří úrovní. Pro každou aplikaci může být vhodná jiná.
Přesun 1:1 (cloud-hosted)
Aplikace se přesune na cloudovou infrastrukturu bez zásadní změny architektury. Dostupnost, zálohování a obnovu je potřeba samostatně navrhnout a zahrnout do nákladů. Přesun může být dočasným krokem i dlouhodobým řešením, pokud dává provozní a ekonomický smysl.
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, konkrétní rozsah ale závisí na službě, zvoleném tarifu a nastavení. Úpravy kompatibility mohou být malé i podstatné.
Změna architektury (refactor nebo nový vývoj)
Aplikace se upraví pro využití cloudových služeb, například bezserverových funkcí, komunikace založené na událostech nebo horizontálního škálování. Účtování podle spotřeby může být výhodné u proměnlivé zátěže, cenu však ovlivňuje také architektura, minimální kapacity a datové přenosy.
Provozní návrh je součástí migrace
Cílové prostředí potřebuje předem navrženou kapacitu, dostupnost, zálohy, obnovu a řízení nákladů. Bez těchto rozhodnutí se změní umístění aplikace, ale ne její provozní model.
Jak se rozhodnout u každé aplikace
Prvním krokem je rozhodnutí, co s každou aplikací udělat. Některé lze přesunout bez zásadní změny, jiné potřebují úpravu, přepis nebo náhradu; část portfolia může zůstat v současném prostředí. Každé rozhodnutí musí uvést důvod, předpoklady, dopad na data a integrace a cílový způsob provozu.
Přesun 1:1 (rehost)
Přesun aplikace na cloudovou infrastrukturu bez zásadní změny omezuje zásah do jejího kódu. Stále je však nutné vyřešit kompatibilitu, síť, zabezpečení a následný provoz. Hodí se například při ukončení datacentra nebo jako mezikrok před náhradou systému.
Přesun s částečnou modernizací (replatform)
Přesun využije vybrané spravované služby, například databázi nebo webovou platformu. Rozsah úprav určí kompatibilita aplikace. Zálohy, dostupnost a škálování se řídí možnostmi konkrétní služby, zvoleným tarifem a konfigurací.
Změna architektury (refactor)
Architektura aplikace se upraví pro využití vybraných cloudových služeb. Monolit lze rozdělit na menší služby, virtuální servery nahradit kontejnery nebo bezserverovými funkcemi a některé integrace převést na komunikaci založenou na událostech. Přínos a budoucí provozní náklady je potřeba porovnat s cenou této změny.
Náhrada službou SaaS (repurchase)
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.
Vyřazení systému (retire)
Inventář a provozní data mohou odhalit nepoužívané nebo duplicitní aplikace. Před jejich vypnutím je potřeba ověřit skutečné používání, návaznosti, archivaci dat a retenční povinnosti.
Ponechání systému (retain)
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.
Přehled migračních strategií
Tabulka porovnává jednotlivé strategie podle typické výchozí situace a výsledku pro danou aplikaci.
| 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
Z čeho se skládají cloudové náklady
Náklady na cloud netvoří jen 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
U spravované databáze přebírá poskytovatel část aktualizací, zálohování a zajištění dostupnosti. Přesný rozsah odpovědnosti i možnosti obnovy dat závisí na službě, tarifu a nastavení. Při rozhodování proto porovnáváme požadované SLA, kompetence týmu a celkové náklady.
Odchozí datové přenosy z cloudu (egress)
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í
Cena objektového úložiště se může skládat z uloženého objemu, provedených operací a datových přenosů. 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.
Retence, soft delete a snapshoty
Soft delete a pravidelné snapshoty chrání data, ale zabírají další úložiště. Dopad na účet závisí na objemu změn, frekvenci a době uchování, proto je potřeba jej zahrnout do cenové kalkulace.
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
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. Stejné srovnání musí zahrnout také dlouhodobou správu cloudu a serverů, odpovědnost za změny a způsob řešení incidentů.
Azure pro aplikace využívající cloudové služby
Azure má smysl prověřit, pokud aplikace využije App Service, Functions, Cosmos DB, Event Grid nebo Service Bus a potřebuje pružné škálování či integraci s Microsoft 365 nebo Dynamics 365. Regulatorní požadavky a umístění dat je nutné posoudit pro konkrétní služby a porovnat i s alternativami.
Vyhrazený server pro stálou zátěž
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ů.
Hybridní varianta pro aplikaci a datové úložiště
Možná kombinace pro firmy, které mají velká data a zároveň potřebují pružně škálovatelnou webovou část. 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í odchozí datové přenosy, latence, dostupnost i náklady na správu.
Ponechání současného prostředí
Starší aplikace může zůstat na stabilním hardwaru, pokud její provoz splňuje požadavky a změna by neměla odpovídající přínos. Migrační plán pak řeší její podporu, bezpečnost a vazby na systémy, které se přesouvají.
Co musí být připravené před zahájením migrace
Před zahájením migrace musí být jasný důvod změny, vlastníci jednotlivých systémů a způsob kontroly dat i provozu po přechodu. Tyto vstupy určují rozsah analýzy, pořadí etap a proveditelný harmonogram.
Důvod a hranice projektu
Určete, jaké omezení má migrace vyřešit a které aplikace, země nebo části provozu patří do první etapy.
Vlastníci a rozhodování
U každé aplikace určete člověka, který zná její provoz, potvrdí požadavky a rozhodne o přijetí výsledku.
Data, přístupy a dokumentace
Připravte přístup ke zdrojovým systémům, popis integrací, rozsah převáděných dat a dostupnou provozní dokumentaci.
Testování a přechod
Dohodněte přijatelnou odstávku, kontrolní scénáře, odpovědnosti a podmínky pokračování nebo návratu.
Migrace systému Helvetia do Azure
Pro Helvetii jsme analyzovali backoffice ve Visual Basicu, přepsali celý systém do C# .NET a nasadili ho do Azure App Service a SQL Database. Přepis a migrace trvaly 18 měsíců a přechod probíhal řízeně pro sedm evropských trhů. Po nasazení pokračujeme v provozní podpoře a rozvoji.
Č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 projekt zahrnoval úplný přepis rozsáhlé desktopové aplikace ve Visual Basicu do .NET a její migraci do Azure; trval 18 měsíců.
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 pružné škálování či cloudové integrace a jiná má stálou výpočetní nebo datovou zátěž. O výsledku rozhoduje celkové TCO, odchozí datové přenosy, latence, dostupnost, bezpečnost a schopnost obě prostředí spravovat.
Jaký je rozdíl mezi cloud-hosted a cloud-native aplikací?
Cloud-hosted aplikace běží na cloudové infrastruktuře bez zásadní změny architektury. Cloud-native aplikace je navržená přímo pro cloud a využívá například bezserverové funkce, komunikaci založenou na událostech, spravované databáze nebo horizontální škálování. Volba cloud-native architektury sama o sobě nezaručuje 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.
Související témata
Plánujete migraci do cloudu?
Na úvodní konzultaci projdeme důvod změny, současný provoz, data a závislosti vybraných systémů. Určíme, co je potřeba ověřit před návrhem migračního plánu.