Magyar ERP rendszer kiváltása adatvesztés nélkül

Mikor érdemes váltani, és mikor nem

Ez a rész szándékosan kétirányú. Több ajánlatkérésből, ami hozzánk beesik, körülbelül minden harmadikra azt válaszoljuk, hogy a csere felesleges. Az alábbi listát használd önellenőrzésre a scoping call előtt.

Váltási okok, amiket a gyártók saját anyagai támasztanak alá

Az alábbi táblázat minden sora egy gyártó saját publikus oldaláról származó tényre hivatkozik. Nincs benne vélemény arról, hogy melyik rendszer jó vagy rossz.

Hol tart most a magyar mezőny

Csak az szerepel a táblázatban, amit a gyártó maga publikál, illetve ahol jelöltük, ott az uzletiszoftver.com összehasonlító oldal tájékoztató „-tól” ára. Ez utóbbi nem gyártói adat, és gyakran a legkisebb konfigurációra vonatkozik. Lekérdezés dátuma: 2026. augusztus 14.

A NEXON tudatosan hiányzik a listáról: HR, bér és munkaidő platform, nem vállalatirányítási rendszer. A saját közlése szerint a bérszoftverükkel egymillió munkavállaló bérét számfejtik, és a mi tapasztalatunk szerint ezt integrálni kell, nem lecserélni.

Adatmigráció olyan rendszerből, aminek nincs API-ja

Ez az a rész, amit a legtöbb ajánlatban egy sorral elintéznek. Pedig a projekt kockázatának a többsége itt lakik. Négy szintet használunk, és mindig a legolcsóbbal kezdünk.

1. 1. szint: a gyártó saját exportja

   Szinte minden magyar ügyviteli rendszernek van könyvelői feladása, CSV vagy XML kimenete, néha egy régi, de működő ODBC-nézete. Ez a legolcsóbb csatorna, senki nem tiltja, és a szerződésed sem sérül tőle. A hátránya az, hogy általában csak a pénzügyi magra van kihegyezve: a cikktörzs egyedi mezői, a partnerekhez kötött szállítási címek és a rendelés-történet ritkán férnek bele.

2. 2. szint: olvasó másolat az adatbázisról

   Itt kezdődik az igazi munka. A rendszer napi mentését visszaállítjuk egy külön szerverre, és onnan olvasunk, így az éles rendszerre nulla terhelés jut. Firebird alatt a gbak vagy nbackup mentésből, MS SQL alatt visszaállított másolatból vagy olvasható replikából, PostgreSQL alatt logikai replikációval. A séma feltérképezése kézi munka: táblanevek magyarul, rövidítve, dokumentáció nélkül. Egy közepes rendszernél két-három hét, mire a 600 tábla közül megvan az a 40, amiben az üzleti igazság van.

3. 3. szint: a NAV felé már beküldött adat

   Ez a trükk, amit ritkán látni. A kimenő számláid adatai az Online Számla rendszerben már ott vannak, és lekérdezhetők. Ez független ellenőrző forrás a saját exportod mellé: ha a két halmaz nem fedi egymást, akkor nem a migrációval van baj, hanem a kiindulási adattal, és ezt jobb a projekt harmadik hetében megtudni, mint az első zárásnál.

4. 4. szint: RPA, és csak utolsóként

   Ha egy adat sehogy máshogy nem jön ki, akkor a desktop klienst géppel vezéreljük: bejelentkezés, lista megnyitása, szűrés, exportgomb. Lassú, törékeny, és minden verziófrissítés eltörheti. Nálunk soha nem a fő csatorna, hanem egy-két hiányzó mező pótlása, jellemzően egyszeri futással. Aki RPA-ra épít teljes migrációt, az a projekt kockázatát a lehető legrosszabb helyre teszi.

Egy dolgot mindig megnézünk a projekt előtt: mit mond a szoftverszerződésed a közvetlen adatbázis-hozzáférésről. Van, ahol ez engedélyhez kötött. Ilyenkor a gyártótól kérünk exportot, és a 2. szint helyett az 1. és a 3. kombinációjával dolgozunk. Ez lassabb, de tiszta.

Amit az adaton mérni kell, mielőtt bárki élesít

A migráció akkor kész, ha számokkal bizonyítható. Az alábbi ellenőrzéseket minden projektben lefuttatjuk, és a jegyzőkönyvet a könyvelő is aláírja.

• Rekordszám tábla szinten, forrás és cél oldalon. Ha eltér, a logikailag törölt sorok a leggyakoribb ok: a régi magyar rendszerek szeretnek egy státuszmezőt állítani valódi törlés helyett.
• Összegek áfakulcsonként és időszakonként. Nem a végösszeg számít, hanem a bontás, mert a kerekítési logika eltérése éppen a bontásban ütközik ki.
• Karakterkódolás. A tizenéves magyar adatbázisokban rendszeres a kevert kódolás, és ez a partnernevekben, a hosszú ő és ű betűkön látszik meg először. Ezt a migrációs szkriptben kell javítani, nem kézzel utólag.
• Rejtett üzleti logika a szabad szöveges mezőkben. Ha a megjegyzés rovatba tíz éve kódokat írnak a kollégák, az valódi adat. Kinyerni és mezőbe tenni a migráció része.
• Nyitott tételek külön kezelése. A nyitott vevői és szállítói számlák, a készletmennyiségek és a folyószámla-egyenlegek átemelése a cutover pillanatában történik, nem a történeti adattal együtt.

Párhuzamos üzem és cutover

A sorrend fontosabb, mint a menetrend. Az alábbi felosztás egy közepes, 5–7 modulos projektre vonatkozik; a pontos hosszakat mindig a scoping call után rögzítjük, mert az adatréteg állapotát előre nem lehet megbecsülni.

1. Migrációs audit

   Adatbázis-séma feltérképezése, mentés visszaállítása, mintaadat kinyerése, a hiányzó adatcsatornák azonosítása. A végén tudjuk, mi jön ki és mi nem. Ha itt derül ki, hogy a csere felesleges, azt megmondjuk.

2. Történeti adat betöltése

   Törzsadat, majd tranzakciós történet. A betöltést idempotens szkriptekkel csináljuk, hogy tetszőleges számban újrafuttatható legyen, mert a valóságban öt-hat kör lesz belőle.

3. Árnyékfutás

   Az új rendszer megkapja ugyanazokat a napi tranzakciókat, de a régi marad az igazságforrás. Napi automatikus egyeztetés, eltérés-riport reggelre.

4. Egy teljes hónapzárás mindkét rendszerben

   Ez a valódi vizsga. Főkönyvi kivonat, áfabevallás alapadat, készletérték. A tűréshatárt előre kimondjuk, és amíg nem teljesül, nincs cutover.

5. Cutover és utóélet

   Nyitott tételek átemelése egy leállított hétvégén, majd az új rendszer élesítése. A régi rendszer olvasható marad, a visszaállás lehetőségét pedig az első zárásig fenntartjuk.