Dynamics NAV remains in production in a large number of French SMEs, and the question of its maintenance is not limited to a technical debate about the end of support. The latest version, NAV 2018, benefits from extended Microsoft support until January 2028.
This timeframe changes the nature of the decision: it is not about fleeing an obsolete product, but about planning a transition to Business Central while preserving business processes, integrations, and regulatory compliance.
You may also like : How to Optimize Your Casden Loan Simulation with Points for Civil Servants
Hidden technical debts in a production NAV instance
Any NAV instance operated for several years accumulates customizations in C/AL, custom RDLC reports, and direct connections to third-party tools (EDI, e-commerce platforms, payroll software). These layers constitute a technical debt that is rarely documented.
The transition to Business Central requires rewriting these customizations in AL (the successor language to C/AL) and migrating reports to compatible extensions. Before any migration decision, we recommend a thorough audit of modified objects: pages, codeunits, tables, XMLports. Without this inventory, the migration budget remains a hollow estimate.
Recommended read : The latest trends and news to boost your online business
A point often overlooked concerns middleware integrations. NAV frequently communicates with external systems via SOAP web services or flat files. Business Central, in a SaaS environment, favors REST APIs and Power Automate connectors. Each active SOAP flow represents a distinct conversion project, with its own testing and business validation constraints. To learn everything about Dynamics NAV with ASCI, the functional documentation of the ERP remains a prerequisite before engaging in this type of audit.
Keeping Dynamics NAV until 2028: a rational calculation for an SME
Migrating to Business Central represents a significant investment in project time, user training, and process adaptation. For an SME whose NAV 2018 instance operates stably, delaying migration is not stagnation; it is a financial decision.
Extended support ensures critical security patches until January 2028. As long as the server infrastructure (Windows Server, SQL Server) remains under Microsoft support, operational risk remains manageable.
This time window allows spreading the cost of the transition over several budget cycles. We observe that SMEs that rush migration consistently underestimate two areas:
- The recovery of historical data, which requires cleaning and validating accounting entries accumulated over several fiscal years
- User training on the new web interfaces of Business Central, which are very different from the Windows client of NAV
- Testing of automated flows (orders, invoices, reminders), which engages business teams for several weeks
Planning the exit from NAV does not mean triggering it immediately. The goal is to define the target functional scope on Business Central, estimate each migration batch, and align the timeline with the actual constraints of the business (accounting closures, seasonal activity peaks).
Business Central and the Microsoft ecosystem: what really changes the game
The added value of Business Central compared to NAV does not lie in the functional modules (financial management, inventory, sales, purchases), which remain largely equivalent. The gain lies in the native integration with the Microsoft 365 ecosystem, Power BI, and Power Automate.
On NAV, obtaining a consolidated dashboard required an ODBC connector or a manually configured SSAS cube. On Business Central, Power BI connects directly to the ERP data via published APIs. Users access indicators from Teams or from the browser, without technical intervention.
Power Automate replaces scheduled batch processes in the NAS (Navision Application Server). A flow triggered by a business event (order validation, stock receipt) executes actions in Business Central, sends a Teams notification, or updates a SharePoint file. This type of automation, which required C/AL development on NAV, becomes configurable without code.
The arrival of Copilot in Dynamics 365 adds a layer of assistance through artificial intelligence: suggestions for bank reconciliation lines, generation of product descriptions, natural language queries on data. These features will never exist on NAV. They constitute a medium-term migration argument, not a reason for haste.
Preparing the NAV migration to Business Central without disrupting processes
The technical migration (data, customizations, reports) represents only part of the project. The main risk is the disruption of business processes validated by users.
Business Central in SaaS mode imposes constraints that NAV on-premise did not have. Direct modifications to the application code are prohibited: any customization must go through extensions published on AppSource or installed as per-tenant extensions. This architecture protects the ability for automatic updates but requires rethinking some historical adaptations.
- Custom reports (delivery notes, invoices with specific layouts) must be recreated in Word Layout or RDLC as part of an extension
- Fields added to standard NAV tables migrate to Table Extension type extensions, with a distinct publication logic
- User access rights, often configured granularly on NAV, must be remapped in the Business Central permissions model
- Regulatory compliance (FEC, audit trail, electronic invoicing) must be verified in the new environment, as the French localizations of Business Central evolve with each update wave
We recommend handling the migration in functional batches (finance first, then sales, then inventory) rather than through a global switch. This approach reduces the risk of regression and allows validating each scope with the relevant teams before moving on to the next.
The question posed by the title of this article calls for a direct answer: choosing NAV today means choosing to stabilize an existing system that works while methodically preparing for its replacement. The migration to Business Central is not optional; it is a matter of timing. January 2028 sets the horizon. What remains to be decided is the pace, sequencing, and budget that the company is willing to mobilize to achieve this without operational disruption.