Last updated: November 9, 2026
By ZapAI Team
A Dynamics NAV to Business Central migration moves a NAV database into Microsoft Dynamics 365 Business Central by upgrading through Business Central on-premises version 14, then version 25 or later, and finally running Microsoft’s cloud migration. As of November 2026, NAV 2017 support ends in January 2027 and NAV 2018 support ends in January 2028. Every older NAV version is already out of support.
To migrate Dynamics NAV to Business Central, upgrade NAV to Business Central version 14, convert C/AL customizations to AL extensions, upgrade to version 25 or later, then run cloud migration. Or skip the history and reimplement with fresh data.
Few ERP customers are as loyal as NAV shops. We mean that kindly. NAV was easy to customize, so most installs we see have years of C/AL changes layered on top of each other, written by developers who moved on long ago, and nobody wants to be the person who breaks the invoice posting routine that somehow still works. So the system stays. Patched, paid for, and slowly aging out.
That plan has a clock now. This guide covers what a NAV owner actually has to decide. Which upgrade path your version takes, what happens to customizations, what data moves and what stays, and when a fresh implementation beats an upgrade. Product facts come from Microsoft Learn and Microsoft’s lifecycle and pricing pages, checked on November 9, 2026. Anything that’s ZapAI practice is labeled that way.
Is Dynamics NAV Still Supported in November 2026?
Only NAV 2017 and NAV 2018, and both are in extended support, which means security fixes only. NAV 2017 drops out in January 2027. NAV 2018, the last NAV release, follows in January 2028.
Every NAV release follows Microsoft’s Fixed Lifecycle Policy, roughly five years of mainstream support and five of extended. Here’s where each version stands, from Microsoft’s lifecycle pages.
| Version | Mainstream support ended | Extended support ends | Status, November 2026 |
|---|---|---|---|
| NAV 2009, SP1 and R2 | January 2015 | January 2020 | Out of support |
| NAV 2013 and 2013 R2 | January 2018 | January 2023 | Out of support |
| NAV 2015 | January 2020 | January 2025 | Out of support |
| NAV 2016 | April 2021 | April 2026 | Out of support |
| NAV 2017 | January 2022 | January 2027 | Extended support, two months left |
| NAV 2018 | January 2023 | January 2028 | Extended support |
| Business Central on-premises version 14 | October 2023 | October 2025 | Out of support |
Check your own version against the NAV 2017 lifecycle page and the NAV 2018 lifecycle page. One small wrinkle. Microsoft prints the NAV 2018 cutoff as early on January 12, 2028, Pacific time, while most partner blogs quote January 11. Same week. Don’t plan around the difference.
Version 14 surprises people. The fixed-policy lifecycle page for Business Central on-premises lists October 2025 as the end date for the Spring 2019 release, so companies that stopped at version 14 a few years ago are also unsupported today.
What does unsupported mean in practice? No security patches. No tax or regulatory updates. No help from Microsoft when something breaks. Your partner can still keep the lights on, but every year past the date the risk sits with you, and the pool of people who know C/SIDE gets smaller.
Which Upgrade Path Applies to Your NAV Version?
NAV 2015 through 2018 upgrade to Business Central version 14, then version 25, then the current release. NAV 2013 and 2013 R2 add a stop at NAV 2018 first. NAV 2009 adds two stops before that.
Microsoft’s supported upgrade paths page, updated October 2026, is the source of truth here. The NAV to Business Central online guide adds the cloud step. Combined, they look like this.
| Starting point | Hops to Business Central online | C/AL to AL conversion? |
|---|---|---|
| NAV 2009 SP1 or R2 | NAV 2013 or 2015, then NAV 2018, then version 14, then version 25 or later, then online | Yes, for a full migration |
| NAV 2013 or 2013 R2 | NAV 2018, then version 14, then version 25 or later, then online | Yes, for a full migration |
| NAV 2015, 2016, 2017 or 2018 | Version 14, then version 25 or later, then online | Yes, for a full migration |
| Business Central version 13 | Version 14, then version 25 or later, then online | Yes |
| Business Central versions 14 to 24 | Version 25, then the current version or straight to online | Already AL from version 15 onward |
| Business Central versions 25 to 28 | Direct to version 29, or cloud migration | No |
Count the hops for NAV 2009. Five. Each one is a database conversion, a data upgrade, and a round of testing, which is why we rarely recommend a full technical upgrade from 2009 at all, though we’ll get to that in the decision section.
Also notice the cloud prerequisite. Microsoft’s cloud migration prerequisites require Business Central on-premises version 25 or later as the source, running SQL Server 2016 SP1 or later with compatibility level 130 or higher. No NAV version qualifies directly. None.
Why Do You Still Need Version 14 and Version 25?
Version 14 is the last release that still runs C/AL, so it’s the bridge between NAV’s code model and AL. Version 25 is the floor Microsoft set for cloud migration and for upgrades to newer releases. Both are waypoints, not places to live.
Here’s the odd part. Both waypoints are out of support themselves. Version 14 ended in October 2025. Version 25 ended in April 2026, and version 26 followed in October 2026, per the modern-policy lifecycle page for Business Central on-premises. Microsoft still documents them as upgrade steps. You just shouldn’t go live on them.
Staying on-premises? Aim for version 28 or 29. Version 28 is supported until October 2027 and version 29 until April 2028, and since each on-premises release gets roughly 18 months, an on-premises Business Central customer signs up for an upgrade every year or so for as long as they stay off the cloud. Budget for it. Online, Microsoft applies the updates for you.
One more catch with version 14. Microsoft’s upgrade paths page says new customers can’t use it in production. It’s only a path.
What Happens to Your C/AL Customizations?
They have to become AL extensions before anything reaches Business Central online. Microsoft is blunt about it. Data from tables with code customizations can’t be carried forward unless extensions installed both on-premises and online handle those tables.
The mechanics live in Microsoft’s customization migration guide. Export the C/AL objects in the new text syntax, run them through Txt2Al, build AL projects in Visual Studio Code, fix the compile errors, and test against a sandbox. The C/AL to AL code conversion steps add a detail that matters. Txt2Al ships only with version 14, and you use that copy no matter which later version you’re targeting.
Txt2Al converts syntax. It doesn’t redesign anything. Big difference. A NAV customization that edited codeunit 80 directly still has to be rewritten as an event subscriber, because extensions can’t modify base objects. Microsoft’s guide maps the object types.
- Changed base pages become page extensions. Custom pages become new AL pages.
- Added fields become table extensions.
- Edits inside base codeunits become event subscribers.
- Custom reports become AL reports or report extensions.
- XMLports and queries get rebuilt in AL.
- .NET add-ins need a redesign, since .NET interop isn’t available online.
Three NAV leftovers also die in the move. Codeunit 1 is retired in favor of system events, V1 extensions aren’t supported, and MenuSuite objects are gone, with page and report properties deciding what search finds instead.
One trap we see. For on-premises, the code conversion procedure lets you compile the whole converted application as a custom base app. That gets you onto a modern version. It doesn’t get you to the cloud, where only extensions run, so a team that plans to end up online and stops at a custom base app has bought itself a second conversion project later.
Our practice view? Before converting anything, sort every modification into four piles. Now standard in Business Central. Available on AppSource. Still needed as an extension. Not needed at all. The last pile is usually bigger than the client expects, because a lot of NAV customizations patched gaps Microsoft closed years ago, like approval workflows, bank reconciliation, and document attachments.
What About ISV Add-Ons and Reports?
Every ISV add-on needs a Business Central version from its publisher, a replacement, or retirement. Reports move to AL report objects with RDLC, Word or Excel layouts, and some are better rebuilt in Power BI.
Add-ons first. NAV installs commonly carry several ISV products for things like sales tax, EDI, warehouse scanning, or document capture, and their licenses were sold into the NAV object range. Ask each publisher three questions in week one. Do you have an AppSource version for Business Central online? Does your own upgrade path migrate our data from the NAV tables? What does the new subscription cost? Get answers in writing. Silence on question two is a red flag. Some publishers ship upgrade code that moves their NAV data into the new extension tables. Some don’t, and your partner ends up writing the mapping.
Reports are the hidden budget line. Business Central supports four layout types, Word, RDLC, Excel and External, per Microsoft’s report and document layouts overview. NAV’s RDLC layouts carry over in concept, yet the report objects behind them still need converting to AL. Word layouts are easier for finance people to edit themselves, and if you want custom layouts in emails, Microsoft requires Word, not RDLC. The old Custom Report Layouts page is obsolete too.
Our habit is to rebuild customer-facing documents as Word layouts, keep complex operational reports in RDLC only when someone truly needs them printed, and move analysis to Power BI reporting. Plenty of custom NAV reports turn out to be exports somebody pastes into Excel every Monday. Those don’t need converting. They need a dashboard.
What Data Moves to Business Central Online, and What Doesn’t?
A full cloud migration moves company data from base application tables and from extension tables, including posted history and open entries. It doesn’t move most system tables, users, permissions or record links. Data in unconverted customized tables stays behind.
Behind the scenes, Microsoft’s on-premises to online migration overview describes a pipeline built on Azure Data Factory and a self-hosted integration runtime that copies data table by table. You can replicate repeatedly, deltas run faster than the first pass, and a data upgrade runs in the cloud at the end if the online version is newer. Once that data upgrade finishes, you can’t replicate again from the older version.
| Data | Full cloud migration | Version 14 reimplementation tool |
|---|---|---|
| Master data, setup, dimensions | Yes | Yes |
| Open sales and purchase orders | Yes | Yes |
| Posted ledger history | Yes, all of it | A defined subset, such as posted G/L entries and posted sales invoices |
| Data in converted extensions | Yes, if installed online and set to replicate | Only if you extend the tool |
| Data in unconverted C/AL customizations | No | No |
| Users, permissions, record links | No | No |
Watch storage. Old NAV databases get big. Microsoft’s cloud migration planning guide says tenants start at 80 GB plus allowances per licensed user, suggests keeping each migration run under 30 GB, and warns that some admin tasks get disabled above 80 GB. Online data is compressed, so your SQL size overstates it, but a 15-year NAV database with bloated change log and posting tables needs archiving before the first dry run. The same guide recommends batches of up to 10 companies and at least two dry runs.
Plan for a frozen target, too. Once cloud migration is set up, the online environment can’t take updates, and users without SUPER permissions drop to read-only. So schedule replication between Microsoft’s update windows.
Should You Upgrade or Reimplement?
Upgrade when your history, customizations and processes are worth keeping and you’re on NAV 2015 or later. Reimplement when you’re on NAV 2009 or 2013, when customizations are heavy and poorly documented, or when the business has changed enough that NAV’s setup no longer fits.
Microsoft now names both routes. The NAV online guide calls them full migration and reimplementation, and for companies already on version 14 there’s a version 14 reimplementation tool that moves master data, opening balances, open orders, setup and a subset of posted entries through more than 40 migrators. Two caveats. It’s a preview, and preview features aren’t meant for production. And Microsoft’s own pages disagree on history, since the NAV guide says reimplementation doesn’t carry forward historical transactions while the tool page lists that subset of posted entries.
Below are the decision rules we use per version. They’re ZapAI practice, not Microsoft guidance, and a real assessment of your database can overturn any of them.
| You’re on | Our default recommendation | Why |
|---|---|---|
| NAV 2009 | Fresh implementation, master data and open items loaded from NAV, history kept read-only | Five hops, forms-to-pages transformation for Classic client installs, and code nobody has touched in a decade |
| NAV 2013 or 2013 R2 | Fresh implementation unless customizations are light and well documented | Four hops. The stop at NAV 2018 adds cost without adding anything you keep |
| NAV 2015 or 2016 | Either route. Decide on customization volume and history needs | Same hop count as 2018, but already unsupported, so move this year |
| NAV 2017 | Start now. Upgrade if history matters, reimplement if the setup is tired | Support ends January 2027 |
| NAV 2018 | Upgrade is usually viable. Plan the cutover for 2027 | Shortest path from NAV, and the last NAV with support left |
| Business Central on-premises 14 | Full migration or the reimplementation tool, after a sandbox test of the preview | Already unsupported, and Txt2Al output may already exist |
| Business Central on-premises 15 to 24 | Upgrade to version 25 or later, then cloud migration | Code is already AL, so the work is mostly extension cleanup |
Here’s a quick test. Be honest. If your team can’t name who uses each customization and why, reimplement. If the controller insists on drilling into 2014 invoices inside the ERP, upgrade or keep NAV read-only next to Business Central. Most finance teams pick the read-only archive once they see the price of carrying everything.
Fresh implementations follow the same project shape as any new Business Central rollout, which our Business Central implementation guide covers phase by phase. If you’re also weighing a bigger ERP, read Business Central vs Dynamics 365 Finance first, since Business Central descends from NAV and Finance doesn’t.
What Does Business Central Cost After NAV?
Business Central online lists at $80 per user per month for Essentials, $110 for Premium and $8 for Team Members, on annual commitments. NAV customers moving to the cloud may qualify for a migration discount through a partner.
Those prices come from Microsoft’s Business Central pricing page, checked November 9, 2026. Premium adds manufacturing and service management. The page offers a 30-day trial and shows no on-premises pricing.
Promotions are murkier. Partner sites widely describe a Bridge to the Cloud 3 offer, running January 1, 2026 to December 31, 2027, with 30% off Business Central online licenses for eligible NAV and other on-premises customers with an active Enhancement Plan. We couldn’t find those terms on a public Microsoft page, so ask your partner for the current eligibility rules in writing before you count the discount in a budget.
Licensing logic changes, too. NAV was commonly sold with concurrent users. Business Central online licenses named users. Different math. A 40-person company with 15 concurrent NAV sessions may need 25 full licenses and 15 Team Members, or fewer full seats once you sort out who only approves and reads. Our Business Central pricing breakdown walks through that sorting, and Microsoft notes that internal users with select Microsoft 365 plans can read Business Central data inside Teams at no extra cost.
How Long Does a NAV Migration Take, and What Drives the Cost?
In our practice, a lightly customized NAV 2018 upgrade to Business Central online runs roughly three to five months. Heavily customized installs, older versions, and multi-company databases run six to twelve. Customizations, ISV add-ons, reports and data volume decide where you land.
Those ranges are our experience, not a published benchmark. Nobody has neutral data on this. We looked. What we can say confidently is where the hours go.
- Customization conversion. The biggest swing factor.
- ISV add-ons without a clean upgrade path
- Report rebuilds, document layouts first
- Integrations that wrote straight into NAV tables or used .NET
- Data cleanup and archiving before replication
- The number of upgrade hops for your version
- Dry runs, at least two, with business sign-off on each
- Training. The NAV Windows client is gone, and users move to the browser.
Integrations deserve a closer look. Old NAV integrations wrote into tables over ODBC, dropped files on a share, or called .NET libraries, and Business Central online allows none of that, so each one gets rebuilt on APIs or Power Automate. If you sync with Dynamics 365 Sales, Microsoft’s upgrade considerations require a full upgrade rather than a technical one, and our Business Central and Dynamics 365 Sales integration guide covers the current sync. For services budgets in general, see our Dynamics 365 implementation cost guide.
Where Do NAV Migrations Go Wrong?
Most failures come from converting customizations nobody needs, discovering an ISV add-on late, skipping dry runs, and treating version 14 or 25 as a destination. Bad data and late report work finish the list.
Here are the patterns we see most, in rough order of pain.
- Converting every C/AL object one to one. Txt2Al makes it feel cheap. Testing and maintaining it isn’t.
- Finding the sales tax or EDI add-on in month three, after the timeline is signed.
- Breaking schema changes in converted extensions, which stop synchronization and can strand data.
- One dry run instead of two. The first always fails somewhere. That’s its job.
- Replicating into a live production environment, which Microsoft warns can overwrite data.
- Letting Microsoft update the target environment mid-migration.
- Forgetting users and permissions, since neither migrates.
- Rebuilding reports after go-live, when the AR team can’t find its aging view.
Company names cause a smaller, sillier failure. Microsoft’s upgrade considerations say special characters like periods, ampersands and slashes in a company name can throw errors during upgrade, so rename first and rename back afterward.
Partner fit matters more than people admit. You need both skill sets. A partner who has never touched C/SIDE will struggle with a 2013 database, and a NAV veteran who never shipped an AppSource-grade extension will struggle with the AL side. If your current partner is stuck on one side of that line, our guide to switching your Dynamics 365 partner covers the handover.
What Should Be on Your NAV Migration Checklist?
Inventory, decide, prepare, rehearse, cut over. Below is the checklist we work from, adapted from Microsoft’s own runbook advice plus what we’ve learned on NAV projects.
Inventory
- NAV version and cumulative update, from the help screen, not from memory
- Database size, largest tables, and company count
- Every modified object, grouped by business process
- Every ISV add-on, with publisher contact and upgrade answer
- Every integration and what it writes to
- Every report people actually run. Ask them.
Decide
- Upgrade or reimplement, using the version rules above
- History strategy, full, summarized, or read-only NAV archive
- Online or on-premises, knowing agents and Copilot need online
- License mix, full users versus Team Members
- Cutover date, ideally after a period close
Prepare and rehearse
- Archive old history and trim log tables.
- Confirm SQL Server 2016 SP1 or later and compatibility level 130.
- Rename companies with special characters.
- Convert, compile and test extensions in a sandbox.
- Run two dry runs, timing each one.
- Tie out trial balance, aged receivables, aged payables and inventory value.
Cut over
- Freeze C/AL changes.
- Final replication, then data upgrade.
- Set up users and permissions.
- Reconnect integrations and test each one end to end.
- Keep NAV read-only for audits.
Agents are the reason that third decide item matters. Copilot features and AI agents run only on Business Central online, as our Business Central agents guide explains, so a company that upgrades to on-premises version 29 today gets current code but none of that.
Will Ignite 2026 Change Anything?
Probably not for NAV paths. Ignite runs November 17 to 20, 2026, in San Francisco. Upgrade paths and lifecycle dates rarely move at conferences, but migration promotions and the version 14 reimplementation tool’s preview status could, and we’ll refresh this post if they do.
Wrapping Up
NAV 2017 has two months of support left and NAV 2018 has about fourteen. Every route to Business Central online passes through version 14 and version 25, and every C/AL customization you keep has to become an extension first. So decide early. Upgrade if the history and code are worth carrying. Reimplement if they aren’t, which is usually the case for NAV 2009 and 2013.
ZapAI is a Microsoft Dynamics 365, Power Platform, Fabric and AI consulting firm in Irving, Texas, working with businesses across Dallas-Fort Worth and nationwide. Our Dynamics 365 consultants run NAV assessments, C/AL to AL conversions, cloud migrations and fresh Business Central implementations, and teams coming from other systems can compare notes with our GP to Business Central migration guide or our QuickBooks to Business Central guide. Ready for a straight answer on your database? Ask us for a NAV migration assessment, and we’ll review your version, objects, add-ons and data before recommending a path.
Questions Teams Ask About Moving From NAV
Can NAV 2018 upgrade directly to Business Central online?
No. NAV 2018 upgrades to Business Central on-premises version 14, then to version 25 or later, and only then runs cloud migration to online. C/AL customizations must be converted to AL extensions along the way.
When does Dynamics NAV 2018 support end?
Extended support ends in January 2028. Microsoft’s lifecycle page lists early January 12, 2028, Pacific time, and partners usually quote January 11. Mainstream support already ended in January 2023, so only security fixes ship today.
Is NAV 2016 still supported?
No. Extended support for NAV 2016 ended in April 2026. NAV 2017 follows in January 2027, which leaves NAV 2018 as the only NAV release with support into 2027 and beyond.
Do we lose our NAV history if we reimplement?
Not if you plan for it. A reimplementation usually loads master data, opening balances and open documents, and the version 14 reimplementation tool adds a subset of posted entries. Keep NAV running read-only for older detail.
What is Txt2Al?
Microsoft’s command-line tool that converts exported C/AL objects into AL files. It ships only with Business Central version 14, and Microsoft says to use that copy whatever version you target. Converted code still needs refactoring into proper extensions before it can run online.
Can we stay on Business Central on-premises instead?
Yes. Version 29 is supported until April 2028, and each on-premises release gets about 18 months, so expect an upgrade roughly every year. Copilot and agents need Business Central online.
Do ISV add-ons migrate automatically?
Only if the publisher has a Business Central extension, installed both on-premises and online, plus upgrade code for its NAV data. Ask every publisher for their path in week one, because a missing answer can stall the whole project.