Data Act posunul cloud switching z „teoretickej možnosti“ na tému, ktorú treba mať zvládnutú aj prakticky. Nie preto, že by firmy začali hromadne migrovať, ale preto, že sa mení tlak na vykonateľnosť. Zmena poskytovateľa nemá byť ročný projekt, ktorý sa rozpadne na exportoch, závislostiach a nejasných zodpovednostiach.

Lenže cloud switching firmy často nerobia nie preto, že by ho nechceli. Nerobia ho, lebo vedia, koľko stojí a čo môže pokaziť. Pri PaaS migrácii nejde len o presun infraštruktúry, ale o zásah do dát, integrácií a IAM. A každý taký zásah nesie riziko výpadku aj bezpečnostných incidentov.

Čo znamená cloud switching v realite

Cloud switching nie je „presunieme virtuálky a hotovo“. Pri väčšine moderných systémov je infraštruktúra len povrch. Skutočná práca je v službách, na ktorých aplikácie stoja, v dátach, ktoré sa musia preniesť bez strát, a v identitách a prístupoch, ktoré sa nesmú rozliať mimo kontrolu.

Z praxe to vyzerá takto – keď firma povie „zmeníme cloud“, v skutočnosti rieši viacero paralelných migrácií naraz. Niektoré sú viditeľné hneď, iné sa ozvú až pri cutovere alebo po ňom, keď začnú padať integrácie, chýbajú logy, mení sa latencia alebo sa ukáže, že niečo bolo naviazané na konkrétny managed komponent.

Najväčší vendor lock-in preto zvyčajne nevzniká na úrovni virtuálnych strojov, ale na úrovni služieb:

• managed databázy a dátové služby (DBaaS, cache, analytika)
• event a messaging platformy (queue, stream, pub-sub)
• identita a prístupy (IAM, SSO, roly, policies)
• secrety a kľúče (tokeny, certifikáty, KMS, secrets manager)
• API vrstva a bezpečnostné brány (API gateway, WAF, load balancing)
• observability (monitoring, logy, tracing, alerting)
• build a release reťazec (CI/CD, registry, artefakty)

Ak stojíte na PaaS, switching je migrácia aplikácií a ich závislostí, nie len presun infraštruktúry. A to je aj dôvod, prečo sa toho firmy často boja. Nejde len o effort a peniaze. Ide o riziko výpadku, riziko incidentu počas zmenového okna a o to, či po migrácii stále vidíte, čo sa v systéme deje.

Prečo exit zvyčajne zlyhá

Väčšinou kvôli tomu, že sa do migrácie ide skôr s vierou než s pripraveným postupom. Až keď sa začne riešiť ostrý presun, ukáže sa, že „máme export“ neznamená „vieme to obnoviť“, a „máme prístupy“ neznamená „máme ich pod kontrolou“.

Najčastejšie sa to pokazí na týchto miestach:

• Export je formálny, nie obnoviteľný. Dáta síce viete vyexportovať, ale neviete z nich postaviť funkčný systém. Chýbajú schémy, metadata, konfigurácie, väzby, alebo je export v formáte, ktorý sa v cieľovom prostredí nedá rozumne použiť.
• Dáta sú roztrúsené v službách, ktoré nikto nemá zmapované. Hlavná databáza je len začiatok. Objektové úložiská, fronty, cache, logy, secrets, konfigurácie, eventy, artefakty.
• Nie je definované, čo je minimálne funkčné po migrácii. Tím rieši stovky detailov, ale chýba jasná odpoveď: čo musí byť po cutovere funkčné v prvých hodinách a čo môže prísť neskôr. Bez toho sa migrácia buď zbytočne natiahne, alebo sa riskne príliš veľa naraz.
• IAM a secrety sú naviazané na konkrétny cloud. Roly, policies, servisné identity, integračné účty, kľúče, tokeny, certifikáty. Keď sa to nerobí systematicky, skončíte s dočasnými výnimkami a prístupmi „len na chvíľu“, ktoré potom ostanú.
• Stratíte dohľadateľnosť. Logy, audit trail a monitoring ostanú v starom prostredí alebo sa prenesú neúplne. Po migrácii síce niečo beží, ale neviete to spoľahlivo pozorovať, vyšetrovať incidenty ani preukázať, kto čo urobil.

Technické témy, ktoré musí mať IT pokryté

Switching sa láme na detailoch. Keď nie sú jasné, migrácia sa zastaví hneď na začiatku: pri prvom exporte, prvom chýbajúcom oprávnení alebo prvej integrácii, ktorá sa po presune nerozbehne.

Toto sú základné oblasti, ktoré treba mať dopredu vyriešené.

A) Dáta a exporty

• Kde všade dáta vznikajú a kde končia, nielen „hlavná DB“.
• V akom formáte ich viete dostať von a či z toho viete postaviť systém späť.
• Či export obsahuje aj schémy, indexy, konfigurácie a metadáta.
• Ako riešite šifrovanie a kľúče, aby ste dáta vedeli preniesť alebo bezpečne znovu vytvoriť.
• Čo spravíte s auditnými a prevádzkovými logmi, aby ste dodržali retenciu.

Skúška, ktorá rýchlo ukáže stav: Viete z exportu postaviť systém do funkčného stavu v novom prostredí? Ak nie, export je len formálny výstup.

B) Závislosti na PaaS

Spíšte si služby, na ktorých ste reálne závislí:

• Managed DB, object storage, queue, event bus.
• API gateway, WAF, CDN.
• Secrets manager, KMS, HSM.
• Monitoring, logy, tracing.

Ku každej si doplňte: Čím to nahradíte po migrácii, ako sa to presunie, čo sa stane, keď to vypadne, a kto to vlastní (doručí).

C) Identita, prístupy a tajomstvá

Veľa migrácií padne na IAM. Minimum:

• Účty a roly, ktoré musia existovať po migrácii.
• Mapovanie rolí medzi poskytovateľmi.
• Rotácia kľúčov a tajomstiev.
• Servisné identity pre integrácie.
• Audit zmien oprávnení a prístupov.

Počas migrácie narastie počet dočasných prístupov. Ak ich neriadite, vytvárate si slabé miesto.

Konkrétny scenár: Integrácie bežia na dlhodobo platných tokenoch a účtoch bez revízie. Útočník nemusí kompromitovať zariadenie. Stačí mu token a exportuje dáta cez „oficiálne“ rozhranie.

D) Sieť a konektivita

• DNS, certifikáty, TLS, reverse proxy.
• Privátne prepojenia a peering.
• Odchádzajúci prenos dát z cloudu (egress) a pravidlá na firewalle.
• Latencia, priepustnosť, limity a kvóty.

E) Observability a incident response

• Čo presne znamená „všetko je zelené“ po migrácii.
• Ako zabezpečíte logy a audit trail aj po switchingu.
• Postup pre rollback, keď sa cutover nepodarí.

Exit runbook: Šablóna, ktorú viete použiť hneď

Exit runbook má hodnotu len vtedy, keď je odskúšaný. Kým ho netestujete na vzorke, pracujete s odhadmi. A pri switchingu sú odhady presne to, čo zvyčajne zlyhá.

1. Cieľ a rozsah: Ktoré služby migrujete, čo je mimo scope, definícia „hotovo“ a „minimálne funkčné“.
2. Architektúra pred a po: Závislosti, kritické služby, dátové toky.
3. Export a migrácia dát: Zdroje dát, formáty, obnova v novom prostredí, kontrola konzistencie.
4. IAM a secrety: Roly, účty, integrácie, rotácia kľúčov, prístupové pravidlá počas migrácie.
5. Test: Vzorka, meranie času, úzke miesta.
6. Cutover: Časové okno, DNS a routing, komunikácia, zodpovednosti.
7. Rollback: Kedy ho spúšťate, návrat, dopad na dáta.
8. Po migrácii: Zrušenie dočasných prístupov, audit práv, kontrola logov a alertov, lessons learned.

Kontrola: 10 bodov pre CIO a CISO

• [ ] Máme zoznam dátových úložísk a tokov.
• [ ] Vieme obnoviť systém z exportu do funkčného stavu.
• [ ] Máme zoznam PaaS závislostí a alternatív.
• [ ] IAM roly sú zdokumentované a mapovateľné.
• [ ] Secrety a kľúče majú plán rotácie pri migrácii.
• [ ] DNS, certifikáty a routing majú pripravený cutover.
• [ ] Máme test migrácie na vzorke s reálnymi metrikami.
• [ ] Monitoring a logy sú pripravené vopred.
• [ ] Rollback plán je napísaný a dá sa vykonať.
• [ ] Po migrácii vieme preukázať audit trail a zvládnuť incident.

Záver

Pri migrácii sa nemení len infraštruktúra. Menia sa prístupy, integračné identity, secrety, logovanie a incident response. Preto má zmysel mať exit runbook, ktorý rieši IAM, secrety a audit trail rovnako tvrdo ako dáta.

Data Act posúva cloud switching z marketingového sľubu do oblasti, kde sa očakáva reálna vykonateľnosť a menej umelých bariér zo strany poskytovateľov. To však nepomôže, ak si najväčšie bariéry necháte vo vlastnej architektúre a prevádzke.

Začnite inventúrou: kde sú dáta, ktoré PaaS služby sú kľúčové, a ako sú naviazané identity a integračné účty. Potom urobte test na vzorke. Až ten ukáže reálne časy, úzke miesta a riziká.