„Přesuneme to do cloudu" zní jednoduše. U core systémů je to změna provozu, ne jen infrastruktury. Tohle je blueprint, jak migrovat bez big-bangu, bez výpadků a bez ztráty dat.

5 principů

1 Nejdřív stabilizujte a měřte

Nemigrujte nestabilní systém. Pokud nemáte monitoring, nevíte, jak systém funguje teď — a nepoznáte, jestli po migraci funguje hůř. Prvním krokem je observability, ne Terraform.

Změřte baseline: latence, throughput, error rate, závislosti mezi komponentami. Zmapujte bottlenecky. Identifikujte, co je single point of failure. Tohle potřebujete vědět před tím, než cokoli přesunete.

• Monitoring a alerting na všech klíčových komponentách (APM, logs, metriky)
• Mapa závislostí: co na čem závisí, kdo volá koho, jaké jsou kritické cesty
• Baseline metriky: P50/P95 latence, requests/s, error rate, availability
• Identifikace bottlenecků a SPOF před migrací, ne po ní

2 Série malých přepnutí, ne big bang

Big bang migrace je hazard. Pokud přesunete všechno najednou a něco selže, nemáte kam se vrátit. Správný přístup: integrační vrstva mezi on-prem a cloudem, postupný přesun komponent, canary rollout.

Každé přepnutí je malé, reverzibilní a měřitelné. Přesuňte jednu službu. Sledujte metriky. Porovnejte s baseline. Pokud je vše OK, pokračujte. Pokud ne, rollback.

• Integrační vrstva (API gateway, service mesh) umožňuje směrovat traffic
• Canary: 5 % trafficu na cloud, 95 % on-prem → postupně zvyšujte
• Každá komponenta má vlastní migrační plán a rollback postup
• Nikdy nemigrujte dvě závislé komponenty současně

3 Data jsou nejtěžší část

Kód přesunete snadno. Data ne. Konzistence dat mezi on-prem a cloudem je nejtěžší problém celé migrace — a nejčastější příčina selhání.

Dual-write (zápis do obou prostředí současně) zní jako řešení, ale přináší vlastní problémy: conflict resolution, eventual consistency, rollback. Potřebujete auditní stopu a jasný decision tree pro každý datový konflikt.

• Definujte „source of truth" pro každý datový objekt v každé fázi migrace
• Dual-write: jasná strategie pro conflict resolution
• Auditní stopa: každý zápis zalogovaný s timestampem a zdrojem
• Rollback dat: jak vrátit data do konzistentního stavu
• Testujte data migraci na kopii produkčních dat, ne na mockech

4 Release proces je součást migrace

Migrace není jednorázový projekt — je to série releasů. A každý release potřebuje: staging prostředí, automatizované testy, canary deploy a rollback plán. Pokud nemáte CI/CD pipeline, vybudujte ji před migrací — ne během.

• CI/CD pipeline pokrývající oba prostředí (on-prem i cloud)
• Staging: testovací cloud prostředí zrcadlící produkci
• Canary deploy: nová verze na malém % traffiku
• Automated smoke tests po každém deployi
• Rollback: one-click návrat na předchozí stav (infra + data)

5 DR a incident proces nejsou „až potom"

Disaster recovery a incident response musíte mít od prvního dne hybridního provozu. Máte dvě prostředí, dvě sady komponent a nové failure modes — a potřebujete vědět, co dělat, když něco spadne.

Definujte RTO (Recovery Time Objective) a RPO (Recovery Point Objective) pro každou komponentu. Napište runbooky. Otestujte je. Runbook, který nikdo netestoval, je jen dokument.

• RTO: za jak dlouho musí být služba obnovená (minuty? hodiny?)
• RPO: kolik dat si můžete dovolit ztratit (nula? hodina?)
• Runbooky pro každý scénář: výpadek cloudu, výpadek on-prem, datová nekonzistence
• DR testy: pravidelné, plánované, s měřením RTO/RPO
• Eskalační řetěz: kdo rozhoduje, kdo komunikuje, kdo fixuje

4 fáze migrace

Fáze A Připravenost

Než přesunete první komponentu, potřebujete infrastrukturní základ. Observability, CI/CD pipeline a IAM (Identity & Access Management) v cloudu.

• Cloud account setup: networking, VPN/peering k on-prem, security groups
• Observability stack v cloudu: stejné dashboardy jako on-prem (Grafana, Datadog, ELK)
• CI/CD pipeline schopná deployovat do obou prostředí
• IAM: role, policies, service accounts — principle of least privilege
• Baseline testy: validujte, že cloud prostředí funguje před migrací

Fáze B Hybridní období

Propojení on-prem a cloudu. První bezstavové komponenty migrují. Traffic se routuje přes integrační vrstvu — zatím většina zůstává on-prem.

• API gateway / service mesh jako integrační vrstva
• Migrace prvních bezstavových služeb (stateless API, frontend, worker)
• Canary rollout: 5 → 10 → 25 → 50 → 100 % traffiku
• Monitoring porovnání: cloud vs. on-prem latence, error rate
• Rollback test: ověřte, že přepnutí zpět na on-prem funguje

Fáze C Postupné přepínání

Stavové služby a databáze. Tady je migrace nejtěžší — data, konzistence, dual-write. Každá komponenta má vlastní plán, vlastní timeline, vlastní rollback.

• Migrace stavových služeb po jedné — nikdy dvě závislé najednou
• Data migrace: replikace → dual-write → přepnutí source of truth → cleanup
• Performance testy po každé migrované komponentě
• Load testy: simulujte produkční zátěž na cloud instanci
• Komunikace se stakeholdery: kdo ví, co se děje a kdy

Fáze D Konsolidace

Všechno běží v cloudu. Teď přichází úklid: vypnutí on-prem, optimalizace nákladů, finální DR testy a dokumentace.

• Decommission on-prem: postupné vypínání starých instancí
• Cost optimization: right-sizing, reserved instances, spot instances
• Finální DR test: full failover, měření RTO/RPO
• Dokumentace: aktualizované runbooky, architektonické diagramy, playbooks
• Retrospektiva: co fungovalo, co ne, lessons learned pro příští migraci