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 50+ times. No vendor gloss, no scare tactics. Just the reality of migrating from Dynamics NAV to Business Central — what changes, what stays, how much it costs, and how to do it without the horror stories.

---

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. And the gap between them gets wider every quarter.

The End of Mainstream Support

If you’re on NAV 2016 or earlier, mainstream support from Microsoft ended years ago. That means no more regulatory updates, no new features, no security patches — nothing beyond the emergency break-fix of extended support, and even that has a clock. By the time you read this:

• NAV 2017: Mainstream support ended January 2023. Extended support runs to January 2028 — but extended support doesn’t mean “updates,” it means “we’ll fix it if it breaks catastrophically.”
• NAV 2018: Mainstream support ended January 2023. Extended support ends January 2028.
• NAV 2013 and earlier: Fully end-of-life. No support of any kind.

The polite way to say it: you’re 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 your competitors — some of them, anyway — have already made the move.

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 hybrid 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 annual enhancement plans or subscription models. Named users only.	Pure subscription: Essentials ($70/user/month), Premium ($100/user/month), Team Member ($8/user/month). Device licenses ($40/device/month) for shared devices.
Updates	Annual or bi-annual upgrades. Planned months in advance. Downtime involved.	Monthly automatic updates. Two major release waves per year (April, October). Zero-downtime for SaaS.
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 from Microsoft and third parties. 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 tabs. More capabilities ship every month.
Integration	Mostly custom — web services, file-based imports, third-party middleware. Each one a project.	Native APIs, Power Automate connectors, Dataverse, Microsoft 365 deep 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, full functionality.
Compliance & audit	Manual configuration. Regulatory updates depended on partner-delivered hotfixes.	Built-in audit trails, segregation of duties, automated GDPR tools. Regulatory updates pushed automatically.

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.

---

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. You can even get more out of them with BC’s improved dimension handling, like global dimensions that are easier to enforce and default dimensions that are more flexible.

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 with a modern workflow engine, AppSource-compatible, and 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 across 50+ implementations, 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 monthly 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. Monthly 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.
• Custom AL extensions go through Microsoft’s validation pipeline (usually a formality, but it adds a step).
• 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.
• Some cloud-only features (certain AI 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 industry has settled this debate. 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.

---

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, 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.
• 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. Reformat currency fields. Map NAV dimension codes to BC dimension values. Convert C/AL custom field data to AL extension tables.
6. Load — Import into the BC sandbox environment using Microsoft’s RapidStart Services or custom migration tooling for complex cases.
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 50+ NAV migrations:

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 with account schedules

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.

---

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.

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, ERP system replacement in phases, 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. A typical mid-size company (20 users) moving from NAV to BC SaaS typically lands at €450–650/month in licensing — often less than their previous NAV enhancement plan, because BC’s role-based licensing model lets you put shop-floor users on Team Member licenses instead of full user licenses.

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

After 50+ implementations — and a solid chunk of those being 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 can take every Microsoft update without regression testing. 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 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 paid licenses.

Here’s why: NAV’s legacy licensing model — especially in older versions — was based on concurrent users or broad named-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 Member at $8/month for read-only and light tasks, Essentials at $70 for full finance/sales users, Premium at $100 for manufacturing) means you license people for what they actually do. Companies routinely go from 30 NAV licenses to 8 Essentials, 2 Premium, and 12 Team Members — and their annual Microsoft spend drops 20–40%.

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.

---

FAQ

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

If you’re on NAV 2017 or 2018, you have until the end of extended support (January 2028), but 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.

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?

No — 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 systems 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?

Standard NAV reports (RDLC layouts) don’t transfer directly, but the same data is available in BC. Reports are rebuilt using BC’s Word and Excel layout capabilities, Power BI for dashboards, and account schedules for 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?

It’s still a migration, not a clean-slate implementation. The core data structures (tables, fields, G/L entries) are recognizable even from NAV 2009. The customization rewrite effort is proportionally larger — 2009-era C/AL code has more technical debt — and some processes may need to be redesigned rather than directly translated. But the fundamentals — data, posting logic, business processes — carry forward. Plan for a profile 3 effort: 6–9 months, €45,000–60,000+ partner fee.

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. With over 50 end-to-end implementations from NAV and other systems, across 13 countries, we’ve seen what works — and what doesn’t.

Whether you’re on NAV 2013, NAV 2016, or NAV 2018, 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. We’ve completed over 50 end-to-end ERP implementations, serve 70+ active customers across 13 countries, and manage 700+ stores on LS Central. If you want to learn more about what Business Central actually is, read our complete guide to Business Central.