Migrating from NAV on-premise to Business Central SaaS

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:

1. 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.

2. 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.

Where to go next

The context for the move is Business Central vs Dynamics NAV, and the choice you are also making is on-premises vs SaaS. Rebuilding customisations starts with writing your first AL extension and replacing many of them with ISV add-ons; the data side is Business Central data migration.