Migrating from Dynamics NAV to Business Central: The Complete Guide

If your company runs on Dynamics NAV — whether it’s NAV 2009, NAV 2013, NAV 2016, or NAV 2018 — you already know the conversation is coming. Microsoft has been steering the ship toward Business Central for years, and the window for a low-stress, well-planned migration is narrowing. You’re probably asking the same questions every NAV customer asks: How long will it take? What will it cost? Will my customizations survive? And — honestly — do I actually have to do this?

This guide answers all of those, from someone who’s done it many times. No vendor gloss, no scare tactics. Just the reality of migrating from Dynamics NAV to Business Central — what changes, what stays, what breaks, how much it costs, and how to do it without the horror stories. And if you’re coming from Dynamics AX rather than NAV, there’s a dedicated section for you near the end.

Still deciding whether Business Central is really different from NAV (or Navision)? Read our Dynamics NAV vs Business Central comparison first — this article is the how-to.

---

Why the NAV-to-BC Move Is Happening Now

Let’s be direct: Microsoft is not going to rip NAV away from you. But they’ve made the direction unmistakably clear for years. Business Central is the future. NAV is the past. NAV 2018 was the last NAV release — there will never be another one — and the gap between the two gets wider every quarter.

The End of Support

If you’re on NAV 2016 or earlier, you are already past the end of extended support — no security patches, no regulatory updates, no fixes of any kind. For the two versions still covered, “extended support” means security fixes only: no new features, no new regulatory functionality. Here’s where each version stands, according to Microsoft’s lifecycle pages:

NAV version	Mainstream support ended	Extended support ends/ended
NAV 2009 / 2009 R2	Long ago	Ended
NAV 2013 and 2013 R2	January 2018	January 2023
NAV 2015	January 2020	January 2025
NAV 2016	April 2021	April 2026
NAV 2017	January 2022	January 2027
NAV 2018	January 2023	January 2028

The polite way to say it: most NAV installations are now running unsupported, unpatched, and increasingly isolated software. The direct way: every month you stay on an old NAV version is a month your ERP drifts further from the modern Microsoft ecosystem your other tools already moved into.

The Cloud-First Reality

Microsoft’s entire product strategy now flows through the Microsoft Cloud. Copilot AI, real-time Power BI, automated bank feeds, e-documents — all of it assumes you’re on a connected, continuously updated platform. NAV, even in its most recent on-premise versions, sits outside that ecosystem.

Business Central gets monthly updates. NAV gets nothing. After a few years, those compound — the gap between what you’re running and what the market considers standard becomes a competitive liability, not just a technical inconvenience.

It’s Not Just Microsoft Pushing

Your IT team wants off the server management treadmill — patches, backups, SQL Server upgrades, remote access. Your finance team wants real-time reporting that doesn’t involve exporting to Excel. Your auditors are asking about segregation of duties and audit trails that older NAV versions handle poorly. And an unsupported on-premise ERP with a SQL Server backend, running code that hasn’t been patched in years, is a security finding waiting to happen.

The question isn’t whether to migrate from Dynamics NAV to Business Central. It’s when and how. This guide answers both.

---

What Actually Changes: NAV vs. Business Central

Moving from NAV to BC isn’t like switching from SAP to Oracle. It’s the same DNA — Microsoft bought Navision in 2002 and has been evolving it ever since. But 20+ years of evolution add up to a genuinely different experience. Here’s exactly what’s different.

Area	Dynamics NAV	Business Central
Deployment	On-premise server. You own the hardware, SQL Server licenses, backup strategy, and the 2 AM calls when it goes down.	Cloud SaaS by default. Microsoft runs it, patches it, backs it up. On-premise available, but SaaS is the default and gets features first.
UI/UX	Classic Windows client (or the RoleTailored Client in later versions). Familiar, functional, dated.	Modern browser-based interface. Same on desktop, tablet, phone. Role centers that actually look like they were designed in this decade.
Customizations	C/AL code written directly in the base application. Merging upgrades meant code conflicts, regression testing, and a week of your consultant’s time.	AL extensions — clean, isolated code that sits on top of the base system. Microsoft updates the base, your extensions stay intact. Upgrade weekends shrink from days to hours.
Licensing	Perpetual licenses (buy once) with an annual enhancement plan.	Subscription (SaaS): Essentials ($80/user/month), Premium ($110/user/month), Team Members ($8/user/month) at US list prices since November 2025.
Updates	Upgrades planned months in advance, with downtime — or, realistically, no upgrades at all.	Monthly automatic updates. Two major release waves per year (April, October).
Extensions marketplace	Limited. Most partners built from scratch or relied on the same few ISV solutions.	AppSource — a full marketplace with thousands of ready-made extensions. Audit trails, approval workflows, document capture, shipping integrations — install in minutes.
AI & Copilot	None. Zero.	Copilot built into the product — AI-generated product descriptions, bank reconciliation suggestions, late payment prediction, analysis views, agents. More capabilities ship every release.
Integration	Mostly custom — web services, file-based imports, third-party middleware. Each one a project.	Native REST APIs, Power Automate connectors, Dataverse, Microsoft 365 integration. Connects to Outlook, Teams, Excel, and Power BI out of the box.
Mobile	Third-party or workarounds.	Native mobile apps on iOS and Android, same interface.
Compliance & audit	Manual configuration. Regulatory updates depended on partner-delivered hotfixes.	Built-in audit trails, change log, GDPR tools. Localization and regulatory updates delivered by Microsoft and localization partners.

The bottom line: Business Central is what NAV would be if it had been rebuilt for the cloud from scratch — which, effectively, it was. The shift is from “software you own” to “service you use,” and that changes almost everything about how your business interacts with the system.

The Technical Changes That Drive Migration Effort

The table above is what your users will notice. This one is what your project plan has to account for:

Area	Dynamics NAV	Business Central	Migration impact
Development language	C/AL, embedded in the base application	AL, in isolated extensions	Major. All custom code must be retired, replaced or rewritten.
Custom fields	Added directly to Microsoft’s base tables	Added through table extensions	Major. Custom fields need AL table extensions; direct changes to standard tables are impossible.
Development environment	C/SIDE, built into NAV	VS Code with the AL Language extension	Moderate. Developers switch tools — for the better.
Reports	Classic reports (NAV 2009) or RDLC layouts (NAV 2013+)	Word, Excel and RDLC layouts, Power BI	Moderate. Classic reports need a full rebuild; RDLC layouts can sometimes be adapted.
Web services	SOAP and OData, configured manually	REST APIs, OData, Power Automate connectors	Moderate. Custom SOAP endpoints become BC APIs.
ISV add-ons	.fob files merged into the base application	Extensions from AppSource or the ISV	Varies. Most major ISVs have BC versions; niche add-ons often don’t.
XMLports	Import/export, customizable in C/AL	Same concept, written in AL	Low. Functionally identical.

---

What Stays the Same: Your Business Logic Survives

Here’s what every NAV customer worries about, and the honest answer: your business processes, your core data structures, and the way you think about your ERP — those don’t change nearly as much as you might fear.

The table structure is familiar. Business Central’s underlying database is still built on the same relational model. General ledger entries, customer ledger entries, item ledger entries, value entries — these core tables haven’t been redesigned from scratch. The data structures your finance team understands are preserved.

Posting groups still work the same way. General business posting groups, general product posting groups, VAT posting setups — the logic your NAV system uses to determine how transactions post to the general ledger is functionally identical. If you understand posting groups today, you’ll understand them tomorrow.

The chart of accounts and dimensions carry over. Your existing CoA can be migrated intact, and dimensions — one of NAV’s most powerful features — work the same way in BC.

Purchasing and sales cycles follow the same document flow. Quote → Order → Ship/Receive → Invoice. The document sequence your team has been executing for years is unchanged, right down to the field names and posting logic. The interface looks different, but the process maps to the same steps.

The C/AL to AL shift is about architecture, not functionality. This is the single biggest misconception. Yes, your C/AL customizations need to be rewritten as AL extensions. But the business logic — what the code actually does — is what gets re-implemented. It’s translation, not reinvention. And the result is cleaner, more maintainable, and upgrade-safe in a way C/AL never was.

A concrete example: a NAV client of ours had a custom purchasing approval workflow written in C/AL across three codeunits and two tables. In the Business Central migration, the approval rules stayed identical — but instead of being buried in the base application, they became a clean AL extension on top of BC’s standard workflow engine, untouched by any future Microsoft update.

The migration is not a reset. Your team won’t walk into Business Central and feel like they’re learning a completely foreign system. They’ll recognize the logic, the terminology, the document flow. The learning curve is real — especially for users who spent decades in the Windows client — but it’s a ramp, not a cliff.

---

Migration Paths: Cloud SaaS vs. On-Premise BC

When you migrate from Dynamics NAV to Business Central, you have two deployment options — and the choice shapes your timeline, costs, and experience for years.

Option 1: Business Central Cloud (SaaS)

This is Microsoft’s recommended path, and in our experience, it’s the right answer for roughly 90% of NAV customers.

What you get: Business Central running on Microsoft’s Azure infrastructure. Microsoft handles uptime, security, backups, disaster recovery, and every update. You access it through a browser. That’s it.

The advantages:

• No servers to maintain. Your IT team stops worrying about ERP infrastructure entirely.
• Always current. Updates arrive automatically. You’re never behind on features, security, or regulatory compliance.
• Native integration with Microsoft 365. BC talks to Outlook, Teams, Excel, and Power BI out of the box.
• AppSource extensions install with a few clicks. No server access needed.
• Lower total cost. No SQL Server licenses, no Windows Server licenses, no backup infrastructure, no server hardening.

The constraints:

• You can’t access the SQL database directly. Reporting runs through APIs or Power BI, not direct queries.
• No file system or COM access on the server — integrations and automations that depend on them must be rebuilt.
• You’re on Microsoft’s update cadence, not yours. Major releases happen in April and October, and you can delay them by a window — but you can’t skip them permanently.

Who it’s for: Every NAV customer who doesn’t have a specific, hard reason to stay on-premise.

Option 2: Business Central On-Premise

The on-premise version of Business Central exists — but it’s a deliberate minority offering. It’s for companies that have regulatory, operational, or contractual requirements to keep their ERP data on servers they control.

The trade-offs:

• You maintain your own infrastructure, just like you did with NAV.
• Updates are manual. You decide when to apply them, but you also own the responsibility of doing so — and each on-premise version has a limited support window, so you can’t freeze it the way you froze NAV.
• Some cloud-only features (certain Copilot capabilities, some integrations) aren’t available.
• It costs more to run over time when you factor in infrastructure and IT staffing.

Who it’s for: Organizations in heavily regulated industries where cloud isn’t an option, or companies with specific data sovereignty requirements that Azure’s regional data centers don’t satisfy.

Our Honest Recommendation

Unless you have a legal, regulatory, or contractual requirement to stay on-premise, go SaaS. The economics, the feature velocity, and the operational simplicity all point in one direction. We’ve migrated NAV customers to both, and the SaaS implementations are consistently faster, smoother, and cheaper to maintain.

If you need to understand the full cost picture across both deployment models, our Business Central implementation costs guide breaks down partner fees, licensing, and hidden costs in detail.

---

Choosing Your Upgrade Route: Full Migration, Reimplementation, or Hybrid

This is the decision that shapes your budget more than any other — and it depends mostly on which NAV version you’re on.

Microsoft’s Official Route

There is no direct jump from NAV to Business Central online. Per Microsoft’s migration documentation, every NAV database first goes through Business Central 14 on-premises (the last version that still ran C/AL), then to a current on-premises version, and only then through the Cloud Migration tool to BC online:

Starting version	Supported upgrade route
NAV 2015, 2016, 2017, 2018	BC 14 on-prem → BC on-prem v25 or later → BC online
NAV 2013 / 2013 R2	NAV 2018 → BC 14 on-prem → BC on-prem v25 or later → BC online
NAV 2009 SP1 / 2009 R2	NAV 2013 or 2015 → NAV 2018 → BC 14 on-prem → BC on-prem v25 or later → BC online

Two things follow from that table. First, the more hops, the more a “technical upgrade” costs — a NAV 2009 database has to be upgraded four times before it reaches the cloud. Second, Microsoft itself offers an alternative: once you reach BC 14, a reimplementation tool can move only the essentials (master data, opening balances, setup) without converting customizations or carrying historical transactions.

The Three Practical Paths

Path 1: Technical upgrade (full migration). Your NAV data comes across with its history; every C/AL modification is triaged and rebuilt as an AL extension. Processes stay largely the same; the platform underneath changes. Best for: NAV 2015–2018 with moderate customizations where the business logic is still valid. This is what most people mean by “NAV upgrade.”

Path 2: Reimplementation (fresh start). You start with a clean Business Central, configure it around how you work today, and bring over master data, open balances and open documents. Old history stays in a read-only NAV archive. Best for: NAV 2009–2013 with extensive, often obsolete customizations. Companies that want to redesign processes rather than replicate them. You’re not paying developers to translate 2009-era C/AL written by a partner who’s no longer in business.

Path 3: Hybrid (phased). Finance and core operations go live first with the critical customizations; the remaining modules, integrations and extensions follow in phase two. Best for: mid-size companies that can’t afford one long go-live window, or where some modules (manufacturing, service) are mission-critical and others are nice-to-have. This is the lowest-risk path — finance can be live in 8–10 weeks.

Real paths we’ve delivered:

NAV version	Customer profile	Path taken	Duration
NAV 2009	Regional distributor, heavily customized	Reimplementation	5 months
NAV 2013	Wholesale + light manufacturing, moderate C/AL	Reimplementation	4 months
NAV 2015	Multi-entity services company, 30+ C/AL objects	Hybrid (finance first, operations in phase 2)	5 months
NAV 2017	Single-entity manufacturer, 15 C/AL modifications	Technical upgrade	3 months
NAV 2018	Distribution company, already using extensions	Technical upgrade, minimal rewrite	2 months

Timeline by NAV Version

Your NAV version	Typical path	Timeline	What drives the timeline
NAV 2009 and earlier	Reimplementation	4–6 months	Heavy C/AL debt, Classic reports must be rebuilt, processes likely need redesign, integrations are all custom
NAV 2013 / 2013 R2	Reimplementation	3–5 months	Two extra upgrade hops for a technical upgrade; integrations need rebuilding
NAV 2015	Hybrid or reimplementation	3–5 months	RDLC reports partially reusable, ISV assessment needed
NAV 2016	Technical upgrade or hybrid	2–4 months	Less C/AL debt, better data quality
NAV 2017	Technical upgrade	2–4 months	Direct route via BC 14; effort is mostly customization rewrite
NAV 2018	Technical upgrade (fastest)	2–3 months	If your partner already built new features as AL extensions, migration is mostly data and configuration

The NAV 2018 advantage: If you’re on NAV 2018 and your customizations are already extensions, you’re in the best possible position — this is the 2-month path. Still running C/AL modifications on NAV 2018? Add 1–2 months for the AL rewrite.

The NAV 2009 reality: You’re not doing a technical upgrade. You’re doing a reimplementation that happens to share a data model with your target system. The good news: standard Business Central now covers functionality that required heavy customization in 2009 — warehousing, intercompany, multi-currency, approvals. What took 40 C/AL objects in 2009 might be 5 AL extensions today.

---

The Migration Process: Phase by Phase

A NAV-to-BC migration follows a structure similar to a standard Business Central implementation, but with specific differences that only apply when you’re coming from NAV. If you’re evaluating partners, our implementation services cover the full process — assessment through hypercare. Here’s how the migration phases work.

Phase 1: Discovery & Assessment (Weeks 1–2)

Before any code is touched, we need to understand what we’re dealing with. This phase is fast but critical.

What we look at:

• Your NAV version, build number, and customization history
• All C/AL modifications — objects modified, new objects created, ISV solutions installed
• Database size, table row counts, and data quality indicators
• Integrations: what connects to your NAV, how, and how critical it is
• User counts, permission sets, and security requirements
• Third-party add-ons (LS Retail, Continia, Jet Reports, task management, etc.) and their BC equivalents

The deliverable: A migration assessment document that tells you exactly what maps cleanly, what needs rewriting, what can be retired, which upgrade path fits, and what the effort looks like before you commit to anything.

Your role: Provide system access (database backup, NAV license file, list of ISV solutions). Assign someone who knows the history — which customizations are still used, which were built for a person who left five years ago, which reports actually get run.

Phase 2: Solution Design (Weeks 2–4)

With the assessment in hand, we design the target architecture. This is where decisions get made about what the future looks like.

Key decisions:

• Cloud or on-premise: Final call based on business requirements, not default assumptions.
• Upgrade path: Technical upgrade, reimplementation, or hybrid (see above).
• Extension strategy: Which C/AL customizations map to standard BC features (retire), which become AL extensions (rewrite), and which get replaced by AppSource solutions (replace).
• Integration redesign: Which integrations can be simplified using native BC connectors or Power Automate, and which need custom rebuilds.
• Data migration scope: What comes over — master data, open transactions, historical balances, posted entries. How much history (all of it? last 3 years? last 5 years?).
• Phasing: Whether to go all at once or phase the migration (finance first, operations in wave two).

The most important conversation in this phase: which customizations to keep. Every NAV instance older than 3–4 years has code that nobody uses anymore. Menu items that were added for a project in 2015. Reports that ran once and never again. Custom fields populated for six months then abandoned. A migration is the best opportunity you’ll ever have to clean house — and reducing your customization footprint reduces cost, complexity, and future maintenance.

Phase 3: Data Migration (Weeks 3–8, intensifies closer to go-live)

Data migration from NAV has a specific rhythm that’s different from migrating from a non-Microsoft system.

The good news: Because BC evolved from the same codebase, the data structures are highly compatible. Most table mappings are direct. Field names are recognizable. The migration tooling is mature.

The process:

1. Extract — Pull data from your NAV SQL database. This is usually straightforward — it’s a SQL Server database with well-documented schemas.
2. Profile — Run analysis on the extracted data. Find duplicates, missing required fields, orphaned records, inconsistencies between main tables and subledgers.
3. Cleanse — Fix what needs fixing. De-duplicate customers and vendors. Standardize item descriptions. Close or clear out transactions that were never properly settled. You do this part — only your team knows what’s real and what’s a data artifact from 2012.
4. Map — Define how each NAV table and field maps to Business Central. For most standard tables (G/L Entry, Customer, Vendor, Item), mappings are well-established. Custom tables from C/AL modifications need custom mapping rules.
5. Transform — Apply business rules. Map NAV dimension codes to BC dimension values. Convert C/AL custom field data to AL extension tables.
6. Load — On a technical upgrade, the upgraded on-premises database is replicated to BC online with Microsoft’s Cloud Migration tool. On a reimplementation, data is loaded through configuration packages (RapidStart) or the BC 14 reimplementation tool.
7. Verify — Run reconciliation reports. Compare G/L balances, customer/vendor aging, inventory valuation. Confirm open purchase orders and sales orders match.

We run at least two full migration dry runs before the final cutover. The first one surfaces what’s broken. The second one confirms the fixes. The final one — over the go-live weekend — should be a well-rehearsed process, not a discovery exercise.

What takes the most attention:

• Open transactions — partially shipped orders, partially invoiced shipments, unapplied payments. These are always the messiest.
• Dimensions — if your NAV dimensions were inconsistently applied (and most were), the migration rules need to handle defaults, overrides, and exceptions.
• Inventory valuation — the reconciliation between your NAV inventory value, your physical counts, and what BC calculates post-migration needs to balance to the cent.

Phase 4: C/AL to AL — Handling Legacy Customizations (Weeks 3–8, parallel with data migration)

This is the part of the NAV-to-BC migration that generates the most anxiety — and, in our experience, it’s usually less painful than people expect once they understand the approach.

What’s happening: Every piece of C/AL code in your NAV system — custom reports, modified pages, extended tables, custom codeunits — needs to be reimplemented in AL. You cannot copy-paste C/AL code into Business Central. It doesn’t work, and it wouldn’t be a good idea even if it did.

The approach we use, refined across our NAV migration projects:

1. Triage — Categorize every C/AL modification into one of three buckets:

   • Retire: The functionality is covered by a standard BC feature. Remove it.
   • Replace: An AppSource extension does the same thing, often better. Install it.
   • Rewrite: The business logic genuinely needs a custom extension. Build it in AL.

2. Rewrite what remains — The AL reimplementation follows the same business rules as the C/AL original. The same calculations, the same validations, the same workflow triggers. The only thing that changes is the code language and the architecture — AL sits cleanly on top of the base application as an extension, where C/AL was woven into it.

3. Test with real data — Extensions are tested in the sandbox environment with migrated data. The same scenarios that worked in NAV should produce the same results in BC.

A real example: A manufacturing client running NAV 2016 had 28 C/AL modifications — custom production order statuses, a material availability check, modified capacity planning logic, and several custom reports. After triage: 6 were retired (covered by BC’s improved manufacturing module), 4 were replaced (AppSource solutions for shop floor data collection and quality management), and 18 were rewritten as AL extensions. Total AL development: 18 days across two sprints. The business logic was preserved exactly — the team didn’t notice the difference in outcomes, only in the cleaner interface.

Your role: Provide the business context for each customization. We need to know not just what the code does, but why it was built and whether it’s still needed. An hour of your time in triage saves days of unnecessary development.

Phase 5: Build, Configure & Integrate (Weeks 4–12, varies by scope)

Parallel to the data migration and AL rewrite tracks, the standard implementation work runs:

• Core configuration: chart of accounts, dimensions, posting groups, currencies, payment terms
• Process setup: sales cycle, purchasing cycle, approval workflows
• Role centers: customized for each user profile — finance, sales, purchasing, warehouse, executive
• Integration rebuild: what used to talk to NAV now talks to BC. If it was a custom web service, it becomes a standard BC API. If it was a file import, it probably becomes Power Automate.
• Extension development: the AL rewrites from Phase 4 are built here
• Reporting: Power BI dashboards, custom report layouts, financial reporting

The sprint rhythm: 2-week cycles. At the end of each sprint, you see working software — not a PowerPoint, not a spec document. A sandbox environment with your data, your configuration, your extensions.

Phase 6: Testing & User Acceptance (Weeks 6–final)

Testing in a NAV migration has a specific flavor: parallel validation. Your team runs the same processes in both NAV and BC, comparing outputs.

• Run month-end close in both systems and compare trial balances
• Process a sales order end-to-end in both and compare G/L entries
• Run inventory valuation in both and reconcile differences
• Execute your most complex scenarios — intercompany transactions, multi-currency, advanced dimensions

UAT isn’t just about confirming the system works. It’s about confirming that the migrated system produces the same business results as the one it’s replacing. Any discrepancy gets investigated — it’s usually a mapping issue, not a bug.

Your role: Assign your best people to UAT. Not the person who can spare the time — the person who knows the processes inside out and will immediately spot when a customer aging report doesn’t match or a VAT calculation is off.

Phase 7: Training (Weeks 8–12, final 2–3 weeks before go-live)

The UI change from the Windows client to a browser interface is the single biggest adjustment for NAV users. Training needs to address it head-on.

The approach:

• Role-based training — finance team, sales team, purchasing, warehouse. Each session covers their specific processes using real scenarios with migrated data.
• Navigation bootcamp — a focused session on the interface itself: how search works, how to personalize pages, how FactBoxes replace the old NAV panels, how the web client keyboard shortcuts differ from the Windows client shortcuts.
• Recorded sessions — every training is recorded. New hires, absent employees, and people who “forgot how to do the thing” can rewatch.
• Quick-reference guides — one-pagers per role. Not 50-page manuals. “Here’s how you create a sales order. Here’s how you post a purchase invoice. Here’s the shortcut to find a customer card.”

Phase 8: Go-Live & Hypercare

The go-live weekend for a NAV-to-BC migration follows a structured cutover:

1. Freeze NAV — last transactions entered, final data snapshot taken
2. Final data migration — the last, rehearsed run pulls the final NAV data into BC
3. Reconciliation — open balances verified, inventory confirmed, bank balances matched
4. System switch — users directed to the BC URL. Monday morning, they log in and work.
5. Hypercare — 2–4 weeks of on-call support. Our team is available on your communication channel (Teams, Slack, WhatsApp) for immediate questions. Days 1–3: everyone has questions. Days 4–10: the edge cases surface. Days 11–28: it normalizes.

The most important go-live decision: Keep NAV accessible as read-only for at least 4 weeks. If a user needs to verify a historical transaction, a VAT number from a 2019 invoice, or an item cost from before the migration, they can look it up. It removes the anxiety of “what if I can’t find something” and lets your team focus on learning BC instead of worrying about data loss.

---

What Breaks — and What to Do About It

Every migration has casualties. C/AL code is the obvious one (covered above). These are the less obvious ones that blow up budgets when nobody scoped them.

1. ISV Add-ons Without BC Versions

Most major ISV solutions — Jet Reports, Continia, LS Retail — have Business Central versions and migration paths. Smaller, niche or older add-ons often don’t. If your document capture tool was built by a local partner in 2012, it’s probably not getting a BC port.

What to do: Inventory every ISV solution during assessment. Check AppSource for BC equivalents. For anything without a path forward, find an AppSource replacement or build the functionality as a custom AL extension.

2. File-Based Integrations

If your NAV talks to other systems by dropping CSV files into shared folders or reading XML from FTP servers, those integrations will break. Business Central SaaS doesn’t give you file system access on the server.

What to do: Replace file-based integrations with REST APIs or Power Automate flows. The replacement is usually better — real-time instead of batch, proper error handling, an audit trail — but it’s work that needs to be scoped.

3. COM and Automation Objects

NAV automation that controlled Excel, Word or Outlook through COM doesn’t exist in Business Central SaaS. There’s no Windows COM layer to call.

What to do: Excel automation becomes BC’s built-in Excel layouts or Power BI. Outlook automation becomes the BC Outlook add-in or Power Automate. Document generation becomes Word layouts. More work up front, but you’re replacing fragile hacks with supported features.

4. Classic Reports (NAV 2009 and Earlier)

The Classic report writer has no migration path to Business Central whatsoever. Those reports need to be rebuilt from scratch.

What to do: Rebuild as Word layouts (invoices, statements), Excel layouts (analysis), Power BI dashboards (interactive reporting), or AL reports. In our experience the rebuilt reports are better — filterable and automatically refreshing.

What actually survives:

• Your data — all of it, if you want it
• Your chart of accounts and dimensions
• Your posting groups and posting logic
• Your business processes (the logic transfers, even if the code doesn’t)
• Your user permissions structure (translated, not copied)

---

Timeline and Cost: Three Migration Profiles

Every NAV migration is different, but they cluster into three rough profiles. Here’s what they look like in terms of time and money.

The rule of thumb: a NAV-to-BC migration usually costs 50–70% of a new Business Central implementation for the same scope. The discount comes from familiar data structures (less mapping), known processes (less discovery), and users who already understand the ERP logic (less training).

Profile 1: Lightweight NAV Upgrade

Attribute	What It Looks Like
Your NAV	Standard NAV 2016–2018, minimal C/AL modifications (≤10 objects touched), clean data, single legal entity
Scope	Finance core + basic supply chain. Retire most customizations. Go SaaS.
Customizations	Most retired, 2–3 small AL rewrites, maybe 1–2 AppSource installs
Data migration complexity	Low — standard tables, clean data, minimal open transaction cleanup
Duration	8–12 weeks
Partner fee	€8,000–18,000
What’s included	Assessment, configuration, data migration, basic AL rewrites, training, go-live, 2-week hypercare

Profile 2: Standard NAV Migration

Attribute	What It Looks Like
Your NAV	NAV 2013–2018, moderate customizations (10–40 C/AL objects), some data quality issues, integrations to other systems
Scope	Full finance + supply chain. Rewrite core customizations as AL extensions. Add Power BI reporting.
Customizations	30–50% retired, 5–15 AL rewrites, 2–4 AppSource installs
Data migration complexity	Medium — messy open transactions, dimension inconsistencies, multiple data sources
Duration	3–5 months
Partner fee	€18,000–40,000
What’s included	Full assessment and design, configuration, data migration with multiple dry runs, AL extension development, integration rebuilds, role-based training, go-live, 4-week hypercare

Profile 3: Complex Multi-Entity NAV Migration

Attribute	What It Looks Like
Your NAV	NAV 2009–2017, heavy customizations (40+ C/AL objects), multiple legal entities, multi-country, LS Retail or other vertical ISV, integrations galore
Scope	Multi-entity configuration, heavy AL rewrite effort, phased replacement, LS Central migration, complex intercompany
Customizations	Extensive triage and rewrite. 20+ AL extensions. Multiple AppSource solutions.
Data migration complexity	High — multiple NAV databases, intercompany balances, inter-entity trade, complex inventory
Duration	5–9 months
Partner fee	€45,000–60,000+
What’s included	Everything above plus multi-entity design, intercompany configuration, extensive AL development, possibly LS Central deployment, extended hypercare

Microsoft licensing is on top of these partner fees. Since November 2025, US list prices are $80/user/month for Essentials, $110 for Premium and $8 for Team Members (euro prices vary by country). A 20-user company with 8 Essentials, 2 Premium and 10 Team Members lands at about $940/month at list. That’s often comparable to — or lower than — what they were paying for their NAV enhancement plan plus server infrastructure, because BC’s role-based model lets you put occasional users on Team Member licenses.

What makes a migration more expensive:

• Heavy C/AL customization footprint (more rewrite effort)
• Dirty master data requiring extensive cleansing
• Complex integrations needing full rebuilds
• Multi-entity setups (intercompany, consolidation, multi-currency)
• Delayed decisions that stretch the project calendar

What keeps costs down:

• Clean data — invest in cleanup before the migration starts
• A decisive project lead who can make calls without escalation
• Willingness to retire unused customizations instead of rewriting them
• A phased approach — finance first, operations later
• AppSource extensions instead of building everything custom

For a comprehensive breakdown of what drives costs in each category, see our Business Central implementation costs guide.

---

What Nobody Tells You About the NAV-to-BC Migration

From our implementations — a solid chunk of them NAV-to-BC migrations specifically — here are the patterns that show up again and again.

1. C/AL Customizations Need Rewriting, Not Migration

This is the one that catches people off guard. There’s no “import my NAV codeunits” button. Your C/AL modifications — every modified table, page, report, and codeunit — need to be reimplemented in AL.

But here’s what nobody says: this is a feature, not a bug. After a decade of patches, workarounds, and “temporary” fixes that became permanent, most NAV instances carry a lot of dead code. The triage process — retire, replace, or rewrite — forces a cleanup that would never happen otherwise. Companies routinely find that 30–50% of their customizations are either obsolete or replaceable with standard BC features.

Yes, there’s a cost to rewriting what remains. But the result is a cleaner system that takes Microsoft updates without the merge-and-regression cycle NAV upgrades required. The alternative — keeping those C/AL modifications in an on-premise system that drifts further from support every year — gets more expensive fast.

2. NAV Data Is Often Cleaner Than Feared

Companies who’ve been on NAV for 5–10+ years brace for a data nightmare. In practice, what we typically find:

• Core financial data is solid. G/L entries balance. Customer and vendor ledgers reconcile. The double-entry accounting model is self-correcting.
• Master data has cruft. Inactive customers from 2014, duplicate vendors with slightly different names, item cards with no transactions in 3 years. This is cleanup, not corruption — and the migration is the right time to do it.
• Open transactions need attention. Partially shipped orders that were closed off-system, pending invoices that were paid but never applied. These exist in every legacy system and take a few focused days to resolve.
• Dimensions — the usual suspect. Most NAV implementations underused dimensions, overused dimensions, or applied them inconsistently. The migration is an opportunity to define a clean dimension strategy and enforce it going forward.

Compared to companies migrating from non-Microsoft ERPs, NAV customers have a much smoother data path. The common heritage means far fewer square-peg, round-hole mapping issues.

3. Your License Count Usually Decreases

This surprises people, but it’s consistent: when you move from NAV to BC SaaS, you usually end up with fewer full licenses.

Here’s why: NAV’s legacy licensing — especially in older versions — was based on concurrent users or broad full-user licenses. A warehouse worker who logged into NAV once a day to print a picking list counted as a full user. A shop-floor supervisor who checked inventory availability three times a week had a full license.

BC’s tiered model (Team Members at $8/month for read-only and light tasks, Essentials at $80 for full finance/sales users, Premium at $110 for manufacturing and service) means you license people for what they actually do. It’s common to go from 30 NAV full users to something like 8 Essentials, 2 Premium and 12 Team Members.

4. The First Month Feels Slow — Then It Accelerates

This is the change management reality nobody warns you about. The first two weeks post-go-live, your team will be slower at everything. Creating a sales order takes 30% longer. Finding a customer card takes a few extra clicks. Posting a journal entry feels unfamiliar.

Then something shifts around week 3–4. The interface becomes familiar. Users discover that search is faster than navigating menus. They start using personalization to build their own views. And by month 2–3, they’re doing things in BC that were difficult or impossible in NAV — the things that were part of the business case for migrating in the first place.

Plan for the slowdown. Communicate it openly. “For the first two weeks, some things will take longer. That’s normal. By week four, you’ll be faster than before.” Setting the expectation prevents the panic that happens when people don’t know the slowdown is temporary.

---

Migrating from Dynamics AX to Business Central

We get this question more often than you’d think: “We’re on Dynamics AX — can we do the same thing?” Yes, but it’s a different kind of project, and you should know why before you ask for quotes. This is the short version; the full guide is Dynamics AX to Business Central migration.

Why AX to Business Central Is Not an Upgrade

Business Central descends from NAV. Dynamics 365 Finance & Operations (F&O) descends from AX. They’re two different codebases — AX is written in X++ with its own data model — so nothing about an AX database maps to BC the way NAV does.

In practice that means:

• There is no upgrade path from AX to Business Central. Microsoft’s supported upgrade from AX 2012 goes to F&O, not BC. AX 2009 has no upgrade path to Dynamics 365 at all.
• There is no Microsoft cloud migration engine for AX. BC’s built-in Cloud Migration covers Business Central on-premises, Dynamics GP and Dynamics SL (NAV gets there via BC on-premises). Since April 2026, partners can build custom migration engines for any SQL-based source on the same framework — but for AX that’s partner tooling, not a Microsoft product.
• Support is over. AX 2012 R3 — the last AX release — reached the end of extended support in January 2023. Every AX installation is now unsupported.

So an AX to Business Central migration is a reimplementation of Business Central plus a data migration: master data (customers, vendors, items, chart of accounts), open AR/AP, opening G/L balances, open sales and purchase documents, and inventory quantities and costs — loaded through configuration packages, Excel templates or partner migration tooling. Historical transactions usually stay in an archived AX database or a data warehouse.

Business Central or Finance & Operations?

A lot of AX customers were sold a bigger system than they needed in the 2000s, and they’re the ones who benefit most from moving to BC.

Business Central is usually the right fit if:

• You have up to a few hundred users, most of them in a handful of legal entities
• Your processes are standard distribution, services, project-based or discrete manufacturing
• Much of your X++ customization exists to work around AX, not to support a genuine competitive process
• Total cost of ownership matters — BC’s licences and implementations cost a fraction of F&O’s

Finance & Operations is usually the right fit if:

• You run many legal entities across countries with shared services and complex consolidation
• You need advanced warehouse management, process manufacturing, or very high transaction volumes
• You want to keep AX 2012 history and data structures through Microsoft’s supported upgrade path
• Your customizations encode real competitive processes that BC’s standard functionality won’t cover

What an AX-to-BC Project Looks Like

Attribute	Typical AX → BC project
Approach	Reimplementation + data migration (no code or data upgrade)
Duration	4–9 months, depending on entities, modules and integrations
Partner fee	Priced like a new implementation — typically €18,000–40,000 for a standard scope and €45,000–100,000+ for complex multi-entity projects
Biggest effort drivers	Mapping AX financial dimensions and account structures to BC’s chart of accounts and dimensions, rethinking processes built around X++ customizations, rebuilding integrations, retraining users on a different UI

Don’t expect the 50–70% “NAV discount” — there’s no shared data model to lean on. Expect a normal Business Central implementation with a heavier data migration and process-redesign phase.

---

Migration Prep Checklist

Before you talk to a partner, get this ready. The more of it you can answer, the faster you’ll get an accurate timeline and price.

Know Your Current Setup

• NAV version and build number (Help → About)
• Database size (in GB) and approximate row counts for key tables
• List of all C/AL modifications (modified objects, new objects, custom reports)
• List of all ISV solutions and their versions (Jet Reports, Continia, LS Retail, etc.)
• Number of users by role (finance, sales, purchasing, warehouse, shop floor, read-only)

Know Your Data

• Number of active customers and vendors (not the total count)
• Number of inventory items and whether descriptions are standardized
• Approximate volume of posted entries (G/L, customer ledger, vendor ledger)
• Known data quality issues (duplicate customers, orphaned records, unreconciled balances)
• How much history you want in BC (2 years? 5 years? everything?)

Know Your Integrations

• Every system that connects to NAV (e-commerce, payroll, CRM, warehouse, banking, reporting tools)
• How each integration works (API, file drop, database link, manual export/import)
• Which integrations are critical vs. nice-to-have

Know Your Decision-Makers

• Project sponsor (an executive with authority to remove roadblocks)
• Project lead (someone with 8–12 hours/week to dedicate)
• Who decides the financial structure (CoA, dimensions, posting groups — hard to change later)
• Who signs off on go-live readiness

Know Your Timeline

• Preferred go-live window (avoid year-end close, busy season, audit periods)
• Hard deadlines (end of extended support, server hardware lease renewal, audit findings)

---

FAQ

When should I migrate? Can I wait another year or two?

Extended support for NAV 2016 ended in April 2026. NAV 2017’s ends in January 2027, and NAV 2018 — the last NAV release — in January 2028. Waiting until the deadline is expensive: migrations done under pressure, when support has lapsed and something has broken, cost more, take longer, and carry more risk. The best time to migrate is when you can plan it properly. Start the conversation 6–12 months before you want go-live.

How much does a NAV to Business Central migration cost?

Partner fees run €8,000–18,000 for a lightly customized single-entity NAV 2016–2018, €18,000–40,000 for a standard migration, and €45,000–60,000+ for complex multi-entity projects — roughly 50–70% of a new BC implementation of the same scope. Microsoft subscription licences come on top.

Can I upgrade directly from NAV to Business Central online?

No. Microsoft’s route goes through Business Central 14 on-premises, then a current on-premises version (25 or later), then the Cloud Migration tool. NAV 2013 must go through NAV 2018 first, and NAV 2009 through NAV 2013 or 2015. That’s why older installations usually choose a reimplementation instead.

What happens to my ISV solutions — Jet Reports, Continia, task management tools?

Most major NAV ISVs have Business Central versions. Jet Reports is available for BC. Continia has BC modules for document capture, expense management, and payment processing. Some tools become unnecessary because BC’s native features cover the same ground (e.g., BC’s built-in approval workflows may replace a third-party task management add-on). The assessment phase identifies which ones migrate easily and which ones need alternatives.

Can I run NAV and Business Central in parallel during the transition?

Not as two live production systems — and you don’t need to. The approach is to run parallel validation during UAT (testing the same scenarios in both systems without affecting live operations), then cut over cleanly. Running both as production ERPs simultaneously would create data synchronization nightmares. The structured migration — NAV frozen Friday, BC live Monday — is simpler, safer, and standard.

Will my NAV reports work in Business Central?

Classic reports (NAV 2009 and earlier) don’t transfer at all. RDLC reports from later versions don’t transfer directly either, though layouts can sometimes be adapted. Reports are rebuilt using BC’s Word and Excel layouts, Power BI for dashboards, and BC’s financial reporting. The output is usually better — interactive, filterable, and automatically refreshing — rather than the static printouts NAV reports typically produced.

What if I’m on a very old NAV version — 2009 or earlier?

The core data structures (tables, fields, G/L entries) are recognizable even from NAV 2009, but a technical upgrade would take four upgrade hops. In practice, NAV 2009 customers get a better result from a reimplementation with selective data migration. Plan for a Profile 3 effort: 5–9 months, €45,000–60,000+ partner fee for complex setups; less if the company is single-entity and willing to retire most customizations.

Can I migrate from Dynamics AX to Business Central?

Yes, but as a reimplementation, not an upgrade — AX and BC are different codebases, and there’s no Microsoft upgrade path or cloud migration engine for AX. See the AX section above for the short version, or our AX to Business Central migration guide for routes, data, customisations and costs.

Do I lose my NAV history?

No. How much history you bring to BC is a decision, not a limitation. Most companies migrate 2–5 years of posted entries (G/L entries, customer ledger entries, vendor ledger entries, item ledger entries, bank ledger entries) and all open transactions. Older history can be kept in a read-only copy of your NAV database. The recommendation: bring enough history for comparative reporting (3–5 years), archive the rest.

Is the migration disruptive to daily operations?

The project itself runs in parallel — your team keeps working in NAV during the build, configuration, and testing phases. The only disruption is the go-live weekend (typically Friday–Sunday) and the learning curve in the first two weeks. Compared to moving to a completely different ERP platform, a NAV-to-BC migration is one of the least disruptive ERP transitions you can make.

---

Ready to Plan Your NAV-to-BC Migration?

Migrating from Dynamics NAV to Business Central is a significant project — but it’s also the most predictable ERP migration path in the Microsoft ecosystem. The data structures are familiar, the business logic transfers, and the operational disruption is measured in days, not months.

The difference between a smooth migration and a painful one comes down to two things: planning ahead and choosing a partner who’s done it before. From our implementations, from NAV and other systems, across Europe and the Gulf, we’ve seen what works — and what doesn’t.

Whether you’re on NAV 2013, NAV 2016, NAV 2018 — or Dynamics AX — let’s talk about what a migration would look like for your specific setup: timelines, data migration, customization review, and honest pricing with no surprises.

→ Explore our Business Central implementation services

Book a free discovery call — 30 minutes, no obligation, no pitch. Just an honest assessment of where you are and what the path to Business Central looks like.

---

Vanguard 360 Solutions is a Microsoft Dynamics 365 Business Central partner and LS Retail Gold Partner, operating across Europe, the UK, UAE, and Saudi Arabia. Our work includes LS Central across 120+ stores in Romania, Pharmacy for LS Central across 100+ pharmacies in Norway, and the architecture for a 700-store retailer in 13 countries. If you want to learn more about what Business Central actually is, read our complete guide to Business Central.