2026 elején egy 12 fos, kustom-elektronikai termekeket gyarto magyar ceggel kezdtunk egy ERP-migraciot a Netorigo platformra. A regi rendszer egy 11 eves, on-prem Microsoft Dynamics NAV 2015 volt, sajat fejlesztesu, 137 darab kustom riport-tal. A migraciot 8 hetre terveztuk. 8 het alatt elkeszult. Egy rollback, egy tanulsag a kepzesrol.
Az ido megoszlasa
8 het - 320 munkaora a Netorigo csapaton beluli + kb. 80 ora a kliens IT vezetojetol. Az ido nem egyenletesen oszlott meg:
- 1-2 het: discovery + adat-elemzes. Mi van a NAV-ban? A 137 riport mibol all? Melyek a kritikusak (3-4 darab), melyeket nem hasznaljak (94 darab, ahol a
last_executed_at > 2 ev). - 2-5 het: adat-modell tervezes + Prisma migracios scriptek. 11 modul: customers, products, BOMs, work orders, inventory, purchases, sales, invoices, payments, users, roles.
- 5-7 het: delta-migracio tesztkornyezeten + felhasznaloi acceptance tesztek.
- 7. het pentek - 8. het hetfo: eles cutover.
- 8. het: post-go-live support + finomhangolas.
A 3 hetes adatmodell
A BOM (Bill of Materials) versioning volt a legnehezebb. A regi NAV-ben egy BOM-versio egyetlen JSON-string mezoben volt tarolva (igen, JSON egy NAV-mezoben, ez nem joke), es kellett rekonstrualnunk a verziozott BOM strukturat hierarchikusan, ahol egy alaptermek (product.code='ELECTRONICS-CORE-V3') 47 al-komponensre bomlik, es minden al-komponens lehet egy masik BOM tetejen.
Mi a Prisma sema-ban harom tablat hasznaltunk:
bom- a fo BOM rekord (productId, versionNumber, validFrom, validTo)bom_component- egy BOM tetel egy alkatresszel (bomId, componentProductId, quantity, unitOfMeasure)bom_history- audit-log a BOM valtoztatasokrol
A migracios script (migrate-bom.ts a prisma/scripts/-ben) 3 het alatt erte el az 'utility' allapotot: a 4,200 BOM-bol 4,184 sikeres at-merged kerult, 16-ot manualisan kellett megerintenunk, mert a regi JSON parsing 'ts' helyett t s (extra space) szeparatort hasznalt.
A 30 perces adatmodell
Konyu reszek: ugyfelek. A regi NAV-bol 1,847 ugyfel-rekord, csak name, address, tax_id, phone, email mezok. Egy Prisma customer tablaba egy direct SQL INSERT ... SELECT muveletekkel 30 perc alatt at-migraltak. Az ugyfel-orientált indexek (tax_id unique, email lower(email) functional index) egy kovetkezo migracios scriptben kerultek hozzaadasra.
Ez az osszehasonlitas pedagogikus: a komplex adatmodell (BOM) 3 hetes, az egyszeru (ugyfelek) 30 perces. Ha ezt a tervezesi szakaszban tudtak volna, masokent dontottek volna a sprint-priorizalas-rol.
A pentek-hetfo cutover
A pentek 18:00-rol vasarnap 22:00-ig tarto cutover-ablakot terveztunk be. A BullMQ worker-eket leallitottuk, a regi NAV-bol egy vegleges adatdump kerult letre, es a Netorigo platformon egy 'silent migration' mod kerult bekapcsolasra (csak read-only, az API-k 503-mal valaszolnak). 18:00-22:00 a CSV import futott. 22:00-02:00 a delta-validacio (osszehasonlitottuk a regi NAV-bal a friss Netorigo adatait sor-soron). 02:00 elaludtunk, 09:00 ebredtunk.
Vasarnap napon hibaval indultak a felhasznalok: nehany regi NAV-uzeneti tagsag (a NAV-bol orokolt 'reminder' rendszer) nem kerult migracios listara. Egy 6 oras gyors hotfix-tal kerult be a notification_subscription tabla, es a hetfo 08:00-ig minden mukodott.
Egyetlen rollback tortent: a payment_method.gateway_credentials mezot tul gyorsan re-encryptelve hagytak, es 6 partner-fizetes 5 percig nem mukodott. Rollback a payment_method tablara, decrypt az alapertelmezett kulcssal, ujra encrypt az uj kulccsal. 14 perc, nincs adatvesztes.
A kepzesrol tanult
A legnagyobb hiba: a felhasznaloi kepzest elhalasztottuk a cutover utanra. A hetfo reggeli 08:00-rol a felhasznalok 8-10 ora alatt elsajatították a Netorigo UI alapjait, de a haladobb funkciok (jelentest-szerkesztes, kustom BOM-szerkesztes) 2 hetig tartottak.
A jovokeli ajanlas: a kepzes a 7. heten kezdodjon, parhuzamosan a UAT-tal, nem a 8. heten a go-live utan. Ez 1 het 'felig-mukodes'-tol ovta volna meg a klienst.