Migrace aplikací do cloudu s řízeným přechodem

Kdy současný provoz potřebuje změnu

Signály, že samotná údržba už nestačí

Aplikaci je stále obtížnější upravovat

Starší komponenty, chybějící dokumentace nebo znalost soustředěná u několika lidí prodlužují každou změnu.

Infrastruktura omezuje další provoz

Současné prostředí komplikuje rozšíření do dalších zemí, zvyšování kapacity nebo pravidelné nasazování nových verzí.

Napojení stojí na nepodporovaných rozhraních

Datové přenosy závisejí na lokálních souborech, starších knihovnách nebo ručních mezikrocích, které se obtížně kontrolují.

Za provoz není jasná odpovědnost

Není určené, kdo řeší aktualizace, zálohy, obnovu, přístupy a náklady jednotlivých částí systému.

Jak připravujeme migraci

Rozhodnutí vychází z konkrétní aplikace, jejích dat a provozu

Vlastní cesta pro každý systém

Někde stačí změnit provozní prostředí. Jinde je potřeba upravit platformu nebo přepsat část aplikace, která další rozvoj omezuje.

Používané funkce a provozní pravidla
Technické a licenční závislosti
Požadovaná dostupnost a kapacita
Cílový způsob provozu

Data a závislosti před první změnou

Nejdřív zmapujeme databáze, soubory, integrace, uživatelské role a části infrastruktury, na kterých aplikace závisí.

Rozsah převáděných dat a historie
Mapování a validační kontroly
Napojení na okolní systémy
Identity, role a oprávnění

Přechod pod kontrolou

Připravíme pořadí etap, kontrolní body a způsob ověření dat i kritických pracovních scénářů před přepnutím a po něm.

Přijatelná délka odstávky
Odpovědné osoby a potvrzení výsledku
Podmínky pokračování nebo zastavení
Návratový postup podle možností systému

Předání do běžného provozu

Před spuštěním určíme odpovědnost za monitoring, aktualizace, zálohy, obnovu a další rozvoj.

Provozní dokumentace a přístupy
Monitoring kritických částí
Zálohovací a obnovovací postup
Dohodnutý model následné podpory

Přesun, úprava platformy nebo přepis

Stejný postup nefunguje pro každou aplikaci. Systém s podporovanými komponentami může změnit provozní prostředí bez zásahu do hlavních funkcí. Aplikace závislá na starých knihovnách nebo lokálních zařízeních potřebuje před přesunem úpravy.

Pokud současný kód brání bezpečné údržbě, integracím nebo dalšímu rozvoji, může být součástí migrace jeho postupný nebo úplný přepis. Rozsah určujeme podle funkcí, které lidé skutečně používají, datových vazeb a možností cílového prostředí.

Cloudovou platformu a konkrétní služby vybíráme až nad těmito požadavky. Samotná změna poskytovatele nevyřeší omezení, která zůstávají uvnitř aplikace.

Přepis starší aplikace do současného prostředí

Před přepisem mapujeme používané funkce, provozní pravidla, databázi, integrace a závislosti na operačním systému. Tím oddělíme skutečné potřeby provozu od částí, které už nikdo nepoužívá.

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ů.

Každý ze sedmi trhů má vlastní instanci s lokálními úpravami. Přechod proto probíhal řízeně po jednotlivých trzích a po nasazení jsme navázali provozní podporou a dalším rozvojem.

Přechod dat a provozu

Před migrací dohodneme, která data a historie se převádějí, jak se mapují do cílového modelu a podle čeho se výsledek potvrdí. Kontroly mohou zahrnovat počty záznamů, vazby, zůstatky i vybrané pracovní scénáře.

Způsob přepnutí vychází z kritičnosti systému a přijatelné odstávky. Pokud architektura dovoluje přechod po trzích, modulech nebo uživatelských skupinách, připravíme etapy tak, aby každá měla vlastní kontrolní body.

Dočasný souběh a návrat ke staré verzi jsou možné jen tehdy, když lze spolehlivě řídit synchronizaci dat. Jejich použití proto stanovíme v migračním plánu podle možností konkrétního systému.

Migrace končí předáním provozu

Po přepnutí kontrolujeme kritické funkce, integrace a provozní metriky. Dokumentace musí popsat architekturu, přístupy, nasazování změn, zálohy a postup obnovy.

Součástí předání je také jasné rozdělení odpovědnosti mezi interní tým, dodavatele aplikace a provozní správu. Po potvrzení těchto bodů může systém přejít do běžného režimu.

Pokud má TechOne převzít také monitoring, pravidelnou údržbu, zálohy nebo řešení incidentů, navazuje samostatná správa cloudu a infrastruktury.

Jak probíhá migrace

Od zmapování současného systému po stabilní provoz v novém prostředí

01

Zmapování systému

Popíšeme používané funkce, data, integrace, technické závislosti a požadavky na současný provoz.

02

Migrační rozhodnutí

Určíme, co lze přesunout, co potřebuje úpravu nebo přepis a jak má vypadat cílové prostředí.

03

Příprava dat a přechodu

Připravíme mapování, validační kontroly, pořadí etap, odpovědnosti a podmínky přepnutí.

04

Realizace po etapách

Provedeme schválené změny, převedeme data a před každým přepnutím ověříme dohodnuté scénáře.

05

Stabilizace a předání

Po spuštění zkontrolujeme provoz, předáme dokumentaci a nastavíme odpovědnost za další správu a rozvoj.

Migrace v praxi

Helvetia: přepis Visual Basic backoffice do .NET a přechod sedmi trhů do Azure

HELVETIA

E-commerce

3+ roky

Délka spolupráce

7

Země

Často kladené otázky

Musí se při migraci celá aplikace přepsat?

Ne vždy. U podporované aplikace může stačit změna provozního prostředí nebo úprava vybraných komponent. Přepis dává smysl tam, kde současný kód brání údržbě, integracím nebo dalšímu rozvoji. Rozhodnutí vychází z analýzy používaných funkcí, dat a závislostí.

Dokážete přepsat starší aplikaci ve Visual Basicu?

Ano. Pro Helvetii jsme přepsali celý backoffice systém z Visual Basicu do C# .NET a nasadili ho do Azure App Service a SQL Database pro sedm evropských trhů. Přepis a migrace trvaly 18 měsíců.

Co se stane s daty při migraci?

Předem dohodneme rozsah dat a historie, mapování do cílového modelu a kontroly výsledku. Původní data chrání zálohovací a návratový postup připravený podle možností zdrojového systému. Převedená data potvrzují odpovědní uživatelé podle dohodnutých kontrol.

Omezí migrace běžný provoz?

Dopad závisí na kritičnosti systému, datových vazbách a přijatelné odstávce. Přechod může proběhnout v servisním okně nebo po ucelených etapách, pokud to systém umožňuje. Konkrétní pořadí, kontrolní body a odpovědnosti jsou součástí migračního plánu.

Jak se určuje cena a harmonogram migrace?

Rozsah ovlivňuje stav aplikace, počet závislostí a integrací, objem a kvalita dat, potřebné úpravy i způsob přechodu. Po vstupní analýze rozdělíme práci do etap a připravíme jejich odhad. Provozní náklady cílového prostředí počítáme zvlášť podle zvolené architektury a očekávané zátěže.

Kdo se o prostředí stará po migraci?

Při předání určíme odpovědnost za monitoring, aktualizace, zálohy, obnovu a další rozvoj. Provoz může převzít interní tým, současný správce nebo TechOne. Dlouhodobou podporu řešíme v rámci Správy cloudu a infrastruktury.

Související služby

Další služby, které by vás mohly zajímat