Migrace ze starého systému bez odstavení provozu

Starý systém funguje. Nikdo mu už nerozumí, dodavatel na něj nemá kapacitu, na nové požadavky se čeká měsíce — ale funguje. A právě proto je jeho výměna tak nepříjemná: nejde o to postavit nové, ale odstřihnout staré, aniž by se firma zastavila.

Představa je přitažlivá: přes víkend se přepne, v pondělí se pracuje v novém. Problém je, že chybu objevíte až v pondělí ráno — a to už obvykle není kam se vrátit, protože do nového systému začaly padat objednávky.

Velký třesk má smysl jen u malého systému s málo daty a málo uživateli. U čehokoli většího platí, že riziko roste rychleji než úspora času.

Praktičtější je rozdělit systém na části a přesouvat je po jedné. Pořadí určuje pravidlo: začněte tím, co má nejméně vazeb na zbytek.

Typicky to bývá číselník nebo modul, který data hlavně čte — například přehledy a reporty. Provoz na nich nestojí, takže případná chyba nikoho nezastaví, a zároveň se na nich ověří, jestli nový systém vidí data správně.

Až potom přicházejí moduly, které data zapisují, a nakonec ty, na kterých stojí denní provoz.

Každý krok musí mít definovaný stav, ke kterému se lze vrátit. Ne teoreticky — vyzkoušený. Stejně, jak to popisujeme u zálohování a obnovy firemní aplikace: obnova, která se nikdy netestovala, není plán, ale naděje.

Během přechodu bude nějaký čas běžet obojí. To je nepříjemné, ale nevyhnutelné — a dá se to zvládnout, pokud jsou předem jasné dvě věci.

Kdo je zdroj pravdy. Pro každý typ dat musí být určeno, který systém je závazný. Ne „oba", protože pak vzniknou dvě verze skutečnosti a nikdo neví, která platí.

Jak se data synchronizují. Jednosměrně, dokud to jde. Obousměrná synchronizace je řádově náročnější a je v ní potřeba řešit konflikty. Jak se takové propojení staví, rozebíráme v článku o propojení firemních systémů přes API.

Toto se podcení skoro vždy. Ve starém systému jsou roky výjimek: záznamy bez povinných polí, duplicitní zákazníci, data ve třech formátech, poznámky v poli pro telefonní číslo.

Nový systém má přísnější pravidla a většinu z toho odmítne. Jsou tři možnosti a je třeba vybrat vědomě: data vyčistit (nejlepší, nejdražší), pravidla nového systému uvolnit (rychlé, přenese nepořádek), nebo problémové záznamy nemigrovat a nechat je dostupné jen ke čtení v archivu.

Osvědčilo se migrovat nanečisto opakovaně — každý týden celý objem dat, s protokolem o tom, co neprošlo a proč. Seznam chyb se tak zkracuje postupně, místo aby se celý objevil týden před spuštěním. Užitečný je i samostatný krok čištění firemních dat ještě před migrací.

• Integrace třetích stran. Na starý systém bývá napojeno víc věcí, než si kdokoli pamatuje — banka, e-shop, doprava, reporty pro mateřskou firmu.
• Tiskové sestavy. Faktury a dodací listy musí vypadat stejně, jinak se ozvou zákazníci i účetní.
• Práva uživatelů. Přenášet se mají role, ne nastavení jednotlivců; je to příležitost uklidit, kdo na co vidí.
• Historie. Je třeba předem rozhodnout, kolik let jde do nového systému a co zůstane v archivu.

Technicky vydařená migrace se dá pokazit tím, že si ji tým neosvojí. Pomáhá zapojit několik lidí z provozu už během testování — ne jako školení, ale jako reálnou práci v novém systému vedle starého. Najdou věci, které v zadání nikdy nebyly, a zároveň se z nich stanou ti, kterých se kolegové ptají po spuštění.

Stojí za to říct i tohle: pokud starý systém pokrývá potřeby a jediným problémem je, že je starý, migrace nemusí dávat smysl. Rozumnější bývá obalit ho rozhraním a nové věci stavět vedle něj.

Pokud zvažujete výměnu a chcete si projít rizika dřív, než se rozhodnete, napište nám. Jak přistupujeme k vývoji na míru a co jsme podobně řešili, najdete v referencích.