Adatmigráció: hogyan költöztesd át az üzleti adatokat?

Új CRM vagy üzleti rendszer bevezetése előtt állsz? Gyakorlati terv az adattisztításhoz, próbamigrációhoz, ellenőrzéshez és a biztonságos átálláshoz.

Buda Sándor · 2026-09-19

Az új üzleti rendszer már elkészült, a bemutatón minden működik, mégis az átállás előtt derül ki a legfontosabb kérdés: mi lesz a régi ügyféladatokkal, nyitott rendelésekkel és dokumentumokkal? Az adatmigráció sikere azon múlik, hogy az adatok az új helyükön is ugyanazt jelentik-e, és folytatható-e velük a napi munka.

Ez az útmutató azoknak a cégvezetőknek és projektgazdáknak szól, akik CRM-et, ügyviteli rendszert vagy egyedi üzleti szoftvert váltanak. Végigvezet a költöztetés üzleti döntésein, a próbaimporton, az ellenőrzésen és az éles átállás feltételein. A cél egy olyan terv, amelyből kiderül, ki mit fogad el, mikor lehet továbblépni, és mi történik eltérés esetén.

Mit jelent az adatmigráció egy üzleti rendszerben?

Az adatmigráció adatok átvitele egy régi környezetből egy újba, szükség esetén tisztítással és átalakítással. Lehet egyszerű import, de több forrás összevonásakor önálló projektfeladat. Egy ügyfélhez például kapcsolattartók, telephelyek, ajánlatok, rendelések és megjegyzések tartozhatnak. Ha csak az ügyféltörzs érkezik meg, a vállalkozás munkájának jelentős része még hiányozhat.

A migráció és a tartós integráció eltérő feladat. A migráció egy meghatározott átállási állapotot hoz létre; az integráció később is adatot cserélő rendszereket köt össze. A költözés idejére szükség lehet átmeneti szinkronizálásra, de előre rögzíteni kell, mikor szűnik meg a régi rendszer adatgazda szerepe.

Amikor az új folyamatokhoz egyedi üzleti szoftver készül, az adatköltözést már a tervezésbe érdemes beemelni. A meglévő adatok minősége és kapcsolatai ugyanis befolyásolhatják az új rendszer mezőit, keresőit és jogosultságait is.

Először a költöztetés határát döntsd el

A „mindent hozzunk át” kérés látszólag biztonságos, mégis feleslegesen bonyolíthatja az indulást. Különítsétek el a napi működéshez szükséges aktív adatokat, a későbbi visszakereséshez szükséges előzményeket és a döntésre váró állományokat. Az archívum lehet külön, kereshető megoldás, ha a felhasználók onnan is elérik a szükséges információt.

Írjátok le azt is, mi marad ki. Egy régi tesztügyfél vagy elavult segédmező kihagyása indokolt lehet, de ezt ne az importot készítő fejlesztő találja ki. Minden adatkörhöz legyen üzleti felelős, aki megmondja, mire használják, és elfogadja a költöztetés szabályát. A megőrzésről vagy törlésről külön, a vállalkozásra érvényes követelmények alapján döntsetek.

Egy használható adatkörjegyzék

Adatkörönként rögzítsétek a forrásrendszert, a felelős személyt, a becsült mennyiséget, az új célhelyet és az elfogadás módját. A „rendelések” sor önmagában kevés. Hasznosabb megfogalmazás: minden nyitott rendelés a tételeivel, státuszával és ügyfélkapcsolatával együtt, az egyeztetett fordulónapi állapot szerint.

Az adatminőséget még az import előtt vizsgáld meg

A tisztítás nem pusztán a felesleges szóközök eltávolítása. Kiderülhet, hogy ugyanaz a partner több néven szerepel, egy kötelező azonosító hiányzik, vagy egyetlen mezőbe került a cím és a megjegyzés. Ezekre eltérő megoldás kell: automatikus javítás, kézi döntés vagy elkülönített hibajegyzék.

Ne csak a legszebb mintát nézzétek meg. Kerüljenek a vizsgálatba régi és friss rekordok, szokatlan karakterek, hosszú megjegyzések, inaktív ügyfelek, több telephellyel rendelkező partnerek és hiányos kapcsolatok. Így hamarabb kiderül, hogy az új mezőhossz, dátumkezelés vagy kötelezőség valóban megfelel-e a forrásnak.

A feltárt problémákat számszerűsítsétek a saját állományban. Hány partnernek nincs használható azonosítója? Hány rendelésnél hiányzik a kapcsolódó ügyfél? Ezek belső mérések legyenek, nem iparági becslések. A javítási feladat mellé kerüljön felelős és határidő, különben a tisztítás könnyen az élesítés előtti napra marad.

Készíts mezőtérképet és egyértelmű átalakítási szabályokat

A mezőtérkép azt írja le, hogy a régi rendszer egy adata hová kerül az újban, milyen átalakítással és milyen ellenőrzéssel. Nem elég annyi, hogy „név → név”. Ki kell derülnie, mi történik az üres értékkel, a túl hosszú szöveggel, az ismeretlen státusszal és a hibás dátummal.

Egy kitalált példában a régi „folyamatban” állapot két dolgot jelent: az ajánlat elküldését és a visszaigazolásra váró megrendelést. Az új rendszer ezt külön kezeli. A szétválasztást csak olyan kiegészítő adat alapján szabad automatizálni, amely valóban megkülönbözteti az eseteket. Ha ilyen nincs, a bizonytalan rekordok kerüljenek felülvizsgálatra.

Az azonosító fontosabb, mint az elnevezés

Az ügyfélnév megváltozhat, és két külön partner neve is lehet azonos. A régi és új rekord közötti kapcsolatot stabil azonosítópárral őrizzétek meg. A megfeleltetési táblázat segít a hibakeresésben, az ismételt importban és a kapcsolódó rendelési tételek helyes hozzárendelésében. Az összevonás szabályát külön dokumentáljátok, mert két hasonló név még nem bizonyít duplikációt.

A kapcsolatok és az üzleti jelentés is költözzön

Azonos rekordszám mellett is lehet hibás az eredmény. Elképzelhető, hogy minden rendelés megérkezett, de rossz ügyfélhez kapcsolódik. Vagy a megjegyzések átkerültek, viszont eltűnt a szerző és az időpont, így nem rekonstruálható egy egyeztetés. Ezért adatkörök helyett teljes üzleti történeteket is ellenőrizzetek.

Egy CRM-bevezetés és ügyféladat-költöztetés esetén például ugyanannak a partnernek az adatlapját, nyitott lehetőségét, kapcsolattartóját és következő feladatát együtt vizsgáljátok. A rendszer akkor segíti az értékesítőt, ha ezek az új felületen is értelmes láncot alkotnak.

A mellékletek külön figyelmet igényelnek. Nem az számít, hogy van-e fájlnév a rekordban, hanem hogy a dokumentum megnyitható-e a megfelelő jogosultsággal. A fájlkapcsolatok ellenőrzése tartalmazzon hiányzó állományt, azonos nevű dokumentumokat és több verziót is.

Válassz átállási módszert a működéshez

Egyszeri, leállási ablakkal végzett költözés

Ha a vállalkozás el tud fogadni egy előre meghatározott szünetet, az egyszeri átállás átlátható megoldás lehet. A régi rendszer írását leállítjátok, elkészül a végső export, lefut az import és az ellenőrzés, majd megnyílik az új rendszer. A szünetbe az ellenőrzést és a döntés idejét is bele kell számolni.

Fokozatos átállás vagy változáskövetés

Folyamatos működésnél szükség lehet előzetes nagy importálásra, majd az azóta történt változások átvitelére. Ez összetettebb: az új rekordok mellett a módosításokat és törléseket is kezelni kell. A párhuzamos működés során minden adatkörnél legyen világos, melyik rendszerbe szabad írni.

A választásnál a megengedett kiesés, a változások sebessége, a forrás exportképessége és a csapat rendelkezésre állása számít. A nulla leállás nem általános alapfeltétel: csak akkor vállalható, ha a teljes folyamat és a technikai környezet ezt ténylegesen támogatja.

A próbamigráció legyen megismételhető főpróba

A próba célja, hogy a valódi lépéssor hibái még ellenőrzött környezetben derüljenek ki. Ugyanazokat az átalakításokat és ellenőrzéseket futtassátok, amelyeket az éles átálláskor is használni fogtok. Jegyezzétek fel az egyes szakaszok idejét, a visszautasított rekordokat és a kézi beavatkozásokat.

Az import újrafuttatása ne hozzon létre csendben újabb példányokat ugyanabból a rendelésből. Előre döntsétek el, hogy a művelet frissít, kihagy vagy hibát jelez, ha már létező forrásazonosítót talál. A félbeszakadt futás folytatását és a hibás részhalmaz javítását külön is próbáljátok ki.

Egy Laravel-alapú üzleti alkalmazás fejlesztésekor az importhoz is tervezhető külön futtatási napló és ellenőrző felület. A lényeg a visszakövethetőség: melyik forrásból, melyik szabályverzióval, mely rekordok kerültek be, és milyen hibák maradtak nyitva.

Három szinten ellenőrizd az eredményt

Első szint: teljesség. Egyeztessétek a költöztetés körébe tartozó rekordok számát, a kihagyási listát és a kapcsolódó fájlokat. A számlálást ugyanarra a fordulónapi állapotra és ugyanazokra a szűrési feltételekre kell elvégezni, különben a különbség félrevezető lehet.

Második szint: tartalmi helyesség. Vizsgáljátok a mezőértékeket, státuszokat, dátumokat, mértékegységeket és kapcsolatokat. A forrás és cél összevetése ismert migrációs eljárás; az AWS DMS hivatalos adatellenőrzési dokumentációja is ilyen összehasonlításra épül. Az alkalmazható módszer azonban a választott eszköztől és adattípusoktól függ.

Harmadik szint: üzleti használhatóság. A munkatárs végig tud-e vinni egy valódi feladatot? Megtalálja-e az előzményt, folytathatja-e a rendelést, helyes kimutatást kap-e? Az ellenőrzött minták mellé kérjetek teljes állományra futó szabályokat is, mert néhány hibátlan adatlap nem bizonyítja az egész költözés sikerét.

Példa: nyitott megrendelések átvétele

Az alábbi helyzet szemléltető példa, nem ügyféltörténet. Egy szolgáltató cég új munkairányítási rendszerbe költözik. Az aktív ügyfeleket, nyitott megrendeléseket és kapcsolódó dokumentumokat viszi át; a lezárt munkák külön archívumban maradnak kereshetők.

A próba során a csapat észreveszi, hogy néhány munkalaphoz már nem aktív kapcsolattartó tartozik. Ahelyett, hogy automatikusan a cég központi e-mail-címére írnák át, kivétellistát készítenek. Az ügyfélkapcsolati felelős eldönti, melyik személyhez kerüljön a feladat, és az eredeti kapcsolatot előzményként megőrzik.

Az elfogadási feltétel így konkrét: minden nyitott megrendeléshez legyen érvényes ügyfélkapcsolat, felelős munkatárs és értelmezhető határidő, a dokumentum pedig megnyitható legyen. Amíg egy kritikus rendelés nem teljesíti ezt, az átállás nem tekinthető üzletileg elfogadottnak, akkor sem, ha az importprogram hibamentesen lefutott.

Az élesítéshez kell döntési pont és visszaállási terv

Az átállási forgatókönyvben legyen sorrend, felelős és megállási feltétel. Ki tiltja le a régi rendszerbe írást? Ki készíti az exportot? Ki ellenőrzi a nyitott tételeket? Ki mondja ki, hogy az új rendszer használható? Az informatikai végrehajtó és az üzleti jóváhagyó szerepe különüljön el, még ha kis csapatban szorosan együtt dolgoznak is.

A visszaállás nem pusztán egy mentési fájl megléte. Tudni kell, hogy a mentés visszatölthető-e, mennyi ideig tart a helyreállítás, és mi lesz az új rendszerben közben rögzített adatokkal. Ha az új felület már fogadott rendeléseket, azok rendezése nélkül a régi állapot visszatöltése újabb adatvesztést okozhat.

Határozzatok meg egy utolsó biztonságos döntési időpontot. Ha addig nem teljesülnek az előre rögzített feltételek, a kijelölt felelős elhalasztja az indulást vagy elindítja a kipróbált visszaállást. Így a döntést nem az éjszakai fáradtság és az addig befektetett munka mennyisége határozza meg.

Átállás előtti ellenőrzőlista

• A költöző és kimaradó adatköröket az üzleti felelősök elfogadták.
• A mezőtérkép, státuszváltások és duplikációs szabályok dokumentáltak.
• A kritikus hibák javítása megtörtént, a többi eltérésnek van gazdája.
• A próbamigráció megismételhető, futási ideje ismert.
• A forrás és cél összevetése azonos időpontra és hatókörre vonatkozik.
• A jogosultságok és dokumentumkapcsolatok ellenőrzöttek.
• Az éles átállás döntéshozója és leállítási feltételei megvannak.
• A visszaállítást kipróbáltátok, az új adatok sorsa rendezett.
• A munkatársak tudják, mikortól melyik rendszerben dolgoznak.

Mitől függ a ráfordítás, és mit kérj az ajánlatban?

A rekordok száma csak az egyik tényező. Sokszor a források eltérő logikája, a hiányzó azonosítók, az összetett kapcsolatok és a kézi tisztítás adják a munka nagyobb részét. Tíz rendezett adattábla kezelhetőbb lehet, mint egyetlen, évek alatt következetlenül kitöltött állomány. Az árat ezért konkrét adatmintára és felmért szabályokra érdemes alapozni.

Kérj külön feladatot az adatfelmérésre, a megfeleltetési tervre, az import elkészítésére, a próbakörökre és az élesítés támogatására. Derüljön ki, ki javítja a forráshibákat, mennyi üzleti egyeztetés szükséges, és hogyan kezelik a később felfedezett eltéréseket. A „migráció benne van” mondat önmagában nem elegendő teljesítési feltétel.

A csapat belső ráfordításával is számolj. Az értékesítőnek, ügyintézőnek vagy raktárosnak időt kell adni az ellenőrzésre. Ha a szakmai döntésekhez senki nem elérhető, a fejlesztő technikailag elkészülhet, miközben az üzleti átvétel továbbra is nyitott marad.

Mi történjen az első munkanapon és utána?

Az indulás utáni támogatás kapjon előre kijelölt felelőst és hibabejelentési utat. Az első munkanapon a kritikus folyamatokat figyeljétek: új rendelés rögzítése, előzmények visszakeresése, feladatátadás és dokumentumelérés. Az eltéréseket forrásazonosítóval, elvárt eredménnyel és tényleges eredménnyel rögzítsétek, hogy a javítás visszaellenőrizhető legyen.

A régi rendszert csak az elfogadott átállási és megőrzési terv szerint vezessétek ki. A csak olvasható hozzáférés átmenetileg segítheti az ellenőrzést, de ne alakuljon ki tartós kettős adatbevitel. A projekt lezárásakor adjátok át a végső megfeleltetési dokumentációt, futási jelentéseket és a még vállalt utómunkák listáját.

Összegzés: akkor kész, ha folytatható a munka

A jó adatmigráció bizonyítható átállást eredményez. Ismert a hatóköre, érthetők az átalakításai, megismételhető a futtatása, és az üzleti felelősök ellenőrizték a végeredményt. A használható tervhez adatjegyzék, mezőtérkép, próbamigráció, elfogadási feltételek és kipróbált visszaállási folyamat szükséges.

Ha új rendszerre készülsz, kezdd a jelenlegi adatforrások és a nélkülözhetetlen napi munkafolyamatok összegyűjtésével. A BudaWeb üzleti rendszerfejlesztési konzultációján ezek alapján átbeszélhető, hogyan kapcsolódjon az adatköltöztetés a fejlesztéshez és a bevezetéshez. Egy anonimizált adatstruktúra, a forrásrendszerek listája és a kívánt átállási időablak már jól használható kiindulópont.