Microsoft Dynamics NAV is an ERP system built for small and mid-sized businesses. Many people still know it by its old name, Navision. It handles finance, supply chain, manufacturing, projects, and service in one system, and for a few decades it quietly ran the back office of thousands of companies.
Here’s the part most guides bury: Microsoft no longer sells NAV to new customers. The last release was Dynamics NAV 2018, and Microsoft’s focus moved to Dynamics 365 Business Central. But “discontinued for new sales” doesn’t mean “gone.” Plenty of distributors, manufacturers, and service firms still run NAV every day, and they have real decisions to make about support, security, and what comes next.
This guide covers all of it: what NAV is, what it does, how implementations work, where support stands today, and how to think about migrating. Whether you’re running NAV now, inheriting it after an acquisition, or just trying to understand what you’re looking at, you’ll find a practical answer here.
Microsoft Dynamics NAV is an enterprise resource planning (ERP) system that connects a company’s financials, inventory, sales, purchasing, manufacturing, and project data in a single platform. It was designed for small and mid-sized organizations that needed more than accounting software but didn’t want the weight of a large-enterprise ERP.
In plain terms: NAV is where a business records what it sells, buys, makes, owes, and is owed. One customer record, one item record, one general ledger, shared by every department.
NAV could be installed on-premises, hosted by a partner, or run in a private cloud. Most deployments were tailored by a Microsoft partner, which is one reason no two NAV systems look quite alike today.
NAV’s story starts in Denmark. In 1984, a company called PC&C released an accounting package that later became Navision. By the mid-1990s, Navision Financials for Windows had a loyal following across Europe, and the company, renamed Navision Software, kept expanding.
Microsoft acquired Navision in 2002, following its earlier purchase of Great Plains Software. The product was folded into Microsoft Business Solutions and eventually renamed Microsoft Dynamics NAV, which is why you’ll still hear “Navision” used interchangeably with NAV.
A few milestones are worth knowing:
NAV’s reputation rests on breadth. A single install covers most of what a growing business needs, and a partner can extend the rest. Here are the capabilities that matter most.
The general ledger sits at the core: chart of accounts, dimensions for slicing data by department or project, multi-currency, bank reconciliation, fixed assets, cash management, and consolidation across companies. Finance teams like that every sub ledger posts back to the ledger automatically.
NAV tracks items by location, lot, serial number, and unit of measure, with several costing methods (FIFO, average, standard). Reorder policies, item substitutions, and demand forecasting help planners keep stock lean without running out.
Quotes, orders, blanket orders, returns, and drop shipments all flow through the same document structure. Purchasing mirrors it: purchase orders, receipts, invoices, and vendor payments. Because documents link together, tracing an invoice back to the original order takes a few clicks.
98ulanning Bills of materials, routings, work and machine centers, production orders, capacity planning, and material requirements planning (MRP) are built in. Discrete and light process manufacturers have used these tools for years without needing a separate MES for basic needs.
Warehouse features range from simple bin tracking to directed put-away and pick, wave shipments, and cross-docking. Handheld scanner support through add-ons is common in NAV warehouses.
The Jobs module lets you budget a project, assign resources, record time and expenses, and compare actuals against the plan. Service and construction firms rely on it to see margin before a project closes, not after.
NAV ships with standard reports, account schedules for financial statements, and analysis views. Later versions connect to Power BI and Excel, so finance and operations teams can build dashboards from live ERP data.
NAV’s flexibility comes from its C/AL development language and, in later versions, extensions. Approval workflows, custom fields, and custom objects let partners shape the system to match a company’s processes. That freedom is a strength, and, as we’ll see, also the source of most migration headaches.
People searching for Microsoft Dynamics NAV modules usually want to know how the system is organized. NAV isn’t sold as separate apps the way some newer platforms are. It’s one application with functional areas, and licensing determines which were switched on.
Handles the general ledger, accounts payable and receivable controls, fixed assets, cash management, budgets, and financial reporting. It’s the backbone every other module posts into.
Covers customers, pricing, discounts, quotes, orders, invoices, credit memos, and collections. Credit limits and payment terms are enforced here.
Manages vendors, purchase orders, receipts, invoices, and payment proposals. Three-way matching between order, receipt, and invoice is a common control.
Tracks item cards, stock levels, locations, transfers, and warehouse activities. It feeds both costing in finance and availability in sales.
Adds production BOMs, routings, production orders, and planning worksheets for companies that make what they sell.
Supports job budgets, resource planning, WIP calculation, and invoicing against project milestones or time and materials.
Built for companies that service equipment or deliver ongoing work: service contracts, service orders, item and resource scheduling, and warranty tracking.
Account schedules, analysis views, and query objects, plus connectivity to Excel and Power BI, give users self-service insight without waiting on IT.
NAV earned its place for practical reasons. These are the benefits companies tend to cite when they talk about why they stayed on it so long.
One database replaces the spreadsheet-and-email patchwork many growing companies start with. Sales, purchasing, and finance work from the same customer, vendor, and item data, which cuts reconciliation time.
Because every transaction posts to the ledger in real time, month-end close gets faster and managers can see margin by product, customer, or dimension without a manual rollup.
Accurate on-hand quantities, reorder points, and planning tools help reduce both stockouts and excess stock tied up on shelves.
Approval workflows, posting rules, and document flows push people to follow the same steps every time. That consistency matters for audits as much as for efficiency.
Companies with unusual processes (project billing quirks, special manufacturing steps) could model them directly in NAV instead of bending the business to fit the software.
To be fair, NAV now has real limits. There are no new feature releases. Older versions are out of mainstream support. Heavily customized systems can be fragile and hard to upgrade. Integrations with modern cloud tools often need workarounds, and finding developers fluent in C/AL gets harder each year.
Microsoft no longer sells NAV for new deployments, so most “implementation” work today means one of three things: rolling NAV out to a new subsidiary, rebuilding an existing instance, or inheriting a legacy system. The method below still applies, and it maps almost directly onto a Business Central project too.
Step 1: Assess Business Requirements and ERP Readiness Start with how the business actually runs, not how the org chart says it runs. Interview finance, operations, sales, and warehouse leads. Document pain points, reporting gaps, and the processes that must not break.
Step 2: Define Project Scope, Goals, and KPIs Pick measurable goals: days to close the books, inventory accuracy, order-to-cash cycle time. Fix the scope in writing, because scope creep is the most common reason ERP projects run late.
Step 3: Plan System Configuration and Customization Configure first, customize last. Every custom object adds cost now and during every future upgrade. If a standard feature covers 80 percent of a need, challenge whether the last 20 percent is worth coding.
Step 4: Prepare and Migrate Business Data Clean data before it moves. Merge duplicate customers, retire dead items, and fix inconsistent units. Run at least two trial migrations and reconcile balances against the old system before the final cutover.
Step 5: Integrate NAV With Existing Business Applications List every system that exchanges data with the ERP: CRM, e-commerce, payroll, banks, EDI, scanners. Decide for each whether it needs real-time or scheduled sync, and who owns errors when a sync fails.
Step 6: Test Workflows, Data, and Reports Test end to end, not just screen by screen. Walk a sales order from quote to cash, a purchase from request to payment, a production order from release to finished goods. Have real users run the scripts, not just the consultants.
Step 7: Train Users and Manage Change Train by role, with their own data and their own scenarios. Name internal champions in each department. Most post-go-live complaints trace back to people not understanding the new process, not to software defects.
Step 8: Go Live, Monitor Performance, and Optimize Plan a hypercare window of a few weeks with fast-response support. Watch posting performance, job queue errors, and user feedback, then schedule a first optimization round once the dust settles.
The quality of its Microsoft Dynamics NAV integration with surrounding tools often decides whether users trust it.
NAV lets users export lists to Excel, edit in bulk, and publish changes back. Later versions also connect with Outlook and Office 365 for contacts and documents. It’s one of the simplest wins and one of the most used.
NAV can connect to Dynamics 365 Sales or other CRMs to share accounts, contacts, and order status. The main design question is which system owns the customer record, and settling it early prevents duplicate data later.
Online stores need accurate stock, pricing, and order status. Connectors or API-based integrations can push inventory out and pull orders in. Test volume peaks, since a sync that works at 50 orders a day can choke at 5,000.
Scanner apps, carrier platforms, and third-party warehouse systems commonly connect through web services or middleware. Agree on how shipping confirmations, tracking numbers, and returns will flow back into NAV.
Power BI is the usual choice. Connect through OData or SQL views, but be careful about pointing heavy reports at the live production database during business hours.
Watch for brittle point-to-point connections, API versions that fall out of support, duplicate records, and credentials stored in old scripts. Use a service account with least privilege access, log every sync, and set up alerts for failures so nobody discovers a broken integration from a customer complaint.
This is the section most NAV customers are here for.
It depends on your version. Microsoft sets support dates by version under its Modern Lifecycle and Fixed Lifecycle policies. NAV 2018 is the newest release and remains in extended support, but extended support covers security updates and fixes for critical issues, not new features or general enhancements. Older versions have already aged out. Check your version against the Microsoft Lifecycle site before you plan anything.
Here’s a quick reference. Treat the dates as a starting point and confirm them on Microsoft’s official lifecycle pages, since terms can be updated.
| Version | Mainstream support ended | Extended support ends |
| NAV 2018 | January 2023 | January 2028 |
| NAV 2017 | January 2022 | January 2027 |
| NAV 2016 | April 2021 | April 2026 (already ended) |
| NAV 2015 and earlier | Ended | Ended or ending; verify your exact version |
What Happens When a NAV Version Reaches End of Support?
The software keeps running. What stops is the safety net: no more security patches, no regulatory updates (tax rules, e-invoicing formats, bank file changes), and no Microsoft help if something breaks. Over time that raises security, compliance, and audit risk, and some cyber insurers and auditors ask about unsupported systems directly.
What Does Third-Party Dynamics NAV Support Include?
Partner support usually covers help-desk tickets, bug fixes in custom code, performance tuning, database maintenance, user administration, report changes, and integration monitoring. Some partners also provide compatibility patches for tax and compliance changes. What they cannot do is issue official Microsoft security patches, so ask any provider exactly where its responsibility stops.
Look for proven NAV experience on your version, clear service levels with response times in writing, access to developers who can read C/AL, and a candid view on modernization. A good partner will tell you when it’s time to move, even if that ends the support contract.
Comparing Features, Architecture, Deployment, and Updates
| Area | Dynamics NAV | Dynamics 365 Business Central |
| Status | No new sales, no new releases | Actively developed, regular releases |
| Deployment | On-premises or partner hosted | Cloud (SaaS), plus on-premises options |
| Customization | C/AL code, direct object changes | AL extensions that don’t touch base code |
| Updates | Manual, project-based upgrades | Scheduled automatic updates in the cloud |
| Interface | Windows client, web client | Web-first, browser and mobile |
| Ecosystem | Limited integration with newer tools | Native Power Platform, Copilot capabilities, AppSource apps |
On-premises gives control over infrastructure but also leaves patching, backups, security, and hardware on your plate. Cloud ERP shifts that to Microsoft in exchange for subscription pricing and less direct control over update timing.
Can Dynamics NAV Customers Upgrade to Business Central?
Yes, but “upgrade” is a bit generous. Because Business Central replaces direct code changes with extensions, you’ll need to review, rewrite, or retire customizations built in C/AL. Data migrates through defined upgrade paths, and the exact route depends on your NAV version. Expect a structured project, not a button click.
When Should Business Consider Migrating From NAV?
Start planning when your version is in or near end of support, when customizations make every change expensive, when you can’t find NAV developers, when you want cloud access or better integrations, or when auditors and insurers start asking questions. Planning early costs far less than migrating in a hurry.
Assess Your Current NAV Environment
Document your version and build, number of companies, database size, user count, hosting setup, and add-ons. This baseline drives every cost and timeline estimate that follows.
Audit Customizations, Extensions, Integrations, and Data
Inventory every custom object, third-party add-on, report, and integration. Sort each one into keep, rebuild, replace with standard functionality, or retire. In most audits, a surprising share of customizations land in the last two buckets because nobody uses them anymore.
Choose Between Continued Maintenance and ERP Modernization
Staying put can make sense in the short term if your version is supported, the system is stable, and you have a clear exit date. It becomes risky when you’re treating “stay” as a permanent strategy. Compare the three-to-five-year cost of maintenance, extended support risk, and migration, not just this year’s budget.
Plan a Migration to Dynamics 365 Business Central
Choose cloud or on-premises Business Central, map NAV functionality to standard BC features, plan the rebuild of required customizations as extensions, and decide how much historical data to bring across. Many companies migrate open transactions and balances and archive older history instead of carrying everything forward.
Prepare a Migration Roadmap and Budget
Break the project into phases: discovery, design, build, data migration, testing, training, cutover, and post-go-live support. Budget for licenses, partner services, data cleanup, integrations, training, and a contingency. A roadmap without a contingency is a wish.
