Migrace do cloudu bez výpadku: jak přesunout data a aplikace, aby si toho zákazníci ani nevšimli

01Proč se migrace pokazí, i když data dorazí v pořádku

Jedna z nejdražších migračních chyb v bankovnictví nevznikla ztrátou dat. Britská banka TSB v dubnu 2018 přesunula data klientů na novou platformu bez chyby, jenže systém hned po spuštění začal selhávat. Potíže zasáhly všechny pobočky a velkou část z 5,2 milionu klientů. Běžný provoz se vrátil až v prosinci. Regulátoři FCA a PRA bance vyměřili pokuty v úhrnu 48,65 milionu liber a na odškodnění klientů zaplatila dalších 32,7 milionu (FCA). Podle regulátorů banka migraci špatně naplánovala, neměla ji pod kontrolou a nezvládla řízení rizik u kritického IT dodavatele.

Z toho plynou dvě lekce. Zkopírovat data je ta snazší polovina práce, těžší je ověřit, že nad nimi všechno funguje pod skutečnou zátěží. A za výsledek odpovídáte vy, i když migraci dělá dodavatel. Proto se vyplatí mít přístupy, dokumentaci i zdrojové kódy ve svých rukou, jak popisujeme v článku jak převzít web od dodavatele.

Další věc, kterou firmy podceňují: cloud výpadky neodstraní, jen je přesune jinam. Za zhruba dvěma třetinami veřejně hlášených výpadků za posledních devět let stojí externí poskytovatelé IT a datových center, tedy velcí cloudoví hráči, operátoři a pronajímatelé serveroven. Nejčastější lidskou příčinou výpadků přitom zůstává nedodržení zavedených postupů (Uptime Institute). Migraci proto stavte tak, aby s chybou počítala. Potřebujete cestu zpět, vyzkoušenou obnovu ze zálohy a jasný scénář, kdo co udělá, když něco selže.

Česko je v zavádění cloudu těsně nad evropským průměrem, Slovensko s 36,4 % výrazně pod ním. Z českých firem, které za cloud platí, v něm ale e-mail provozuje 89,8 %, kdežto databázi jen 41,5 %. A právě databáze a systémy nad nimi jsou na migraci nejcitlivější.

02Příprava: bez inventury nepřesouvejte ani jeden server

Častou příčinou nepříjemných překvapení při přepnutí je zapomenutá závislost. Typicky jde o noční úlohu, která kopíruje soubory na síťový disk, o účetní program napojený přímo na databázi e-shopu nebo o IP adresu natvrdo zapsanou v konfiguraci. Než se dotknete prvního serveru, potřebujete vědět, co přesně stěhujete a co na čem závisí.

1. Sepište všechno, co běží. Aplikace, databáze, úložiště, plánované úlohy a napojení na partnery. U každé položky uveďte vlastníka na straně firmy, ne jen správce.
2. Zmapujte toky dat. Kdo s kým komunikuje, přes jaké porty a jak často. Týden záznamu síťového provozu odhalí víc než jakákoli dokumentace. Zvlášť si projděte napojení přes API, o kterých píšeme v článku propojení systémů přes API.
3. Určete, co si můžete dovolit. Každé aplikaci přiřaďte dva údaje: jak dlouho smí být nedostupná (RTO) a za jak dlouhé období smíte přijít o data (RPO). E-shop snese minuty, interní wiki klidně celý den.
4. Seřaďte aplikace podle rizika. Jako pilot vyberte systém, který je důležitý, ale ne kritický, a má málo závislostí. Na něm si vyzkoušíte postup i nástroje.

Ne každá aplikace potřebuje stejný přístup. Pro výběr se používá rámec sedmi strategií, kterému se podle anglických názvů říká 7R (AWS Prescriptive Guidance).

Častou chybou je pustit se do přestavby aplikace ve chvíli, kdy ji stěhujete. AWS u velkých migrací výslovně doporučuje nejdřív přesunout a modernizovat až potom. Dvě velké změny najednou znamenají, že při problému nevíte, která z nich ho způsobila.

03Data: kopírujte průběžně, přepnutí zvládněte za pár minut

Při migraci bez výpadku se data nepřenášejí najednou. Postup má pět kroků a zákazník si všimne nanejvýš přepnutí, které trvá minuty.

Počáteční kopie. Migrační nástroj zkopíruje celou databázi do cloudu, zatímco původní systém normálně běží a přijímá objednávky.

Průběžná replikace (CDC, change data capture). Od začátku kopírování nástroj čte transakční log zdrojové databáze a každou změnu posílá do cloudu. U MySQL čte binární log, u PostgreSQL využívá logickou replikaci. Dokumentace AWS Database Migration Service upozorňuje na dvě věci. Replikace neběží v reálném čase a její zpoždění může při zátěži vzrůst na několik minut i víc. Zdrojová databáze navíc musí uchovávat log změn dost dlouho, u zdrojové databáze v Amazon RDS podle AWS obvykle stačí 24 hodin (AWS DMS). Zpoždění replikace proto sledujte a přepínejte teprve tehdy, když se dlouhodobě drží v řádu sekund. V režimu jen pro čtení pak klesne na nulu.

Přepnutí. Aplikaci na několik minut převedete do režimu jen pro čtení, počkáte, až replikace dožene poslední změny, ověříte shodu dat a zápis přesměrujete do nové databáze. Zákazník si web mezitím normálně prohlíží, jen chvíli nemůže odeslat objednávku. Martin Fowler zmiňuje i možnost nechat nové prostředí před přepnutím nějakou dobu běžet jen pro čtení. Podle něj to může stačit k odhalení řady skrytých problémů dřív, než se začne zapisovat naostro (martinfowler.com).

Ověření. Porovnejte počty řádků v každé tabulce, kontrolní součty klíčových tabulek a několik konkrétních záznamů, třeba posledních sto objednávek. Automatická kontrola, kterou nabízí většina migračních nástrojů, je dobrý začátek, ne náhrada vlastního testu.

Cesta zpět. Po přepnutí nechte běžet replikaci opačným směrem, z cloudu zpět do starého systému. Když se v prvních dnech nebo týdnech objeví vážná chyba, vrátíte se bez ztráty objednávek, které mezitím přibyly. AWS DMS obousměrnou replikaci umí, ale výslovně uvádí, že konflikty nerozpozná ani nevyřeší. Zapisovat proto smíte vždy jen do jedné z obou databází.

Plán návratu. Starý systém nevypínejte hned po přepnutí. Nechte ho běžet s obrácenou replikací, dokud neproběhne alespoň jeden kritický cyklus vaší firmy, třeba měsíční uzávěrka nebo výplaty. Teprve potom ho vypněte a data v něm bezpečně smažte.

04Aplikace: provoz přepínejte po částech

U aplikací platí stejný princip jako u dat. Nové prostředí běží vedle starého a provoz na něj převádíte postupně.

Blue-green. Máte dvě co nejpodobnější produkční prostředí. Na starém běží provoz, na novém dokončíte testy a pak přepnete směrování. Když se něco pokazí, přepnete zpátky (martinfowler.com).

Postupné přepínání. Místo celého provozu najednou pošlete do cloudu nejdřív malou část uživatelů, třeba 5 %, potom 25 %, 50 % a nakonec všechny. Mezi jednotlivými kroky sledujte chybovost a odezvu. Poměr nastavíte na load balanceru nebo váženým záznamem v DNS. Zapisuje se přitom už jen do nové databáze: po přepnutí dat na ni míří staré i nové aplikační servery.

DNS. Změna záznamu se k uživatelům nedostane okamžitě, protože resolvery si starou hodnotu pamatují po dobu TTL. Cloudflare doporučuje snížit TTL kritických záznamů nejméně 24 až 48 hodin před migrací, běžně na 300 sekund, u záznamů s delším TTL ideálně s předstihem odpovídajícím jejich TTL (Cloudflare). Pokud má záznam TTL jeden den a vy ho nesnížíte, část zákazníků bude chodit na starý server ještě den po přepnutí. Stejně dlouho by pak trval i návrat.

Na co se nejčastěji zapomíná:

• Přihlášení uživatelů. Pokud aplikace drží relace v paměti serveru, po přepnutí se všichni odhlásí. Relace přesuňte do sdíleného úložiště ještě před migrací.
• Soubory od uživatelů. Nahrané faktury, fotky a přílohy synchronizujte průběžně stejně jako databázi.
• Změny databázového schématu. Nejdřív upravte schéma tak, aby fungovalo se starou i novou verzí aplikace. Staré sloupce mažte až po ustálení provozu.
• Odchozí IP adresy. Banky, platební brány a partneři mají často povolené jen vaše současné adresy. Nové jim nahlaste s předstihem.
• E-maily z aplikace. Po změně serveru zkontrolujte záznamy SPF, DKIM a DMARC, jinak mohou potvrzení objednávek končit ve spamu.

Nové prostředí před přepnutím vyzkoušejte zátěžovým testem, ideálně se špičkou, jakou zažíváte v sezóně. Na co se při něm dívat, popisujeme v článku o škálovatelnosti webové aplikace.

Kritéria pro pokračování a pro návrat si sepište předem a měřitelně. Například chybovost nad 1 % po dobu pěti minut nebo odezva košíku nad dvě sekundy znamená okamžitý návrat. Pravidlo sepsané v klidu je lepší než rozhodnutí ve dvě ráno pod tlakem.

05Bezpečnost, zákony a smlouva s poskytovatelem

Během migrace jsou data zranitelnější než kdykoli jindy. Existují ve dvou kopiích, putují po síti a přístup k nim má víc lidí než obvykle.

• Šifrujte přenos i uložená data. U citlivých dat si klíče spravujte sami.
• Přístupy pro migraci časově omezte. Dočasné účty a klíče po dokončení zrušte. Všechny administrátorské účty v cloudu chraňte dvoufázovým ověřením.
• Logování zapněte první den, ne až po spuštění. Bez záznamů nezjistíte, co se během přepnutí stalo.
• Zálohu před přepnutím zkušebně obnovte. Záloha, ze které jste nikdy nic neobnovili, je jen naděje.
• Staré prostředí po skončení zkušebního provozu bezpečně zlikvidujte, včetně disků, snapshotů a starých záloh.

Nastavení serverů, HTTPS a oprávnění v cloudu podrobně rozebírá náš článek zabezpečení serveru, HTTPS a cloudu, ochranu osobních údajů v aplikaci pak bezpečnost dat v systému na míru.

Zákon o kybernetické bezpečnosti. Od 1. listopadu 2025 je účinný zákon č. 264/2025 Sb., který do českého práva převádí směrnici NIS2. Podle odhadu NÚKIB se týká zhruba šesti tisíc organizací, do února 2026 se jich ohlásilo přes 4 800. Regulovaná firma podává prvotní hlášení incidentu do 24 hodin od zjištění. Má-li incident významný dopad, následuje do 72 hodin oznámení a do 30 dnů od něj závěrečná zpráva. Firmy v režimu vyšších povinností hlásí NÚKIB. Firmy v režimu nižších povinností hlásí Národnímu CERT, a to jen incidenty s významným dopadem. Za kybernetickou bezpečnost odpovídá vrcholné vedení. V režimu vyšších povinností hrozí pokuta až 250 milionů Kč nebo 2 % čistého celosvětového ročního obratu podle toho, co je vyšší, v režimu nižších povinností až 175 milionů Kč nebo 1,4 % (Lupa.cz).

Pokud v cloudu poběží regulovaná služba v režimu vyšších povinností, bude poskytovatel typicky významným dodavatelem podle vyhlášky č. 409/2025 Sb. a smlouva s ním musí obsahovat předepsané náležitosti včetně pravidel zákaznického auditu. Hospodářská komora ČR firmám doporučuje mít ve smlouvách s dodavateli minimální bezpečnostní standardy, právo na audit a lhůty pro reakci na incidenty (Lupa.cz). Co z toho musí hlídat vedení firmy, shrnuje článek bezpečnost aplikace pro vedení: NIS2 a CRA.

GDPR. Pokud v cloudu zpracováváte osobní údaje, poskytovatel je v roli zpracovatele a potřebujete s ním smlouvu o zpracování osobních údajů podle čl. 28 GDPR (ÚOOÚ). U velkých poskytovatelů bývá součástí obchodních podmínek. Ověřte také, ve kterých zemích data fyzicky leží a zda se nepřenášejí mimo EU a Evropský hospodářský prostor.

Data Act a cesta ven. Podle nařízení o datech (Data Act) musí poskytovatelé cloudu v EU od 12. září 2025 umožnit přechod k jinému poskytovateli nebo zpět do vlastní serverovny. Výpovědní lhůta pro zahájení přechodu smí být nejvýš dva měsíce a samotný přechod má proběhnout do 30 dnů. Pokud to technicky nejde, nejvýš do sedmi měsíců. Do 12. ledna 2027 smí poskytovatel za přechod účtovat nejvýš skutečné náklady, které s ním přímo souvisejí, potom žádné poplatky, a to ani za přenos dat ven (nařízení (EU) 2023/2854, DLA Piper).

Při výběru cloudu si proto rovnou nechte popsat, jak data dostanete zpět a v jakém formátu. Plán odchodu patří k dobré migraci stejně jako plán příchodu.

06Kontrolní seznam před migrací

Zkopírujte si ho a ke každému bodu doplňte, kdo za něj odpovídá.

Týdny předem

• Seznam aplikací, databází, úložišť, plánovaných úloh a napojení na partnery
• Mapa toků dat z alespoň týdenního záznamu provozu
• RTO a RPO pro každou aplikaci, odsouhlasené s vedením
• Zvolená strategie ze 7R pro každou aplikaci a pořadí migrace po vlnách
• Pilotní migrace na méně kritickém systému
• Smlouva s poskytovatelem: bezpečnostní požadavky, právo na audit, lhůty pro incidenty, plán odchodu
• Zpracovatelská smlouva podle GDPR a ověřené umístění dat

Týden před přepnutím

• TTL kritických DNS záznamů snížené na 300 sekund, nejméně 24 až 48 hodin předem
• Replikace dat běží a zpoždění se drží v řádu sekund
• Relace uživatelů ve sdíleném úložišti
• Nové odchozí IP adresy nahlášené bankám a partnerům
• SPF, DKIM a DMARC připravené pro nové servery
• Záloha vytvořená a zkušebně obnovená
• Sepsaná kritéria pro pokračování a pro návrat
• Zátěžový test nového prostředí

Den přepnutí

• Informovaný zákaznický servis a připravená zpráva pro zákazníky
• Režim jen pro čtení, dorovnání replikace, kontrola dat
• Postupné přepínání provozu s kontrolou chybovosti po každém kroku
• Spuštěná obrácená replikace do starého systému

Po přepnutí

• Staré prostředí běží až do konce prvního kritického cyklu firmy
• Dočasné migrační účty a klíče zrušené
• TTL vrácené na běžné hodnoty
• Staré prostředí vypnuté a data bezpečně smazaná

07Časté otázky

08Zdroje

• Uptime Institute: Annual Outage Analysis 2026
• Eurostat: cloudové služby ve firmách (isoc_cicce_use)
• Eurostat: 53 % firem v EU platilo v roce 2025 za cloud
• FCA: pokuta pro TSB za selhání migrace
• AWS Prescriptive Guidance: strategie migrace 7R
• AWS Prescriptive Guidance: průvodce velkými migracemi
• AWS DMS: průběžná replikace (CDC)
• Martin Fowler: Blue Green Deployment
• Cloudflare: příprava DNS na migraci
• Zákon č. 264/2025 Sb., o kybernetické bezpečnosti
• Vyhláška č. 409/2025 Sb. (režim vyšších povinností)
• NÚKIB: ohlášení podle nového zákona provedlo přes 4 800 organizací
• Lupa.cz: zákon o kybernetické bezpečnosti začal platit
• ÚOOÚ: zpracovatel osobních údajů
• Nařízení (EU) 2023/2854 (Data Act)
• DLA Piper: odchod z cloudu podle Data Act
• ČNB: kurz devizového trhu 29. 9. 2026

Údaje platí k 29. 9. 2026. Dolary jsme přepočítali kurzem ČNB z téhož dne (21,501 Kč za dolar).