Microsoft Dynamics NAV Upgrade & Support Guide

Practical guide to upgrading from Dynamics NAV to Business Central, covering C/AL to AL migration, customisation challenges, and support planning.

Best for: IT managers, business owners Practical guide for business decision-makers

Who this is for

IT managers, business owners, and finance managers running Dynamics NAV who need to plan their migration to Business Central or handle ongoing NAV support.

Question this answers

What does it take to migrate from Dynamics NAV to Business Central, and what should we plan for?

What you'll leave with

  • NAV support timelines and what they mean for your business
  • Migration paths from NAV to Business Central
  • How to handle C/AL to AL code migration
  • Key risks and practical planning considerations

Platform overview

Microsoft Dynamics NAV (originally Navision) is one of the most widely deployed ERPs for small-to-mid-market businesses globally. In Australia, it's common across distribution, professional services, and light manufacturing.

Microsoft stopped developing NAV in 2018, replacing it with Dynamics 365 Business Central, a cloud-native platform built on the same foundations but with a fundamentally different architecture. NAV ran on-premises with C/AL code. Business Central runs in Azure with AL extensions.

If you're running NAV, the question isn't whether to move. It's when and how.

Common version & support issues

Support timeline. NAV 2018 extended support runs until January 2028. Earlier versions (2017, 2016, 2015, 2013) have already exited support. If you're on anything older than NAV 2018, you're running completely unsupported.

Skills availability. NAV developers are migrating their skills to Business Central. The C/AL developer pool is shrinking, which means higher rates and longer timelines for any NAV-specific work.

Security and compliance. Unsupported versions don't receive security patches. Australian tax and reporting requirements keep changing (STP Phase 2, updated BAS), and NAV can't keep up without manual intervention.

Integration limitations. NAV's integration capabilities are dated compared to modern platforms. Web services exist but are limited. Many NAV integrations use direct SQL or ODBC, which are fragile and hard to maintain.

Upgrade and migration paths

Migration to Business Central (cloud). The standard path. Move to Microsoft's cloud-hosted Business Central. Automatic updates, no infrastructure to manage, strong Microsoft 365 integration. Most NAV users end up here.

Migration to Business Central (on-premises). If you need on-premises for data sovereignty, compliance, or connectivity reasons, Business Central still has an on-premises option. Less common but available.

Alternative ERP migration. If your NAV environment has outgrown what Business Central offers (complex manufacturing, multi-entity, advanced warehousing), consider NetSuite, Dynamics 365 F&O, or industry-specific alternatives.

Staged migration. Migrate core modules first (financials, purchasing), then secondary modules (warehousing, manufacturing) in later phases. Reduces risk per phase but extends the overall timeline.

Customisation & integration challenges

C/AL to AL conversion. This is the biggest technical task. All C/AL code needs converting to AL extensions. Microsoft provides some conversion tools, but complex customisations with deep table modifications or heavily modified base pages need manual rewriting.

Page and report changes. NAV used classic client pages and RDLC reports. Business Central uses a web-based interface and different report rendering. Custom pages and reports need redesigning.

Integration modernisation. NAV integrations often use:

  • Direct SQL queries: Must be replaced with API calls in Business Central
  • NAV web services (SOAP): Still supported in BC but being superseded by OData and REST APIs
  • File-based integrations: CSV/XML imports should be modernised to API-based flows
  • Custom OCX/DLL add-ins: Must be replaced with BC-compatible extensions or external services

Data migration. NAV data structure is similar to Business Central, but not identical. Master data, open transactions, and historical data all need mapping and validation.

Risks and decision points

What makes a move to Business Central harder

  • C/AL code volume

    Large volumes of custom C/AL code mean longer, more expensive migration.

  • NAV version age

    Older versions require more work. NAV 2009 is a significantly bigger project than NAV 2018.

  • Direct SQL integrations

    These all need replacing. Often the largest hidden cost in NAV migrations.

  • User adoption

    Business Central's web interface is different from NAV's Windows client. Plan for retraining.

  • Third-party add-ons

    NAV add-ons may not have BC equivalents. Check availability early.

How HELLO PEOPLE can help

  • Customisation audit: Map all C/AL customisations with conversion complexity ratings
  • Integration mapping and modernisation: Document all integration points and replace direct SQL/file-based methods with APIs
  • Custom application development: Build web portals, customer-facing apps, and specialised tools that connect to Business Central
  • Data migration: Extract, clean, and transform NAV data for loading into Business Central
  • Reporting modernisation: Rebuild custom RDLC reports as Power BI dashboards or AL-based reports

Frequently asked questions

What's the difference between Dynamics NAV and Business Central?

Business Central is the cloud-native successor to NAV. It runs on the same core code base but uses AL instead of C/AL, runs in Azure, and receives continuous updates. Think of it as NAV rebuilt for the cloud.

Can we keep running NAV instead of migrating?

Technically yes, for now. But mainstream support has ended for NAV 2018 and earlier. Extended support for NAV 2018 runs until 2028. After that, you're on your own. The skills pool is shrinking, so the longer you wait, the harder the migration becomes.

How long does a NAV to Business Central migration take?

Typically 3-9 months depending on your NAV version, customisation volume, and data complexity. NAV 2018 migrations are simpler (closer architecture). NAV 2009 or earlier migrations are more complex and may take 6-12 months.

What happens to our C/AL customisations?

C/AL code doesn't run in Business Central. All customisations need converting to AL extensions. Some can be automated with conversion tools, but complex customisations need manual rewriting and testing.

Is Business Central really better than NAV?

For most use cases, yes. Automatic updates, cloud hosting, better integration with Microsoft 365, modern UI, and a growing extension marketplace. The trade-off is less control over upgrades and a different customisation model.

Key takeaways

  • Dynamics NAV to Business Central is a migration project, not a simple upgrade
  • All C/AL code must be converted to AL. No exceptions. Plan for development effort.
  • The closer your NAV version is to 2018, the simpler the migration. Older versions are more work.
  • This is also an opportunity to retire customisations you no longer need
  • Plan for user retraining. Business Central looks and behaves differently from NAV.
ERPUpgrade SupportDynamics NAVBusiness CentralMigrationLegacy Systems

Meet the person

Written by the person who does the work

This guide comes from real projects. If it raises a question about your own system, you can ask the founder directly.

HELLO PEOPLE designs, builds and looks after AI, software, app and data solutions for Australian businesses, with senior expertise on every project and a scope agreed before work starts. For an older system, that means learning what it really does first, so nothing your business relies on is lost.

Since 2007, HELLO PEOPLE has delivered more than 100 projects from Perth for small and medium businesses across Australia: custom software and apps, system integrations, data migrations, reporting and dashboards, and AI that works inside the systems a business already runs.

I lead every engagement myself. I trained in accounting before moving into IT, hold accounting and IT professional qualifications and an MBA, and bring more than 20 years of experience across sales, service delivery, inventory and compliance. I am also a PhD candidate in AI at Curtin University, researching retrieval-augmented generation (RAG), so the technology is always judged by what it does for the business.

  • An old-fashioned service

    Small and boutique. The person who scopes the work is the person who does it, and the same person is there when the old system is switched off.

  • Quick responses

    No ticket queue and no account manager in between. You hear back within one business day, usually sooner.

  • A long-term partner

    The upgrade is the start, not the end. When you need the next system, integration or report, you call the same person, who already knows your business.

Ask the author

Still have a question?

Ask it here and it comes straight to the founder. No sales call, no obligation, and a real answer even if the answer is that you do not need us.

Kasun Wijayamanna, Founder Kasun Wijayamanna
Founder, replies within one business day

Get Started

Want help choosing the right next step?

Tell us what you are comparing, replacing, or trying to improve. We will come back with a practical recommendation and realistic scope.

Australian owned and operated

Built here. Your data stays here.

  • No offshore development. Everything is written by our own team in Australia. Nothing is subcontracted overseas.
  • Your data stays onshore. Hosted in Australia, on infrastructure you own, under Australian law.
  • Every state, not just ours. Perth, Melbourne, Sydney, Brisbane, Adelaide and everywhere between.