Kako smanjiti rizik pri migraciji podataka i integracija

Kad tvrtka mijenja stari sustav, česta je pogreška misliti da je najteži dio novo sučelje. U praksi najviše problema obično nastaje pri migraciji podataka i integracija.

Sučelje se može dizajnirati i testirati prilično uredno. Podaci iz starog sustava, međutim, često sadrže duplikate i nedosljedne formate, poslovna su pravila skrivena u stotinama iznimaka, a integracije nitko nije dokumentirao. Zato migraciju treba planirati kao projekt upravljanja rizikom, a ne kao puki tehnički prijenos.

Zašto migracija često krene po zlu

Problem rijetko leži u samoj tehnologiji. Stari se sustav često godinama koristi bez jasne dokumentacije, pa podaci i pravila s vremenom postanu razumljivi samo ljudima koji s njima dugo rade.

Kad takav sustav mijenjate, obično se pojave tri vrste rizika:

• podaci nisu čisti
• integracije nisu dobro poznate
• poslovna pravila nisu u potpunosti zapisana

Ako ih ne prepoznate na početku, lako se dogodi da novi sustav tehnički radi, ali poslovno ne daje iste rezultate kao stari.

Prvo: mapirati podatke

Prvi je korak razumjeti koje podatke uopće imate:

• koji entiteti postoje
• kako su povezani
• gdje su duplikati
• koji su podaci obvezni
• gdje nedostaju vrijednosti
• koja se polja koriste, a koja ne

Bez toga migracija samo prenosi probleme iz jedne baze u drugu.

Drugo: razumjeti poslovna pravila

Podaci sami po sebi nisu dovoljni. Treba razumjeti i kako se koriste, na primjer:

• kako se izračunava status
• što se događa kad podatak nedostaje
• koja pravila vrijede za eskalaciju
• što se smije mijenjati, a što ne
• kako korisnici tumače stare vrijednosti

Često se pokaže da jedno polje, ovisno o kontekstu, ima nekoliko različitih značenja. Ako se to ne analizira dovoljno temeljito, migracija će upravo tu pogriješiti.

Treće: provjeriti integracije

Integracije su među najrizičnijim dijelovima migracije jer se na njih često zaboravi sve dok ne prestanu raditi.

Treba provjeriti:

• koji sustavi šalju podatke u stari sustav
• kamo stari sustav šalje podatke
• koje integracije rade automatski
• gdje postoje ručni koraci
• koji se formati podataka koriste

Ako za neku integraciju ne znate, to ne znači da ne postoji. Obično ju je netko davno postavio, a dokumentacija nikad nije napisana.

Fazni pristup sigurniji je od zamjene u jednom potezu

Najsigurnije je migrirati fazno. Umjesto da stari sustav ugasite u jednom danu (tzv. big bang pristup), zamjenjujete ga u više koraka.

Uobičajen je ovaj redoslijed:

1. analiza i mapiranje
2. izdvajanje kritičnih tokova
3. pilot ili manji modul
4. paralelni rad
5. provjera podataka i rezultata
6. postupni prijelaz korisnika
7. gašenje starog dijela sustava tek kad novi radi stabilno

Takav pristup traje nešto dulje, ali znatno smanjuje rizik od prekida poslovanja.

Kako testirati migraciju podataka

Testiranje migracije ne smije se svesti na dojam da je sve na mjestu. Treba provjeriti:

• broj zapisa prije i poslije migracije
• popunjenost polja i obvezne vrijednosti
• reference i relacije
• poslovno kritične iznimke
• nasumične uzorke stvarnih podataka

Ako je moguće, usporedite rezultate starog i novog sustava za isti scenarij. Tako se brzo vidi gdje se razlikuju.

Kako smanjiti rizik integracija

Kod integracija svaka strana mora imati jasno definirana očekivanja. To uključuje:

• format i strukturu podataka
• pravila za obradu pogrešaka
• vremenska ograničenja (timeout) i ponovne pokušaje (retry)
• verzioniranje API-ja
• rezervne scenarije (fallback)

Integracija testirana nasumce nosi velik rizik. Kad je provjerena na konkretnim slučajevima i graničnim uvjetima, prijelaz je puno sigurniji.

Što treba dokumentirati prije migracije

Prije nego što krenete u izvedbu, dobro je imati zapisano:

• koje se tablice ili moduli migriraju
• koji se podaci preslikavaju i na koji način
• koje integracije postoje
• koja su poslovna pravila kritična
• kako se vraća prethodno stanje (rollback) ako nešto pođe po zlu
• tko odobrava prijelaz na novi sustav

To može izgledati kao administracija, ali upravo takav zapis projekt čuva od vrlo skupih pogrešaka.

Najčešće pogreške pri migraciji podataka i integracija

Neki se problemi ponavljaju gotovo uvijek:

• podaci se migriraju bez prethodnog čišćenja
• integracije se testiraju prekasno
• ne zna se koja su polja doista kritična
• stari se sustav gasi prerano
• korisnici nisu uključeni u provjeru rezultata
• ne postoji plan za slučaj pogreške

Zbog takvih se propusta migracija se čini uspješnom sve dok se stvarni korisnici ne počnu oslanjati na novi sustav.

Kako izgleda dobar prijelaz

Dobar prijelaz obično ima ove značajke:

• stari i novi sustav neko vrijeme rade usporedno
• podaci se uspoređuju prije konačnog gašenja
• korisnici sudjeluju u pilot-fazi
• integracije su testirane na stvarnim scenarijima
• postoji jasna kontaktna osoba za podršku

Uz takav pristup migracija se odvija kontrolirano i ne remeti svakodnevni rad.

Povezane teme

Više o tome kako pristupamo zamjeni starih sustava pročitajte na stranici o migraciji legacy sustava.

Ako razmišljate i o sljedećim koracima, pogledajte stranice o:

• izradi web aplikacija
• održavanju softvera
• AI rješenjima

Što dalje

Migracija podataka i integracija često je najrizičniji dio modernizacije i ne može se rješavati usput. Ako je od početka dokumentirate, testirate i provodite fazno, rizik je znatno manji.

Ako želite proći kroz postojeći sustav i procijeniti gdje je rizik najveći, javite nam se.

Česta pitanja

Moramo li migrirati sve odjednom?

Ne. U većini je slučajeva sigurnije migrirati fazno, po modulima ili procesima.

Što je najvažnije kod migracije podataka?

Kvaliteta i dosljednost podataka te provjera jesu li poslovno kritične vrijednosti ispravno prenesene.

Kako znati da je migracija uspješna?

Kad novi sustav daje jednake ili bolje poslovne rezultate, a korisnici u njemu rade bez zastoja.

Što ako integracija nije dokumentirana?

Tada je najprije treba otkriti analizom postojećeg sustava i njegovih zapisa (logova) te razgovorom s ljudima koji ga koriste.