Dynamics NAV - originally Navision - has been the ERP of choice for small-to-mid-market Australian businesses for over 20 years. It's popular with wholesale distributors, manufacturers, professional services firms, and retail businesses across Perth, Melbourne, Sydney, and Brisbane. You'll find NAV installations running everything from basic GL and AP/AR to complex warehouse management with barcode scanning.
Microsoft rebranded it as Dynamics 365 Business Central in 2018 and has been pushing hard toward the cloud SaaS version. But thousands of Australian businesses still run NAV 2009, NAV 2013, NAV 2015, NAV 2016, NAV 2017, or NAV 2018 on-premise. This guide covers what's involved in upgrading, migrating, or just keeping things running.
Upgrade Paths to Business Central
The upgrade path depends on your current version. Microsoft doesn't support jumping directly from very old versions to the latest.
From NAV 2018
This is the cleanest path. NAV 2018 already has some AL support, and the data structure is close to Business Central. You still need to convert C/AL customisations to AL extensions, but the database upgrade is relatively straightforward.
From NAV 2015-2017
You have two options: a technical upgrade through intermediate versions, or a data-only migration where you set up Business Central fresh and migrate your data across. The best approach depends on how much customisation you have.
From NAV 2013 or Earlier
Direct technical upgrade is usually not practical. A data migration approach is typically more cost-effective - set up Business Central, rebuild essential customisations as AL extensions, and migrate master and transactional data.
Technical Upgrade vs Data Migration
- Technical upgrade - Step through intermediate versions, converting code and data at each step. Preserves everything but is slow and expensive for large version jumps.
- Data migration - Fresh Business Central setup with clean configuration. Data is extracted from NAV, transformed, and loaded. Customisations are rebuilt from scratch in AL. Faster but requires rebuilding custom logic.
- Hybrid approach - Technical upgrade the database to get the data across cleanly, then rebuild customisations as AL extensions. Often the most practical for heavily customised systems.
C/AL to AL: The Language Migration
This is the part that catches most businesses off guard. It's not just a simple conversion - it's a fundamental shift in how customisations work.
What Changed
- Development environment - C/AL used the old C/SIDE development environment built into NAV. AL uses Visual Studio Code with a Microsoft-provided extension.
- Customisation model - C/AL allowed direct modification of base application objects. AL requires extensions - you subscribe to events and add functionality without modifying Microsoft's code.
- Deployment - C/AL changes were applied by importing fob files or modifying objects in the development client. AL extensions are packaged as .app files and deployed through the admin portal or PowerShell.
- Source control - AL code lives in files on disk and works naturally with Git. C/AL code was trapped inside the NAV database (unless you used special export tools).
Conversion Strategy
Microsoft provides a txt2al tool that performs an initial conversion of C/AL code to AL syntax. But this is just the starting point:
- The tool generates AL code, but it won't follow the extension model. Direct modifications need to be refactored into event subscribers and table extensions.
- Custom pages built in C/AL need redesigning for the Business Central web client
- Integration code that used .NET interop or COM objects needs rewriting - Business Central Online doesn't support those
- Reports need attention too - the report rendering engine has changed between versions
Practical tip: Don't convert everything. Some old C/AL customisations were built to work around NAV limitations that Business Central has since fixed natively. Review each customisation and decide: rebuild it in AL, replace it with standard BC functionality, or drop it entirely.
Business Central: Cloud vs On-Premises
When migrating from NAV, you need to decide between Business Central Online (SaaS) and Business Central On-Premises:
Business Central Online (SaaS)
- Hosted and managed by Microsoft on Azure
- Automatic updates (you get the latest version whether you want it or not)
- No infrastructure to manage
- Extensions must pass Microsoft's AppSource validation rules
- No direct database access (no custom SQL queries or stored procedures)
- Some .NET and COM interop functionality isn't available
Business Central On-Premises
- Runs on your own servers (or your cloud IaaS)
- You control when updates are applied
- Full SQL Server access for custom reporting and integrations
- More flexibility for customisations that don't meet AppSource rules
- You're responsible for infrastructure, backups, and security
- Gets less attention from Microsoft - some features are cloud-only
For most Australian businesses, Business Central Online is the better long-term choice unless you have specific requirements that need on-premises capabilities (like direct SQL access for complex BI, or customisations that can't work within the SaaS constraints).
Common Problems with NAV Installations
- Version sprawl - Businesses stuck on NAV 2009 or 2013 because the upgrade always seemed too costly. The longer you wait, the more expensive it becomes.
- Undocumented C/AL mods - Custom code scattered across hundreds of modified objects. Nobody remembers why half of them were changed. Each one needs to be understood before migration.
- ISV add-on dependencies - Jet Reports, Lanham, Insight Works, Continia, or other add-ons that are deeply embedded in your workflows. Some have Business Central versions. Others don't.
- Performance issues - NAV databases that have grown over 10+ years without proper maintenance. Index fragmentation, bloated data, and inefficient code slow everything down.
- User resistance - Staff who've used the same NAV client for a decade don't want a web-based interface. Training and change management are real factors in any migration.
- Integration fragility - ODATA, xmlport-based, or direct SQL integrations with warehousing, e-commerce, or banking systems that need careful handling during migration.
How HELLO PEOPLE Can Help
We're a Perth-based software company with 18+ years of enterprise development experience across Australia - Perth, Melbourne, Sydney, Brisbane, Adelaide, and regional areas.
Our Dynamics NAV Services
- Migration assessment - Detailed audit of your NAV instance: version, customisations, add-ons, data volumes, and a realistic migration plan with effort estimates.
- C/AL to AL conversion - Converting your custom C/AL code to AL extensions for Business Central, with proper testing and documentation.
- Data migration - Extracting data from NAV, transforming it, and loading it into Business Central (or an alternative platform). Including validation and reconciliation.
- Integration development - Rebuilding NAV integrations for Business Central using APIs, web services, Power Automate, or custom middleware.
- Ongoing NAV support - If you're not ready to migrate yet, we provide maintenance, bug fixes, and C/AL development to keep your current system running.
- Training and change management - Helping your team transition from the NAV Windows client to the Business Central web interface.
Free NAV health check. We'll assess your Dynamics NAV environment, catalogue customisations and add-ons, and give you a realistic picture of what migration involves. Get in touch - no pressure, just honest advice.
Frequently Asked Questions
Is NAV the same as Business Central?
Business Central is the successor to NAV. The on-premises version of Business Central is essentially the latest NAV with a new name. Business Central Online (SaaS) is cloud-hosted with a different deployment and update model. The core ERP functionality is familiar, but the technology stack has evolved significantly.
What happened to C/AL?
C/AL has been replaced by AL, which uses Visual Studio Code as the IDE. If you have C/AL customisations, they need to be converted to AL before they can run in Business Central. Microsoft provides conversion tools, but manual rework is always required.
How long does migration take?
From NAV 2018 with light customisations: 3-4 months. From NAV 2013 or older with heavy customisations: 6-12+ months. The C/AL to AL conversion effort is the biggest variable.
Can I stay on NAV forever?
Technically the software doesn't stop working, but you'll lose Microsoft support, security patches, and eventually the ability to find developers who know C/AL. It's a declining platform. Plan your exit - just do it on a timeline that works for your business.
Should I go to Business Central or a different ERP?
If NAV has served you well and your processes fit the product, Business Central is the natural path. If you've outgrown NAV or your industry needs have changed, it's worth evaluating alternatives like NetSuite or Dynamics 365 Finance & Operations. Talk to us and we'll help you assess.
Summary
Dynamics NAV has been a workhorse ERP for Australian businesses, but the technology is moving on. Business Central is the future of this product line, and the C/AL to AL transition is a significant technical hurdle that needs proper planning. Whether you're ready to migrate now or need support to keep NAV running while you plan, having expert guidance makes the difference.
If your NAV system is ageing, your C/AL customisations are undocumented, or you're just not sure where to start - book a free assessment. We'll give you a clear picture of where you stand and what your options are.