Ztracené vazby a neviditelné vztahy

Jednou z nejčastějších komplikací jsou vazby mezi entitami, které ve starém systému fungují „nějak“, ale nikde nejsou zdokumentované. V jednom projektu jsme řešili migraci dokumentů, které měly uloženy nejen metadata, ale také dynamická oprávnění, která se odvíjela od obchodní logiky v systému – ta ale nebyla v databázi vůbec vidět. V novém systému pak dokumenty „zmizely“ pro některé uživatele – ne proto, že chyběly, ale protože nebyla přenesena správná oprávnění.

Vazby se přitom nemusí týkat jen přístupových práv – často jde o vnitřní logiku mezi položkami, která vypadá jako „šedá zóna“. V jednom případě jsme narazili na to, že historie schválení byla vnořená do JSONu v jedné tabulce, ale nový systém vyžadoval samostatnou entitu.

Validace, na kterou se zapomene… a pak to spadne

Další opakovaný motiv: validace a kontrolní mechanismy. U některých typů projektů (zejména ve veřejné správě nebo pojišťovnictví) jsme viděli, jak absence validace způsobí, že sestavy přestanou fungovat, výpočty selžou, nebo se rozbije napojení na reportingové systémy.

Problém je, že validace se často bere jako něco, co „doděláme za běhu“. Jenže právě na ní stojí důvěryhodnost výsledků, a to i z právního pohledu. Po nasazení do produkce už bývá pozdě něco „dolaďovat“.

Migrace pohyblivých dat? Jen v krajním případě

Jedna z největších pastí, kterou v projektech občas vidíme, je snaha migrovat živá data – tedy data, která se během projektu mění: transakce, otevřené workflow, aktivní požadavky. Teoreticky to možné je. Prakticky ale každý takový pokus znamená neúměrné náklady, riziko chyb a velmi často i prodloužení projektu o desítky procent.

Většinou pomáhá jasné rozhodnutí: co migrujeme jako statická data (uzavřené případy, historické záznamy), co musíme před migrací uzavřít, a co raději přesměrujeme na nové řešení s novým ID nebo vazbou. Hybridní režim s přechodným provozem bývá méně riskantní než pokus o „dokonalý převod všeho“.

Historická data, která už nikdo nepotřebuje? Omyl.

Často slýcháme: „To jsou stará data, ta už nejsou důležitá.“ Jenže právě historie je často největším právním a auditním rizikem. Případy, které už nejsou aktivní, ale budou se jednou kontrolovat. Smlouvy, které mají dlouhou právní lhůtu. Události, které sice neprobíhají, ale definují návaznosti, limity nebo odpovědnosti.

V některých sektorech (např. ve financích nebo zdravotnictví) je zkrátka nemožné brát historii na lehkou váhu.

Co funguje – a co se osvědčilo

Zkušenost z většiny projektů je jednoznačná: bez analýzy datového modelu na začátku se dobrý scénář migrace navrhuje těžko. A to platí i u systémů, které nemají žádnou dokumentaci, nebo u starších monolitů s netypickými strukturami. Reverzní inženýrství, logická mapa dat, modelování výjimek – to vše se nakonec vyplatí.

U některých projektů jsme využili i kombinaci SQL skriptů, exportních služeb a vizualizace datových toků pro lepší pochopení. Důležitá je i testovací strategie – ideálně s přechodným provozem a fallback plánem.

Pro ty, co chtějí jít víc do hloubky

Pokud vás problematika migrací dat zajímá více do hloubky, doporučujeme třeba článek „Why Data Migration Projects Fail“ od Billa Inmona – známého „otce datového skladu“ – který se věnuje právě neviditelným nástrahám u datových migrací.
📖 Odkaz na článek

Zajímavé postřehy nabízí i pravidelné studie společnosti Gartner, které zmiňují, že až 83 % projektů s migrací dat překročí původní časový nebo rozpočtový rámec právě kvůli nepodceněným (nebo neznámým) vazbám v datech.

Na závěr

Migrace dat není jen technický krok. Je to vstupenka do toho, jak celý systém funguje – nebo někdy nefunguje. A čím dřív se začneme ptát na to, co vlastně přesouváme, tím větší šanci máme, že to bude fungovat správně – a že se projekt nezastaví u nečekaných souvislostí.