Navision Business Central migráció 2026: IT-vezetői útmutató az on-premise rendszerről a felhőbe

A Navision Business Central migráció nem egyszerű verziófrissítés, hanem az ERP technológiai alapjainak újratervezése. IT-vezetőként nemcsak azt kell eldöntenie, hogyan kerülnek át az adatok a felhőbe, hanem azt is, mi történik az egyedi fejlesztésekkel, integrációkkal, jogosultságokkal, üzemeltetéssel, monitoringgal és a következő évek frissítéseivel.

A kérdés 2026-ban különösen aktuális. A Dynamics NAV 2016 kiterjesztett Microsoft-támogatása 2026. április 14-én véget ért, a NAV 2017-é 2027 januárjában, a NAV 2018-é pedig 2028. január 11-én jár le.

Ez azonban nem jelenti azt, hogy minden NAV-rendszert azonnal le kell kapcsolni. Azt jelenti, hogy az IT-stratégiában már nem érdemes automatikusan adottságként kezelni a jelenlegi környezet fenntartását.

A Loginform részletes, több mint 70 oldalas Navision → Business Central migrációs útmutatója cégvezetői, pénzügyi és IT-nézőpontból is feldolgozza a döntést. Ez a cikk kifejezetten az informatikai vezetők számára emeli ki a technológiai és projektkockázatokat. Navision → Business Central migrációs útmutató ingyenes letöltése

Tartalomjegyzék

1. Mit jelent technikailag a Navision Business Central migráció?
2. Mikor válik IT-kockázattá a régi NAV fenntartása?
3. Milyen architektúrát kap a vállalat Business Central Online esetén?
4. Mi történik az egyedi NAV-fejlesztésekkel?
5. Hogyan kell újragondolni az integrációkat?
6. Hogyan érdemes az adatokat migrálni?
7. Hogyan néz ki egy biztonságos Navision Business Central migráció?
8. Hogyan kell tesztelni az új Business Central környezetet?
9. Biztonságosabb a Business Central felhőben?
10. Mennyibe kerül a Navision Business Central migráció IT-szempontból?
11. Hogyan válasszon partnert Navision Business Central migrációhoz?
12. Navision on-premise vagy Business Central cloud? IT-vezetői összehasonlítás
13. „Készen állunk a migrációra?” – IT-vezetői ellenőrzőlista
14. Gyakori kérdések IT-vezetőktől

1. Mit jelent technikailag a Navision Business Central migráció?

A Navision Business Central áttérés egyszerű rendszerfrissítés?

Nem. A Navision Business Central áttérés a legtöbb régebbi NAV-környezetben egyszerre jelent alkalmazás-, fejlesztési, integrációs és üzemeltetési modellváltást. Emiatt egy sikeres projektet nem célszerű hagyományos „upgrade-ként” kezelni: először a jelenlegi technológiai örökséget kell feltérképezni, és csak utána lehet kijelölni a célarchitektúrát.

Egy régi NAV-rendszerben gyakran egymásra épült az évek során:

• C/AL alapú egyedi fejlesztés,
• közvetlen adatbázis-kapcsolat,
• fájlcserére épülő interface,
• SOAP vagy egyedi web service,
• Windows-felhasználóhoz kötött jogosultság,
• külső riport vagy Excel-folyamat,
• helyi SQL Server,
• szerveroldali batch vagy egyedi automatizmus.

Business Central Online esetén ezek közül több elemet újra kell tervezni.

A Microsoft jelenlegi migrációs útvonala a Dynamics NAV → Business Central Online átállásnál technikai köztes lépésként Business Central 14-es verzióval is számol. A pontos migrációs út mindig a kiinduló NAV-verziótól és az egyedi kódbázistól függ.

IT-vezetői következtetés: ne az legyen az első kérdés, hogy „mennyi idő átmásolni az adatbázist?”, hanem az, hogy mely jelenlegi technikai megoldásokat érdemes egyáltalán továbbvinni.

Mi a legnagyobb technológiai különbség a régi NAV és a Business Central Online között?

A legnagyobb változás az, hogy a saját infrastruktúrán működtetett, erősen testreszabható ERP-ből Microsoft által üzemeltetett SaaS-platformra kerül a vállalat. A szerver-, adatbázis- és platformüzemeltetés jelentős része átkerül a Microsofthoz, miközben az IT feladata az architektúra, identitás, integrációk, extensionök és üzleti rendelkezésre állás felügyelete lesz.

Ez nem azt jelenti, hogy „az IT-nak többé nincs dolga az ERP-vel”.

Éppen ellenkezőleg. Az IT-feladat jellege változik meg:

NAV on-premise	Business Central Online
szerverüzemeltetés	szolgáltatás- és környezetmenedzsment
SQL-karbantartás	adat- és integrációs governance
saját upgrade projektek	frissítési readiness
C/AL módosítások	AL extension lifecycle
lokális monitoring	Application Insights és platformtelemetria
infrastruktúra-védelem	identitás-, jogosultság- és integrációbiztonság

Az IT tehát kevesebbet foglalkozik azzal, hogy „él-e a szerver”, és többet azzal, hogy fenntartható-e az ERP teljes technológiai ökoszisztémája.

2. Mikor válik IT-kockázattá a régi NAV fenntartása?

Önmagában indokolja a migrációt a Microsoft támogatásának megszűnése?

A támogatás vége önmagában nem teszi használhatatlanná a NAV-rendszert, de alapvetően megváltoztatja a vállalat kockázati profilját. Egy kifutott verziónál egyre nagyobb felelősség kerül a belső IT-ra és a partnerre a biztonság, kompatibilitás, hibakezelés és külső integrációk fenntartása terén.

1. szeptemberi állapot szerint:

Verzió	Kiterjesztett támogatás vége
Dynamics NAV 2016	2026. április 14. – már lejárt
Dynamics NAV 2017	2027. január 11.
Dynamics NAV 2018	2028. január 11.

Forrás: Microsoft Lifecycle.

A Loginform migrációs útmutatója ezért joggal kezeli a nem váltást is tudatos stratégiai döntésként. Egy ERP ugyanis attól még, hogy stabilan fut, technológiailag fokozatosan elszigetelődhet.

Milyen jelek mutatják, hogy a NAV már technológiai féket jelent?

A régi NAV akkor válik valódi IT-problémává, amikor az üzleti igények kiszolgálásához egyre több kerülőmegoldás, egyedi interface, manuális adatmozgatás vagy kritikus szakértői tudás szükséges. A kockázat általában nem egyetlen nagy hibaként, hanem lassan növekvő technikai adósságként jelenik meg.

Tipikus figyelmeztető jelek:

• az integrációk dokumentációja hiányos;
• egy-egy interface működését csak egy kolléga ismeri;
• közvetlen SQL-elérésre épülnek üzleti folyamatok;
• új rendszer kapcsolódása hetek vagy hónapok fejlesztését igényli;
• rendszeresen exportálni kell adatot Excelbe;
• egy verziófrissítés aránytalanul nagy projekt lenne;
• a standard NAV-objektumok erősen módosítottak;
• az infrastruktúra frissítését maga az ERP-verzió akadályozza.

Ezeket érdemes az ERP technikai adósságának tekinteni és számszerűsíteni.

3. Milyen architektúrát kap a vállalat Business Central Online esetén?

Mit üzemeltet a Microsoft, és mi marad a vállalat felelőssége?

Business Central Online esetén a Microsoft üzemelteti az alapvető SaaS-platformot, az adatbázis-infrastruktúrát és a szolgáltatás frissítéseit, de a vállalat felelőssége marad többek között a jogosultsági modell, az integrációk, az extensionök, a konfiguráció és az üzleti folyamatok biztonságos kialakítása.

Ez klasszikus shared responsibility helyzet.

A Microsoft oldalára kerül többek között:

• a Business Central szolgáltatási infrastruktúrája;
• Azure SQL alapú adatbázis-platform;
• platformfrissítések;
• automatikus adatbázis-mentések;
• szolgáltatási monitoring;
• infrastruktúra-szintű biztonsági intézkedések.

A vállalat és implementációs partnere oldalán marad:

• felhasználók és szerepkörök;
• Conditional Access és MFA-stratégia;
• külső integrációk;
• API-jogosultságok;
• extensionök;
• üzleti kontrollok;
• adatmegőrzési és archiválási stratégia;
• incidenskezelési és üzletmenet-folytonossági eljárások.

A „felhőben van, tehát biztonságos” ezért ugyanannyira hibás megközelítés, mint az, hogy „a saját szerver automatikusan biztonságosabb”.

Hogyan működik a mentés és visszaállítás Business Central Online-ban?

Business Central Online alatt az Azure SQL automatikusan készít adatbázis-mentéseket, amelyekből jelenleg legfeljebb 28 napra visszamenőleg lehet időpont-alapú környezet-visszaállítást végezni. Ez jelentős üzemeltetési könnyítés, de nem helyettesíti automatikusan a vállalat saját archiválási, adatmegőrzési vagy üzletmenet-folytonossági szabályait.

A Microsoft dokumentációja szerint a Business Central production és sandbox környezetek adatbázisai automatikus backupot kapnak, és az adminisztrátor meghatározott időpontra állíthat vissza környezetet a rendelkezésre álló 28 napos perióduson belül.

IT-audit során ezért legalább három külön kérdést érdemes kezelni:

1. operatív recovery: hogyan állítjuk vissza a működő környezetet;
2. jogi/adatmegőrzési igény: milyen adatnak mennyi ideig kell megmaradnia;
3. archív hozzáférés: hogyan férünk hozzá például 7–10 évvel korábbi üzleti adatokhoz.

Ez három külön követelmény — nem egyetlen „van backup” checkbox.

Hogyan változik az identitás- és hozzáféréskezelés?

Business Central Online az identitáskezelést szorosan a Microsoft Entra ID környezethez kapcsolja, így az ERP-hozzáférés a vállalati identitásbiztonság részévé tehető. Az MFA és a Conditional Access segítségével az IT egységesebb hozzáférési politikát alakíthat ki, mint sok régi, lokális NAV-környezetben.

A Microsoft kifejezetten ajánlja a többtényezős hitelesítést, és Business Central Online-ra Conditional Access szabályok is alkalmazhatók.

Migrációkor ezért ne egyszerűen a régi felhasználói listát másolja át.

Vizsgálja felül:

• ki férhet hozzá az ERP-hez;
• milyen szerepkörrel;
• milyen eszközről;
• milyen földrajzi helyről;
• kell-e MFA;
• mely service accountok léteznek;
• mely integrációk milyen alkalmazásidentitást használnak.

4. Mi történik az egyedi NAV-fejlesztésekkel?

Átvihető változtatás nélkül a régi C/AL kód?

Általában nem. A régebbi NAV rendszerekben készült C/AL testreszabásokat a modern Business Central extension-alapú, AL nyelvű fejlesztési modelljéhez kell igazítani. Ezért a migráció egyik legfontosabb technikai munkafázisa nem a kód automatikus konvertálása, hanem annak eldöntése, mely egyedi funkció maradjon meg egyáltalán.

A modern Business Central alkalmazás extension-alapú. A Microsoft dokumentációja szerint a termék jelenlegi verzióiban az alkalmazásfejlesztés AL-extension modellre épül; a klasszikus C/SIDE/C/AL megközelítés már nem a célarchitektúra része.

Ez kiváló alkalom az évek alatt felhalmozott fejlesztési örökség tisztítására.

Minden egyedi objektumnál négy kérdésre érdemes választ adni:

1. használja még valaki;
2. bekerült-e időközben a standard Business Centralba;
3. kiváltható-e kész appal;
4. ha egyedi marad, hogyan lehet frissítésálló AL-extensionként megvalósítani.

A legdrágább stratégia általában az, amikor mindent automatikusan újrafejlesztünk csak azért, mert a régi rendszerben is benne volt.

Miért fontos az extension-alapú fejlesztés az IT-vezetőnek?

Az extension-modell legfontosabb IT-előnye, hogy a saját fejlesztések jobban leválaszthatók a Microsoft standard alkalmazásáról, ezért kezelhetőbbé válik a frissítés, verziókövetés és tesztelés. Ez azonban csak akkor előny, ha a fejlesztések valóban megfelelő architekturális és kódminőségi elvek szerint készülnek.

Az „extension” önmagában nem jelent automatikusan jó megoldást.

Érdemes számon kérni:

• forráskód-kezelést;
• verziózást;
• automatizált buildet;
• upgrade codeunitokat;
• dokumentált függőségeket;
• telemetry támogatást;
• regressziós tesztelést;
• lehetőleg minél kevesebb standard-függést.

A Microsoft külön upgrade-mechanizmust biztosít az extensionök adatstruktúrájának változtatására is.

5. Hogyan kell újragondolni az integrációkat?

Elég a régi NAV-interface-eket újrakötni Business Centralhoz?

Nem feltétlenül. Egy Navision Business Central migráció során minden integrációt külön életciklus- és architektúra-auditnak kell alávetni, mert egy korábban megfelelő SOAP, fájl-, SQL- vagy egyedi kapcsolat 2026-ban már technológiai adósságot jelenthet. A migráció célja nem a régi interface-térkép reprodukálása, hanem egy fenntartható integrációs réteg kialakítása.

Készítsen integrációs leltárt legalább ezekkel az adatokkal:

Integráció	Irány	Technológia	Kritikus?	Adatgazda	SLA	Újratervezendő?
webshop	kétirányú	REST	igen	értékesítés	5 perc	nem
bank	be	fájl/API	igen	pénzügy	napi	vizsgálandó
régi BI	ki	SQL	igen	controlling	óránként	igen
HR	be	fájl	közepes	HR	napi	vizsgálandó

Az ilyen tábla gyakran többet mond a migráció valós nehézségéről, mint maga az ERP-adatbázis mérete.

Miért kell 2026-ban különösen figyelni a SOAP-integrációkra?

A SOAP-alapú Business Central web service-ek kifutó technológiának számítanak, ezért új migrációban már REST API vagy OData V4 irányba érdemes tervezni. Microsoft 2026-os dokumentációja szerint a SOAP támogatás deprecált, a Microsoft UI-oldalak SOAP web service-ként történő publikálásának támogatása pedig a 2026 release wave 2, vagyis a 29.0-s verzió során tovább szűkül.

A Microsoft kifejezetten REST API-k és API page/query megoldások használatát ajánlja.

Ez 2026-ban nem elméleti kérdés.

Ha egy migrációs projektben most új SOAP-integráció készül, könnyen előfordulhat, hogy már az induláskor technikai adósságot építünk.

Milyen integrációkat érdemes külön vizsgálni magyar vállalatnál?

Magyar vállalatoknál az ERP integrációs térképe rendszerint nem ér véget a CRM-nél és a webshopnál: a pénzügyi, számlázási, banki, NAV- és dokumentumkezelési kapcsolatok üzletkritikus interface-ek lehetnek. Ezek tesztelésébe az IT mellett a pénzügyi és számviteli területet is be kell vonni.

Tipikus kapcsolódások:

• NAV Online Számla;
• banki rendszerek;
• számlázó megoldások;
• webshop;
• WMS és logisztikai rendszer;
• CRM;
• Power BI;
• HR- és bérprogram;
• dokumentumkezelő;
• Microsoft 365;
• Power Platform;
• iparági rendszerek.

Itt válik különösen fontossá, hogy az ERP-partner ne csak az API-t értse, hanem azt is, milyen üzleti és számviteli adat folyik rajta keresztül.

6. Hogyan érdemes az adatokat migrálni?

Minden régi Navision-adatot át kell vinni az új rendszerbe?

Nem. Az adatmigráció célja nem a régi adatbázis teljes másolata, hanem az új rendszer működéséhez, riportálásához, jogszabályi megfeleléséhez és üzleti visszakereshetőségéhez szükséges adatok kontrollált átvitele. A teljes történeti állomány migrálása indokolatlanul növelheti a projekt idő-, tesztelési és adattisztítási igényét.

Három adatcsoportot célszerű elkülöníteni:

1. Törzsadatok

Partnerek, cikktörzs, főkönyvi struktúrák, dimenziók, fizetési feltételek és egyéb alapadatok.

2. Nyitó és nyitott tételek

Főkönyvi nyitóadatok, nyitott vevő- és szállítótételek, készlet, tárgyi eszközök, aktív projektek.

3. Történeti adatok

Korábbi évek könyvelése, bizonylatai és analitikái.

A harmadik csoportnál dönteni kell: ténylegesen migráljuk, külön archív rendszerben tartjuk, vagy csak riportálható formában őrizzük meg?

Hogyan ellenőrizhető, hogy az adatmigráció sikerült?

Az adatvalidációt üzleti kontrollösszegekkel kell bizonyítani, nem azzal, hogy a migrációs script hiba nélkül lefutott. IT-szempontból sikeres adatbetöltés után a pénzügyi és operatív területeknek is igazolniuk kell, hogy a forrás- és célrendszer kritikus egyenlegei, darabszámai és állományai megegyeznek.

Példák:

• főkönyvi egyenlegek;
• vevő- és szállítóegyenlegek;
• készlet mennyisége és értéke;
• tárgyi eszköz nettó értéke;
• nyitott megrendelések;
• nyitott projektek;
• adó- és ÁFA-releváns adatok;
• dimenziók;
• felhasználói jogosultságok.

A validációhoz érdemes előre meghatározni az elfogadási kritériumokat.

Ne a go-live hétvégén derüljön ki, hogy a pénzügy és az IT mást ért „sikeres migráció” alatt.

7. Hogyan néz ki egy biztonságos Navision Business Central migráció?

Mi legyen a migráció első lépése?

A migráció első lépése technikai és üzleti felmérés, nem telepítés. Az audit során a jelenlegi NAV-verziót, adatbázist, fejlesztéseket, interface-eket, infrastruktúrát, licenceket, jogosultságokat, riportokat és kritikus üzleti folyamatokat egyetlen rendszerképpé kell összerakni.

Egy IT-audit minimális tartalma:

1. NAV-verzió és build;
2. SQL- és infrastruktúra-környezet;
3. adatbázis-méret és növekedés;
4. egyedi objektumok;
5. külső alkalmazások;
6. integrációk;
7. batch folyamatok;
8. riportok;
9. jogosultságok;
10. adatmegőrzési elvárások;
11. rendelkezésre állási követelmények;
12. üzletileg kritikus időszakok.

A Loginform migrációs útmutatója szintén külön projektfázisként kezeli az előkészítő auditot és a migrációt megelőző döntési pontokat.

Milyen lépésekből álljon maga a projekt?

Egy jól kontrollált migráció több egymásra épülő iterációból áll, és a végleges adatköltöztetés csak a folyamat végén következik. A cél az, hogy a go-live előtt az adat-, alkalmazás-, integrációs és felhasználói kockázatok jelentős részét már tesztkörnyezetben megtaláljuk.

Javasolt folyamat:

1. felmérés és scope
2. célarchitektúra
3. standard vs. egyedi funkciók döntése
4. AL extensionök és integrációk kialakítása
5. próba-adatmigráció
6. integrációs és felhasználói teszt
7. második teljes migrációs próba
8. cutover rehearsal
9. éles go-live
10. hypercare és stabilizáció

Microsoft technikai dokumentációja a Dynamics NAV → Business Central Online migrációt szintén többfázisú folyamatként kezeli, amelyben előkészítés, upgrade és cloud migration lépések különülnek el.

Mennyi leállással járhat az ERP-váltás?

A leállási időt nem általános iparági ígéretből, hanem konkrét cutover-próbából kell meghatározni. Jól előkészített projektnél az éles átállás gyakran hétvégi, kontrollált ablakban történik, de a szükséges idő az adatvolumentől, integrációktól, validációtól és az üzleti folyamattól függ.

Tipikus modell:

Péntek

• régi rendszer lezárása;
• tranzakciók befagyasztása;
• végső export.

Szombat

• adatmigráció;
• extensionök és interface-ek ellenőrzése;
• technikai validáció.

Vasárnap

• üzleti kontrollösszegek;
• jogosultságok;
• smoke test;
• go/no-go döntés.

Hétfő

• Business Central éles indulás;
• hypercare.

Az első cutover-időbecslésnél fontosabb adat, hogy mennyi ideig tartott a második teljes próbamigráció.

Kell rollback terv?

Igen. Minden kritikus ERP-migrációnak előre definiált go/no-go és rollback kritériumokra van szüksége. A rollback nem feltétlenül jelenti azt, hogy „egy gombnyomással visszaállunk”; azt jelenti, hogy előre rögzített döntési pont, felelősök és működési forgatókönyv létezik arra az esetre, ha az új rendszer nem indítható biztonságosan.

Előre rögzítendő például:

• meddig lehet visszafordulni;
• ki hozza meg a döntést;
• mi számít blocker hibának;
• hogyan kerülnek vissza a tranzakciók a régi rendszerbe;
• mi történik az átállás közben keletkezett külső adatokkal.

A „majd eldöntjük vasárnap este” nem rollback stratégia.

8. Hogyan kell tesztelni az új Business Central környezetet?

Elég egy felhasználói UAT a go-live előtt?

Nem. Egy Navision Business Central migrációhoz legalább technikai, integrációs, adatvalidációs és üzleti UAT tesztelés szükséges, kritikus környezetben pedig terhelési és cutover-tesztet is célszerű végezni. Az egyes tesztek más típusú hibát keresnek, ezért nem helyettesítik egymást.

Érdemes külön kezelni:

• extension tesztek;
• API- és interface tesztek;
• jogosultsági tesztek;
• adatvalidáció;
• end-to-end folyamatok;
• regressziós tesztek;
• üzletkritikus riportok;
• teljesítmény;
• migráció időigénye.

A Business Central sandbox és preview környezetei lehetővé teszik, hogy a változásokat az éles környezettől elkülönítve teszteljék.

Hogyan változik a frissítések kezelése a felhőben?

Business Central Online esetén a frissítések nem ritka, többéves upgrade projektek, hanem a normál IT-üzemeltetés részévé válnak. A Microsoft évente két nagy kiadási hullámot indít — jellemzően áprilisban és októberben —, közöttük pedig kisebb frissítések érkeznek.

A Business Central admin centerben frissítési időablak állítható be, az új verziók pedig preview/sandbox környezetben előzetesen tesztelhetők.

2026 release wave 1 a 28-as főverzióval indult áprilisban; 2026 augusztusában a 28.4-es frissítés volt aktuális.

Ez az evergreen IT logika.

Az IT feladata ezért nem az lesz, hogy öt évig kerülje az upgrade-et, hanem hogy létrehozza azt a tesztelési és fejlesztési fegyelmet, amely mellett a frissítések rutinszerűen kezelhetők.

Hogyan monitorozható egy felhős Business Central környezet?

A Business Central Azure Application Insights felé képes részletes környezeti és extension-telemetriát küldeni, így az IT nem veszti el a monitoring lehetőségét azzal, hogy az ERP SaaS-rendszerré válik. A megfelelően kialakított telemetry segítségével teljesítmény-, hiba- és használati problémák proaktívan elemezhetők.

A Business Central többek között környezet- és extension-szintű telemetriát biztosít, amely Application Insightsban KQL-lekérdezésekkel, Power BI-jal és riasztásokkal is elemezhető.

Ez különösen fontos saját extensionök esetén.

Az a fejlesztés, amelynek működéséről csak akkor értesül az IT, amikor a felhasználó telefonál, 2026-ban már nehezen nevezhető jól üzemeltethető enterprise megoldásnak.

9. Biztonságosabb a Business Central felhőben?

Biztonságosabb a Business Central Online, mint egy saját NAV-szerver?

Erre nincs minden vállalatra érvényes igen vagy nem válasz. A Business Central Online számos infrastruktúra-szintű biztonsági feladatot Microsoft által üzemeltetett, folyamatosan frissített szolgáltatásba helyez át, de az identitáskezelés, jogosultságok, integrációk és üzleti folyamatok hibás konfigurációja továbbra is komoly kockázatot jelenthet.

A Microsoft jelenlegi dokumentációja szerint a Business Central Online környezetekben:

• az adatok nyugalmi állapotban titkosítottak;
• a hálózati kommunikáció titkosított;
• a környezetek adatbázisai elkülönítettek;
• Microsoft Entra ID és MFA használható;
• Microsoft biztonsági monitoring működik.

A migráció biztonsági terve ennek ellenére tartalmazzon legalább:

• MFA-t;
• Conditional Access szabályokat;
• least privilege elvet;
• adminisztrátori jogosultságok kontrollját;
• API-azonosítók kezelését;
• secret managementet;
• jogosultsági felülvizsgálatot;
• auditálást;
• incidenskezelést.

Mit jelent a magyar kiberbiztonsági szabályozás egy ERP-migrációnál?

Ha a vállalat a magyar kiberbiztonsági szabályozás hatálya alá tartozik, az ERP-migráció során a rendszer kockázatkezelését, hozzáféréseit, auditálhatóságát és üzletmenet-folytonosságát is a szervezeti kiberbiztonsági követelmények részeként kell kezelni. A felhőre költözés önmagában nem jelent NIS2- vagy más jogszabályi megfelelést.

Magyarország kiberbiztonságáról a 2024. évi LXIX. törvény rendelkezik; a jogszabály többek között az elektronikus információs rendszerek bizalmasságának, sértetlenségének és rendelkezésre állásának kockázatarányos védelmét írja le.

1. június 30-ig az SZTFH adatai szerint 2194 szervezet teljesítette első kiberbiztonsági auditját.

Fontos: a szabályozás nem minden magyar vállalkozásra azonos módon vonatkozik. Az érintettséget a vállalat tevékenysége, mérete és jogszabályi besorolása alapján külön kell vizsgálni.

10. Mennyibe kerül a Navision Business Central migráció IT-szempontból?

Miért félrevezető csak a migráció projektárát összehasonlítani?

Az ERP-váltás pénzügyi értékelésénél az egyszeri projektköltség önmagában nem mutatja meg, melyik architektúra kedvezőbb. IT-vezetőként legalább 5 éves TCO-ban érdemes összevetni az infrastruktúrát, licenceket, upgrade-eket, fejlesztéseket, üzemeltetési munkaidőt, monitoringot, backupot és technikai kockázatokat.

On-premise TCO például tartalmazhatja:

• szerver és storage;
• SQL Server;
• operációs rendszer;
• virtualizáció;
• backup;
• monitoring;
• patch management;
• infrastruktúra-munkaidő;
• upgrade projektek;
• külső support;
• egyedi fejlesztések fenntartása.

Cloud oldalon ezzel szemben hangsúlyosabb:

• Business Central előfizetés;
• extensionök;
• integrációk;
• Azure-kiegészítő szolgáltatások;
• partneri support;
• Application Insights;
• governance és security.

A Loginform migrációs útmutatója ezért szintén 5–10 éves teljes életciklus-költség összevetését javasolja az egyszeri projektköltség helyett.

11. Hogyan válasszon partnert Navision Business Central migrációhoz?

Mit érdemes megkérdezni egy Business Central migrációs partnertől?

Az IT-vezető számára a megfelelő partner nem egyszerűen Business Central-licencet vagy fejlesztési kapacitást értékesít, hanem képes a teljes alkalmazási ökoszisztémát architekturálisan kezelni. Migráció előtt ezért érdemes konkrét technikai kérdésekkel tesztelni, hogyan gondolkodik a partner integrációról, fejlesztésről, adatról, tesztelésről és üzemeltetésről.

Tegye fel például ezeket a kérdéseket:

1. Hogyan mérik fel a C/AL fejlesztéseinket?
2. Milyen szempont alapján döntik el, mit fejlesszünk újra?
3. Hogyan kezelik a REST/OData-integrációkat?
4. Hogyan verziózzák az AL extensionöket?
5. Van CI/CD folyamatuk?
6. Hogyan tesztelik a Microsoft major release-eket?
7. Hogyan végzik az adatreconciliationt?
8. Hogyan tervezik meg a cutovert?
9. Mi a rollback-folyamat?
10. Hogyan monitorozzák az egyedi extensionöket?
11. Hogyan kezelik a magyar pénzügyi és NAV-követelményeket?
12. Ki támogatja az ERP-t a go-live utáni első kritikus hetekben?

A Loginform márkastratégiája az IT-vezetők esetében kifejezetten a rendszerintegrációt, hibamegelőzést és kritikus helyzetekben adott gyors szakmai reakciót jelöli meg központi értékajánlatként. A cég pozicionálása szerint a technológiai tudást mély pénzügyi és számviteli kompetencia egészíti ki.

Egy ERP esetében ez azért lényeges, mert egy technikailag működő interface még nem biztos, hogy üzletileg helyes adatot ad át.

12. Navision on-premise vagy Business Central cloud? IT-vezetői összehasonlítás

Melyik modell jelent kisebb hosszú távú IT-kockázatot?

Azoknál a vállalatoknál, amelyek nem rendelkeznek erős üzleti indokkal saját ERP-infrastruktúra fenntartására, a Business Central Online általában kiszámíthatóbb technológiai életciklust kínál. Ugyanakkor a döntést az integrációk, egyedi fejlesztések, adatkezelési követelmények, rendelkezésre állás és a vállalati cloud-stratégia együttes vizsgálatával kell meghozni.

Szempont	Navision on-premise	Business Central Online
infrastruktúra	vállalati felelősség	Microsoft szolgáltatás
SQL-üzemeltetés	vállalati feladat	szolgáltatás része
fejlesztési modell	régi rendszereknél C/AL	AL extension
frissítések	projektjellegűek	folyamatos életciklus
major release	ritkább	évente kétszer
integráció	verziófüggő, gyakran egyedi	REST API / OData fókusz
identitás	gyakran lokális	Microsoft Entra
MFA/Conditional Access	környezetfüggő	natívan integrálható
backup	vállalati felelősség	automatikus Azure SQL backup
monitoring	saját rendszer	Application Insights lehetőség
skálázás	infrastruktúra-projekt	szolgáltatásalapú
technikai adósság	felhalmozódhat	folyamatosan kezelendő

A lényeg: a cloud nem tünteti el az IT-munkát. Más típusú IT-munkává alakítja.

13. „Készen állunk a migrációra?” – IT-vezetői ellenőrzőlista

Milyen feltételek mellett érdemes elindítani a projektet?

A vállalat akkor áll készen a Navision Business Central migrációra, ha a jelenlegi rendszer technikai állapotáról, a szükséges egyedi funkciókról, integrációkról, adatokról, biztonsági elvárásokról és üzleti kritériumokról már közös kép alakult ki. A legnagyobb kockázatot általában nem a technológia, hanem a feltáratlan függőségek jelentik.

Rendszer

• [ ] ismert a pontos NAV-verzió és build;
• [ ] rendelkezésre áll az adatbázis és objektumlista;
• [ ] dokumentáltak a batch folyamatok.

Fejlesztések

• [ ] minden egyedi funkció leltárban van;
• [ ] ismert, mely funkciókat használják ténylegesen;
• [ ] megtörtént a standard/app/egyedi besorolás.

Integrációk

• [ ] minden interface dokumentált;
• [ ] ismert a protokoll és autentikáció;
• [ ] a SOAP- és közvetlen SQL-kapcsolatok külön felülvizsgálatra kerültek.

Adatok

• [ ] eldőlt a történeti adatok kezelése;
• [ ] meghatározták a kontrollösszegeket;
• [ ] kijelölték az adatgazdákat.

Biztonság

• [ ] elkészült a jogosultsági koncepció;
• [ ] MFA/Conditional Access döntés megszületett;
• [ ] az admin- és integrációs accountok szabályozottak.

Üzemeltetés

• [ ] meghatározták a monitoringot;
• [ ] létezik incidenskezelési folyamat;
• [ ] létezik recovery- és rollback terv.

Projekt

• [ ] ismert a go-live időablak;
• [ ] van legalább egy teljes próbaváltás;
• [ ] meghatározottak a go/no-go kritériumok;
• [ ] kijelölték a technikai és üzleti döntéshozókat.

Ha ezek jelentős részére ma még nincs biztos válasz, érdemes migrációs audittal, nem pedig implementációval kezdeni.

A teljes stratégiai, pénzügyi és IT-ellenőrzőlistát a Loginform 2026-os migrációs útmutatója részletesebben is végigveszi. Navision → Business Central migrációs útmutató letöltése

Gyakori kérdések IT-vezetőktől

Meddig használható még biztonságosan egy régi Navision?

Nincs olyan dátum, amely után minden NAV-rendszer automatikusan használhatatlanná válik, de a Microsoft-támogatás megszűnése után a technológiai és biztonsági kockázat nagyobb részét már a vállalatnak és partnerének kell kezelnie. A NAV 2016 támogatása 2026. április 14-én megszűnt, a NAV 2017-é 2027-ben, a NAV 2018-é 2028-ban jár le.

Megmaradhatnak az egyedi fejlesztéseink Business Centralban?

Igen, de jellemzően nem változatlan formában. A valóban szükséges egyedi funkcionalitások AL-extensionként újraalkothatók, miközben érdemes megvizsgálni, hogy egy részük időközben bekerült-e a standard Business Centralba vagy kiváltható-e kész alkalmazással.

Business Central Online mellett szükség van saját SQL Serverre?

A Business Central Online működtetéséhez a vállalatnak nem kell saját Business Central SQL-infrastruktúrát üzemeltetnie. Bizonyos BI-, integrációs vagy adatplatform-megoldások természetesen ettől függetlenül használhatnak saját adatbázist, de ezek már külön architekturális komponensek.

Elérhető a Business Central adatbázisa közvetlen SQL-kapcsolaton keresztül?

Business Central Online esetén nem érdemes a régi on-premise világ közvetlen SQL-hozzáférési mintáiból kiindulni. Integrációhoz és alkalmazáskapcsolathoz támogatott API-, REST- és OData-megoldásokban célszerű gondolkodni.

Mi történik a régi riportokkal?

A riportokat funkcionális igényként kell migrálni, nem feltétlenül technikai objektumként. Először azt kell meghatározni, milyen információra és milyen gyakorisággal van szüksége a felhasználónak; ezután dönthető el, hogy Business Central riport, Excel, Power BI vagy más megoldás a megfelelő céltechnológia.

Mekkora adatbázis migrálható a felhőbe?

Az adatbázis mérete önmagában kevés a projekt nehézségének megítéléséhez. Sokkal fontosabb az adatminőség, a történeti adatok mennyisége, az egyedi táblák, a relációk és az, hogy mennyi adatot kell ténylegesen az új operatív környezetbe vinni.

Kell külön tesztkörnyezet?

Igen. Komoly ERP-migrációt nem célszerű közvetlenül production környezetben fejleszteni és validálni. Sandbox környezetben kell kipróbálni az extensionöket, interface-eket, adatkonverziót, jogosultságokat és a Microsoft frissítéseivel való kompatibilitást.

Meg lehet akadályozni a Business Central automatikus frissítését?

A frissítések időzítése bizonyos keretek között menedzselhető, de a Business Central Online alapelve a folyamatosan frissített SaaS-szolgáltatás. A fenntartható stratégia ezért nem a frissítések tartós blokkolása, hanem az extensionök és integrációk upgrade-ready kialakítása és rendszeres tesztelése.

Mennyi ideig tart egy Navision Business Central migráció?

Nincs általános, minden projektre érvényes időtartam. A projekt hosszát főként az egyedi fejlesztések száma, az integrációk, az adatminőség, a vállalati folyamatok összetettsége és a teszteléshez rendelkezésre álló üzleti kapacitás határozza meg.

Mi legyen az első konkrét lépés?

Egy technikai és üzleti migrációs audit. Ennek eredménye nem feltétlenül az, hogy azonnal váltani kell, hanem egy döntési térkép: mi a jelenlegi rendszer kockázata, milyen célarchitektúra indokolt, mit kell átépíteni, mennyi munka várható és milyen sorrendben célszerű haladni.

Összegzés: az IT-vezető feladata nem a „felhőbe költözés”, hanem a technikai adósság kontrollált kiváltása

A Navision Business Central migráció akkor sikeres, ha az új rendszer nem egyszerűen ugyanazt a működést viszi tovább másik infrastruktúrán.

Az átállás lehetőséget ad arra, hogy a vállalat:

• felszámolja a felesleges egyedi kódot;
• modernizálja az interface-eket;
• rendezze a jogosultságokat;
• megszüntesse a kritikus kulcsember-függőségeket;
• monitoringot építsen;
• rendszeressé tegye a tesztelést;
• és olyan ERP-architektúrát alakítson ki, amely a következő Microsoft-frissítésnél nem újabb több hónapos upgrade projektet generál.

A legjobb migráció ezért nem az, amelyikben minden régi funkciót sikerült átmásolni.

Hanem az, amelynek végén kevesebb technikai adóssággal, jobb ellenőrizhetőséggel és kiszámíthatóbb üzemeltetéssel működik a vállalat ERP-je.

Ha szeretné először strukturáltan felmérni, hogy a jelenlegi Navision-rendszer mennyire áll készen a váltásra, a Loginform részletes 2026-os döntési útmutatója ingyenesen elérhető.

Navision → Business Central migrációs útmutató 2026 – ingyenes letöltés

Szerzői blokk – publikálás előtt kitöltendő

Kérdő Róbert ügyvezető, Loginform Kft.

A Loginform több mint 15 éves Microsoft Business Central / Navision tapasztalattal dolgozik ERP-bevezetési, fejlesztési, integrációs és támogatási projekteken. A vállalat egyik meghatározó erőssége, hogy technológiai tudását pénzügyi és számviteli szakértelemmel kapcsolja össze.