A erp.netorigo.com mögött futó örökölt PHP/Drupal ERP még mindig aktívan szolgál ki több tucat KKV-t. A modern Netorigo stack (Admin + Finance + Logistics + Storefront) felé vezető migráció ma a stratégiai irány — de nem egy út van, hanem négy. Eldönteni, hogy melyik passzol egy ügyfélhez, fontosabb, mint maga a kivitelezés.
A négy mintázat
1. Teljes átállás (full cutover) — 10 hét. Egy hétvégi átkapcsolás, utána a legacy read-only marad 90 napig. Akkor működik, ha a tenant 50 fő alatti, és a folyamatok nem túl egyedi módon kanyarodnak. Magas kockázat, alacsony cost.
2. Párhuzamos futás (parallel run) — 12 hét. A két rendszer 4 hétig egymás mellett dolgozik, ugyanazokat a tranzakciókat duplán rögzítjük, hetente sztornírozzuk az egyiket. Kockázat alacsony, költség magas (másfélszeres bérköltség az átállási hónapokban). Akkor választjuk, ha a könyvelési zárás integritása kritikus.
3. Strangler-fig — 6 hónap. Modulonként cseréljük le a régi rendszert. Először Storefront, aztán Logistics, végül Finance. A legacy ERP API-jain keresztül beszélnek egymással az átmeneti időszakban. Akkor a legjobb, ha az ügyfél belső csapatának fel kell zárkóznia.
4. API-only — örökre. Nem migrálunk, csak REST-réteget teszünk a legacy elé, és a modern UI-k onnan olvasnak. Lásd külön cikk a témáról. Akkor jön szóba, ha a tenantnak nincs kapacitása vagy üzleti indoka a teljes cserére.
Mit lehet gyorsan migrálni — és mit nem
A gyorsan migrálható adatok (1–2 nap, scripttel):
- Ügyfél törzs (név, cím, adószám, e-mail).
- Beszállító törzs.
- Termék törzs alapadatai (kód, név, mértékegység, ár).
A lassan migrálható adatok (3–6 hét, kézi finomhangolás):
- BOM (anyagjegyzék) többszintű hierarchiák, verzióval.
- Gyártási műveleti útvonalak (routings), gépidő- és emberi-erőforrás bontásban.
- Egyedi árképzési szabályok (mennyiségi sávok, ügyfél-specifikus listaárak).
A legtöbb projekt azon bukik el, hogy a planning a gyors adatokra alapozva ütemez, és a lassú adatok későn érkezve borítják a sprint priorítást.
Miért hagyjuk a legacy reportokat 90 napig
Go-live után az átkapcsolás napjától a legacy ERP read-only módban fut tovább 90 napig. A teljes reporting elérhető marad. Két ok miatt csináljuk ezt:
- Auditori kérések. Az éves könyvvizsgáló a régi formátumokat kéri, és nem akarjuk a régi jelentéseket az új rendszerre átültetni csak azért, hogy aztán senki ne nézze meg többet.
- Bizalom. A tenant könyvelője hetente egyszer összehasonlítja a két rendszert. Amikor 90 napon át nem talál eltérést, megnyugszik. Ez emberi probléma, nem technikai.
Egy konkrét sztori
12 fős egyedi elektronikai gyártó. 8 hetes sprint, teljes átállás. NAV 2015-ből Netorigo modern stackbe. 4 200 BOM, 1 847 ügyfél, 137 egyedi report (amiből 94 két éve nem futott le). A cutover Friday 18:00–Monday 09:00. Egy 14 perces rollback a payment_method.gateway_credentials kulcs-csere miatt. Hat partner-fizetés volt érintve, adatvesztés nulla.
A tanulság, amit a projekt utáni retrón írtunk le: a user-tréninget a 8. hétre időzítettük, és ezt mindenki megbánta. A 7. hétben kell kezdeni, párhuzamosan a UAT-tal. Egy hét részleges produktivitást spóroltunk volna meg.
Mikor melyik mintázat
- 50 fő alatti tenant, standard folyamatok → full cutover.
- 50+ fő, kritikus könyvelési integritás → parallel run.
- Belső IT-csapat fel kell, hogy zárkózzon → strangler-fig.
- Nincs migrációs kapacitás, de modern UI kell → API-only.
A mintázatválasztás nem műszaki kérdés — üzleti. A műszaki kivitelezés ma már mindegyik esetben rutin.