Migrácia do cloudu bez výpadku: ako presunúť dáta a aplikácie tak, aby si to zákazníci ani nevšimli

01Prečo sa migrácia pokazí, aj keď dáta dorazia v poriadku

Jedna z najdrahších migračných chýb v bankovníctve nevznikla stratou dát. Britská banka TSB v apríli 2018 presunula dáta klientov na novú platformu bez chyby, lenže systém hneď po spustení začal zlyhávať. Problémy zasiahli všetky pobočky a veľkú časť z 5,2 milióna klientov a bežná prevádzka sa vrátila až v decembri. Regulátori FCA a PRA banke uložili pokuty v celkovej výške 48,65 milióna libier a na odškodnenie klientov zaplatila ďalších 32,7 milióna (FCA). Podľa regulátorov banka migráciu zle naplánovala, nemala ju pod kontrolou a nezvládla riadenie rizík outsourcingu IT u kritického dodávateľa.

Plynú z toho dve poučenia. Skopírovať dáta je tá jednoduchšia polovica práce, ťažšie je overiť, že nad nimi všetko funguje pod skutočnou záťažou. A za výsledok zodpovedáte vy, aj keď migráciu robí dodávateľ. Preto sa oplatí mať prístupy, dokumentáciu aj zdrojové kódy vo svojich rukách, ako opisujeme v článku ako prevziať web od dodávateľa.

Firmy podceňujú aj ďalšiu vec: cloud výpadky neodstráni, len ich presunie inam. Za približne dvoma tretinami verejne hlásených výpadkov za posledných deväť rokov stoja externí poskytovatelia IT služieb a dátových centier vrátane veľkých cloudových a internetových firiem, telekomunikačných operátorov a poskytovateľov kolokácie. Pri výpadkoch spôsobených ľudskou chybou je navyše najčastejšou príčinou nedodržanie zavedených postupov (Uptime Institute). Migráciu preto plánujte tak, aby s chybami počítala. Potrebujete cestu späť, vyskúšanú obnovu zo zálohy a jasný scenár, kto čo urobí, keď niečo zlyhá.

Slovensko v zavádzaní cloudu výrazne zaostáva za priemerom EÚ aj za všetkými susedmi v EÚ. Zo slovenských firiem, ktoré za cloud platia, v ňom e-mail prevádzkuje deväť z desiatich, databázu len 43,9 %. Práve databázy a systémy nad nimi sú pritom na migráciu najcitlivejšie.

02Príprava: bez inventúry nepresúvajte ani jeden server

Častou príčinou nepríjemných prekvapení pri prepnutí je zabudnutá závislosť. Typicky ide o nočnú úlohu, ktorá kopíruje súbory na sieťový disk, o účtovný program napojený priamo na databázu e-shopu alebo o IP adresu napevno zapísanú v konfigurácii. Skôr než sa dotknete prvého servera, musíte vedieť, čo presne presúvate a čo od čoho závisí.

1. Spíšte všetko, čo beží. Aplikácie, databázy, úložiská, plánované úlohy a prepojenia na partnerov. Pri každej položke uveďte vlastníka na strane firmy, nielen správcu.
2. Zmapujte toky dát. Kto s kým komunikuje, cez aké porty a ako často. Týždeň záznamu sieťovej prevádzky prezradí viac ako akákoľvek dokumentácia. Osobitne si prejdite prepojenia cez API, o ktorých píšeme v článku prepojenie systémov cez API.
3. Určte, čo si môžete dovoliť. Každej aplikácii priraďte dva údaje: ako dlho smie byť nedostupná (RTO) a za aké obdobie smiete prísť o dáta (RPO). E-shop znesie minúty, interná wiki pokojne celý deň.
4. Zoraďte aplikácie podľa rizika. Ako pilot zvoľte systém, ktorý je dôležitý, ale nie kritický, a má málo závislostí. Na ňom si vyskúšate postup aj nástroje.

Nie každá aplikácia potrebuje rovnaký prístup. Pri výbere pomáha rámec siedmich stratégií, ktorému sa podľa anglických názvov hovorí 7R (AWS Prescriptive Guidance).

Častou chybou je pustiť sa do prestavby aplikácie v tom istom čase, keď ju presúvate. AWS pri veľkých migráciách výslovne odporúča najprv presunúť a modernizovať až potom. Dve veľké zmeny naraz znamenajú, že pri probléme neviete, ktorá z nich ho spôsobila.

03Dáta: kopírujte priebežne, prepnite za pár minút

Pri migrácii bez výpadku sa dáta neprenášajú naraz. Postup má päť krokov a zákazník si všimne nanajvýš prepnutie, ktoré trvá minúty.

Počiatočná kópia. Migračný nástroj skopíruje celú databázu do cloudu, zatiaľ čo pôvodný systém normálne beží a prijíma objednávky.

Priebežná replikácia (CDC, change data capture). Od začiatku kopírovania nástroj číta transakčný log zdrojovej databázy a každú zmenu posiela do cloudu. Pri MySQL číta binárny log, pri PostgreSQL využíva logickú replikáciu. Dokumentácia AWS Database Migration Service upozorňuje na dve veci. Replikácia nebeží v reálnom čase a jej oneskorenie môže pri záťaži narásť na niekoľko minút aj viac. Zdrojová databáza navyše musí uchovávať log zmien dostatočne dlho, pri Amazon RDS ako zdroji podľa AWS zvyčajne stačí 24 hodín (AWS DMS). Oneskorenie replikácie preto sledujte a prepínajte až vtedy, keď sa dlhodobo drží v rádoch sekúnd. V režime len na čítanie potom klesne na nulu.

Prepnutie. Aplikáciu na niekoľko minút prepnete do režimu len na čítanie, počkáte, kým replikácia dobehne posledné zmeny, overíte zhodu dát a zápis presmerujete do novej databázy. Zákazník si web medzitým normálne prezerá, len chvíľu nemôže odoslať objednávku. Martin Fowler uvádza ako jednu z možností nechať nové prostredie pred prepnutím istý čas bežať len na čítanie. Podľa neho to môže stačiť na odhalenie mnohých skrytých problémov skôr, než sa začne zapisovať naostro (martinfowler.com).

Overenie. Porovnajte počty riadkov v každej tabuľke, kontrolné súčty kľúčových tabuliek a niekoľko konkrétnych záznamov, napríklad posledných sto objednávok. Automatická kontrola, ktorú ponúka mnoho migračných nástrojov, je dobrý začiatok, vlastný test však nenahradí.

Cesta späť. Po prepnutí nechajte bežať replikáciu opačným smerom, z cloudu späť do starého systému. Ak sa v prvých dňoch alebo týždňoch objaví vážna chyba, vrátite sa bez straty objednávok, ktoré medzitým pribudli. AWS DMS obojsmernú replikáciu podporuje, ale výslovne uvádza, že konflikty nerozpozná ani nevyrieši. Zapisovať preto smiete vždy len do jednej z oboch databáz.

Kedy vypnúť starý systém. Starý systém nevypínajte hneď po prepnutí. Nechajte ho bežať so spätnou replikáciou, kým neprebehne aspoň jeden kritický cyklus vašej firmy, napríklad mesačná uzávierka alebo výplaty. Až potom ho vypnite a dáta v ňom bezpečne vymažte.

04Aplikácie: prevádzku prepínajte po častiach

Pri aplikáciách platí rovnaký princíp ako pri dátach. Nové prostredie beží vedľa starého a prevádzku naň presúvate postupne.

Blue-green. Máte dve čo najpodobnejšie produkčné prostredia. Na starom beží prevádzka, na novom dokončíte testy a potom prepnete smerovanie. Keď sa niečo pokazí, prepnete naspäť (martinfowler.com).

Postupné prepínanie. Namiesto celej prevádzky naraz pošlite do cloudu najprv malú časť používateľov, napríklad 5 %, potom 25 %, 50 % a nakoniec všetkých. Medzi jednotlivými krokmi sledujte chybovosť a odozvu. Pomer nastavíte na load balanceri alebo váženým záznamom v DNS. Zapisuje sa pritom už len do novej databázy: po prepnutí dát na ňu smerujú staré aj nové aplikačné servery.

DNS. Zmena záznamu sa k používateľom nedostane okamžite, pretože resolvery si starú hodnotu pamätajú počas celej doby TTL. Cloudflare odporúča znížiť TTL kritických záznamov najmenej 24 až 48 hodín pred migráciou, bežne na 300 sekúnd, pri záznamoch s dlhším TTL ideálne s predstihom zodpovedajúcim ich TTL (Cloudflare). Ak má záznam TTL jeden deň a vy ho neznížite, časť zákazníkov môže chodiť na starý server ešte až deň po prepnutí. Rovnako dlho by potom trval aj návrat.

Na čo sa najčastejšie zabúda:

• Prihlásenie používateľov. Ak aplikácia drží relácie v pamäti servera, po prepnutí aplikácia všetkých odhlási. Relácie presuňte do zdieľaného úložiska ešte pred migráciou.
• Súbory od používateľov. Nahrané faktúry, fotky a prílohy synchronizujte priebežne rovnako ako databázu.
• Zmeny databázovej schémy. Najprv upravte schému tak, aby fungovala so starou aj novou verziou aplikácie. Staré stĺpce mažte až po ustálení prevádzky.
• Odchádzajúce IP adresy. Banky, platobné brány a partneri majú často povolené len vaše súčasné adresy. Nové im nahláste s predstihom.
• E-maily z aplikácie. Záznamy SPF, DKIM a DMARC upravte pre nové servery ešte pred prepnutím, inak môžu potvrdenia objednávok končiť v spame.

Nové prostredie pred prepnutím vyskúšajte záťažovým testom, ideálne so záťažou, akú máte v sezónnej špičke. Na čo sa pri ňom pozerať, opisujeme v článku o škálovateľnosti webovej aplikácie.

Kritériá na pokračovanie aj na návrat si spíšte vopred a merateľne. Napríklad chybovosť nad 1 % počas piatich minút alebo odozva košíka nad dve sekundy znamená okamžitý návrat. Pravidlo spísané v pokoji je lepšie ako rozhodnutie o druhej ráno pod tlakom.

05Bezpečnosť, zákony a zmluva s poskytovateľom

Počas migrácie sú dáta zraniteľnejšie ako kedykoľvek inokedy. Existujú v dvoch kópiách, putujú po sieti a prístup k nim má viac ľudí ako zvyčajne.

• Šifrujte prenos aj uložené dáta. Pri citlivých dátach si kľúče spravujte sami.
• Migračné prístupy časovo obmedzte. Dočasné účty a kľúče po dokončení zrušte. Všetky administrátorské účty v cloude chráňte dvojfaktorovým overením.
• Logovanie zapnite hneď v prvý deň, nie až po spustení. Bez záznamov nezistíte, čo sa počas prepnutia stalo.
• Zálohu pred prepnutím skúšobne obnovte. Záloha, z ktorej ste nikdy nič neobnovili, je len nádej.
• Staré prostredie po skončení skúšobnej prevádzky bezpečne zlikvidujte, vrátane diskov, snapshotov a starých záloh.

Nastavenie serverov, HTTPS a oprávnení v cloude podrobne rozoberá náš článok zabezpečenie servera, HTTPS a cloudu, ochranu osobných údajov v aplikácii zasa bezpečnosť dát v systéme na mieru.

Zákon o kybernetickej bezpečnosti. Od 1. januára 2025 je účinný zákon č. 366/2024 Z. z., ktorým sa novelizoval zákon č. 69/2018 Z. z. o kybernetickej bezpečnosti a ktorý do slovenského práva preberá smernicu NIS2. Prevádzkovateľ základnej služby hlási závažný incident v troch krokoch: včasné varovanie do 24 hodín od zistenia, oznámenie do 72 hodín od zistenia a záverečnú správu najneskôr mesiac po oznámení. Bezpečnostné opatrenia musí zaviesť do 12 mesiacov od zápisu do registra. Za nenahlásenie závažného incidentu hrozí pokuta až 7 miliónov eur alebo 1,4 % celosvetového ročného obratu, podľa toho, ktorá suma je vyššia; pri kritickej základnej službe až 10 miliónov eur alebo 2 % (Podnikajte.sk, zákon č. 69/2018 Z. z.).

Pre migráciu je kľúčové, že ak ste prevádzkovateľom základnej služby, s treťou stranou, cez ktorú vykonávate činnosti priamo súvisiace s prevádzkou vašich sietí a informačných systémov, musíte uzavrieť zmluvu o zabezpečení plnenia bezpečnostných opatrení a notifikačných povinností. Cloudový poskytovateľ je spravidla takou treťou stranou a musí sa podrobiť vašej kontrole. Zmluva nie je povinná, ak je poskytovateľ sám prevádzkovateľom základnej služby alebo ak je riziko nízke. Čo z toho musí sledovať vedenie firmy, zhŕňa článok bezpečnosť aplikácie pre vedenie: NIS2 a CRA.

GDPR. Ak v cloude spracúvate osobné údaje, poskytovateľ je v úlohe sprostredkovateľa a potrebujete s ním sprostredkovateľskú zmluvu podľa čl. 28 GDPR. Overte si aj to, v ktorých krajinách sú dáta fyzicky uložené a či sa neprenášajú mimo EÚ a Európskeho hospodárskeho priestoru.

Data Act (akt o údajoch) a cesta von. Od 12. septembra 2025 musia poskytovatelia cloudu v EÚ umožniť prechod k inému poskytovateľovi alebo späť do vlastnej serverovne. Výpovedná lehota na začatie prechodu smie byť najviac dva mesiace a samotný prechod má prebehnúť do 30 dní, a ak to technicky nie je možné, najneskôr do siedmich mesiacov. Do 12. januára 2027 smie poskytovateľ za prechod účtovať najviac skutočné náklady, ktoré s ním priamo súvisia, potom žiadne poplatky, a to ani za prenos dát von (nariadenie (EÚ) 2023/2854, DLA Piper).

Pri výbere cloudu si preto rovno nechajte popísať, ako dáta dostanete späť a v akom formáte. Plán odchodu patrí k dobrej migrácii rovnako ako plán príchodu.

06Kontrolný zoznam pred migráciou

Skopírujte si ho a ku každému bodu doplňte, kto zaň zodpovedá.

Týždne vopred

• Zoznam aplikácií, databáz, úložísk, plánovaných úloh a prepojení na partnerov
• Mapa tokov dát z aspoň týždenného záznamu prevádzky
• RTO a RPO pre každú aplikáciu, odsúhlasené s vedením
• Zvolená stratégia zo 7R pre každú aplikáciu a poradie migrácie po vlnách
• Pilotná migrácia na menej kritickom systéme
• Zmluva s poskytovateľom: bezpečnostné opatrenia, notifikačné povinnosti, právo na kontrolu, plán odchodu
• Sprostredkovateľská zmluva podľa GDPR a overené umiestnenie dát

Týždeň pred prepnutím

• TTL kritických DNS záznamov znížené na 300 sekúnd, najmenej 24 až 48 hodín vopred
• Replikácia dát beží a oneskorenie sa drží v rádoch sekúnd
• Relácie používateľov v zdieľanom úložisku
• Nové odchádzajúce IP adresy nahlásené bankám a partnerom
• SPF, DKIM a DMARC pripravené pre nové servery
• Záloha vytvorená a skúšobne obnovená
• Spísané kritériá na pokračovanie a na návrat
• Záťažový test nového prostredia

Deň prepnutia

• Informovaný zákaznícky servis a pripravená správa pre zákazníkov
• Režim len na čítanie, dobehnutie replikácie, kontrola dát
• Postupné prepínanie prevádzky s kontrolou chybovosti po každom kroku
• Spätná replikácia do starého systému spustená

Po prepnutí

• Staré prostredie beží do konca prvého kritického cyklu firmy
• Dočasné migračné účty a kľúče zrušené
• TTL vrátené na bežné hodnoty
• Staré prostredie vypnuté a dáta bezpečne vymazané

07Časté otázky

08Zdroje

• Uptime Institute: Annual Outage Analysis 2026
• Eurostat: cloudové služby vo firmách (isoc_cicce_use)
• Eurostat: 53 % firiem v EÚ platilo v roku 2025 za cloud
• FCA: pokuta pre TSB za zlyhanie migrácie
• AWS Prescriptive Guidance: stratégie migrácie 7R
• AWS Prescriptive Guidance: sprievodca veľkými migráciami
• AWS DMS: priebežná replikácia (CDC)
• Martin Fowler: Blue Green Deployment
• Cloudflare: príprava DNS na migráciu
• Zákon č. 366/2024 Z. z., novela zákona o kybernetickej bezpečnosti
• Zákon č. 69/2018 Z. z. o kybernetickej bezpečnosti, aktuálne znenie
• Podnikajte.sk: novela zákona o kybernetickej bezpečnosti od 1. 1. 2025
• Nariadenie (EÚ) 2023/2854 (Data Act)
• DLA Piper: odchod z cloudu podľa Data Act
• ECB: referenčné výmenné kurzy

Údaje sú aktuálne k 29. 9. 2026. Doláre sme prepočítali kurzom ECB z toho istého dňa (1 euro = 1,1355 USD).