Migrating from NAV on-premise to Business Central SaaS
Moving from Dynamics NAV on-premise to Business Central SaaS — the cloud migration tool, AL code rebuild, and the operational changes that come with it.
A large installed base of Dynamics NAV customers — running NAV 2013 through NAV 2018 on their own infrastructure — is steadily moving to Business Central SaaS. Microsoft has invested heavily in this path because every NAV-to-BC migration consolidates a customer into the modern, managed cloud where Microsoft prefers them. Tooling has improved substantially over the past few years.
The official path. Microsoft ships the Cloud Migration tool for NAV → Business Central SaaS. It:
- Connects to the on-premise NAV database via an installed extension.
- Maps NAV tables to BC tables, including standard application data and customer customisations.
- Replicates the data into a BC SaaS tenant.
- Supports an iterative model: re-run the migration, refining over time until the BC tenant is good to cut over to.
Supported NAV versions are NAV 2015 and later; earlier versions need an intermediate upgrade.
The two big challenges. Data is the lesser of the two. The bigger ones are:
-
Customisations in C/AL must be rebuilt as AL extensions. NAV's customisation model — direct modification of Microsoft's base objects in C/AL — doesn't exist in BC SaaS. Every customisation, however small, must be rewritten as an AL extension. For lightly-customised customers (a few dozen modifications) this is a few months of work. For heavily-customised customers (thousands of modifications), it's a year or more — and an opportunity to rationalise.
-
Operational habits change. On-premise NAV ran on the customer's own SQL Server, with full DBA access, server-side jobs, and the ability to modify anything. BC SaaS runs in Microsoft's cloud, with no SQL access, mandatory release waves, API-only integration, and constrained extensibility. Customers used to direct database access must adapt to standard APIs and AL extensibility.
Strategic options.
- Lift and shift. Migrate data and rebuild customisations as exact AL replicas. Fastest path but carries forward bloat.
- Fit-to-standard. Use the migration to re-evaluate every customisation against modern standard BC. Many turn out to be unnecessary (BC has caught up with what custom code used to do). Slower migration but cleaner long-term position.
- Hybrid. Critical-path customisations get rebuilt; nice-to-haves get re-evaluated and often dropped.
Most successful migrations are hybrid.
Integration rebuild. NAV integrations were typically built with C/AL web services, NAS services, or third-party middleware. BC SaaS exposes only the v2.0 REST API and custom AL API pages. Most integrations rebuild; in many cases simpler than before.
Reporting rebuild. NAV's classic RDLC reports and Excel layouts mostly survive in BC SaaS, but C/AL-based report customisations need re-implementation in AL.
Customer expectations. Set them up front. On the day of cutover, the BC SaaS tenant has fewer features than the old NAV (everything that wasn't ported) and a different operating cadence (release waves). This is the cost of getting to a maintained, modern, managed system; communicate it clearly.
Time to live. 6 to 18 months depending on customisation depth. The migration tool moves the data in days; the rebuild is the project.
Related guides
- Business Central vs Dynamics NAVWhat changed in the move from Dynamics NAV to Business Central, and what that means for organisations still running NAV.
- Migrating from NetSuite to Business CentralMoving from NetSuite to Business Central — the data and customisation challenges, the cost angle, and what to expect from the project.
- Migrating from QuickBooks to Business CentralMoving from QuickBooks to Business Central — the data migration wizard, scope decisions, parallel running, and the gotchas that catch people out.
- Migrating from SAP Business One to Business CentralMoving from SAP Business One to Business Central — the practical mapping, data migration approach, and the choices that decide the project's complexity.
- Growing from Business Central to Finance and SCMWhen and how to move from Business Central up to Dynamics 365 Finance and Supply Chain Management — signals, scope, and the migration path.