Switching from Microsoft Dynamics NAV to Dynamics 365 Business Central
Microsoft Dynamics NAV (formerly Navision, originating in Denmark in the 1980s) has been one of the most-deployed mid-market ERPs globally with strong DACH adoption. Microsoft has consolidated NAV into Dynamics 365 Business Central — the cloud-native successor product that retains conceptual familiarity with NAV while transforming the deployment model. For DACH NAV customers, migration to Business Central is increasingly the default path as Microsoft's investment focuses on Business Central and NAV approaches end-of-life.
NAV lifecycle status
NAV mainstream support ended for various versions on a rolling schedule. NAV 2018: mainstream support ended January 2023; extended support ends January 2028. NAV 2017: mainstream ended January 2022; extended ends January 2027. NAV 2016 and older: extended support ended. Beyond mainstream support, customers face no new features, increasingly limited security updates, and growing partner-and-ISV support gaps. Most DACH NAV operations have migrated to Business Central or are actively planning the migration for 2025-2027 windows. Custom-support extensions are expensive and time-limited. The strategic answer is migration rather than deferred operation.
Conceptual similarity to NAV
Business Central retains substantial conceptual familiarity with NAV. Same code lineage: Business Central derives directly from NAV; many conceptual structures, terminologies and patterns are preserved. Familiar data model: tables, fields, relationships largely preserved with modernisation. Familiar workflows: posting routines, approval flows, period-end processes operate similarly. Same partner-extension model: AL extensions replace C/AL but the conceptual approach is similar. What differs: deployment model (cloud SaaS versus on-premises), UX (web-based versus rich client), customisation approach (AL extensions only, no direct table modifications). The migration is the closest of any major ERP migration: same product family, modernised. Functional change is moderate; deployment-and-architecture change is substantial.
Custom-code re-platforming
The largest single migration workstream is custom-code re-platforming. NAV customers accumulated extensive C/AL customisations over years or decades. Business Central requires AL extensions as the only customisation mechanism — no direct object modifications, no in-place customisation. Microsoft provides conversion tools: C/AL to AL converter automates most of the transformation. Manual review and adjustment is still required for: behavioural-modification customisations that don't fit the extension pattern, complex multi-object modifications, performance-sensitive logic. Code-cleanup opportunity: the migration is a good time to retire unused customisations. NAV customers typically accumulate 30-50% of customisations that are no longer needed; eliminating them reduces migration scope and ongoing maintenance burden.
Cloud SaaS versus on-premises options
Business Central is available in three deployment options. Business Central Online (SaaS): fully cloud-native, Microsoft-managed, automatic updates twice per year. The default modern choice. Business Central on-premises: customer-managed deployment for organisations requiring full control. Limited investment continues; cloud-online receives the priority development. Business Central Embed (partner-hosted): niche option for partner-led vertical solutions. Most NAV-to-BC migrations target Business Central Online. The cloud transition is fundamental: subscription pricing replaces perpetual licences; vendor-managed updates replace customer-controlled upgrade cycles; Microsoft Power Platform integration becomes accessible. For organisations not ready for cloud, Business Central on-premises provides a bridge but with declining long-term roadmap relevance.
Migration methodology
Standard approach. (1) Discovery: inventory of NAV customisations, integrations, modules, version history. (2) Customisation cleanup: retire unused customisations before migration to reduce scope. (3) AL extension development: re-platform critical customisations as AL extensions. (4) Data migration: NAV-to-BC migration tools handle master data and open transactions; historical data typically remains in NAV for audit access. (5) Integration redesign: NAV integrations (often via SOAP services or direct database access) re-platformed using BC REST APIs or Power Automate. (6) Testing and cutover: comprehensive regression testing followed by cutover weekend. Implementation duration: 6-18 months typical depending on customisation volume. Cost: 250,000-1,500,000 EUR for mid-market deployments.
Detailed NAV-to-BC technical changes
Beyond high-level concepts, several specific technical changes matter for migration planning. (1) C/AL to AL conversion: NAV's C/AL development language is converted to AL using Microsoft's C/AL to AL converter tool. Most code converts automatically; specific patterns require manual adjustment (table modifications, codeunit extensions, complex queries). (2) Table-extension model: AL does not allow direct modifications to standard tables; new fields go in table extensions. Refactoring of NAV customisations that modified standard tables is required. (3) Event-based programming: AL uses event publishers and subscribers rather than C/AL object overrides. Event-driven patterns enable cleaner upgrade paths but require code refactoring during conversion. (4) Browser-based UX: the rich Windows client of NAV gives way to web-based Business Central. Users face material UX change. (5) AppSource publication model: Business Central extensions can be published to AppSource for marketplace distribution. This shifts the ISV economy.
Common NAV-to-BC pitfalls
Several patterns produce difficulty in NAV-to-BC migrations. (1) Underestimating custom-code volume: NAV customers typically discover more custom-code than they expected. The conversion effort scales with code volume and complexity. (2) Skipping the cleanup opportunity: the migration is the right time to retire unused customisations. Organisations that carry forward everything compound their ongoing maintenance burden. (3) Insufficient partner-team capacity: many NAV partners struggled with the Business Central technology transition. Some teams remained NAV-competent without acquiring deep Business Central expertise. Validate the proposed delivery team's actual Business Central project history. (4) Cloud-versus-on-premises confusion: organisations must consciously choose cloud-SaaS versus on-premises Business Central. Default-to-on-premises continues existing patterns but misses cloud benefits; cloud transition adds substantial change to the migration. Decide explicitly and align organisationally before the project starts.
Cost and timeline considerations
Realistic cost and timeline guidance for NAV-to-Business Central migrations. SMB (under 30 users): 150,000-400,000 EUR total project cost; 4-8 month duration. Lower mid-market (30-100 users): 250,000-800,000 EUR; 6-12 month duration. Mid-market (100-300 users): 600,000-1,800,000 EUR; 10-18 month duration. Upper mid-market (300+ users): 1,500,000-4,000,000+ EUR; 12-24 month duration. Cost drivers: custom-code volume (high impact), integration scope (medium impact), data history scope (medium impact), user-training scope (medium impact), infrastructure transition (low impact for cloud-target). Saving opportunities: customisation cleanup before migration (retire 30-50% of unused customisations), fit-to-standard process adoption (reduce custom-development scope), competitive partner-bidding (15-25% cost difference across qualified partners).
Strategic positioning post-migration
Business Central positions the organisation strategically in three ways. (1) Microsoft ecosystem alignment: tight integration with Microsoft 365 (Outlook, Teams, SharePoint, Power Platform) plus Azure cloud services. Organisations standardised on Microsoft benefit from compounding ecosystem advantages. (2) AI-and-automation roadmap: Microsoft Copilot for Dynamics 365, intelligent document processing, and embedded analytics all evolve continuously. Cloud deployment receives new capabilities first. (3) Lower upgrade burden: cloud Business Central receives automatic updates twice yearly; on-premises NAV required customer-managed multi-year upgrade projects. The ongoing-operations cost differential compounds over system lifecycle. These positioning benefits justify the migration investment beyond the immediate functional comparison.
Related Topics
Frequently Asked Questions
Can NAV customers run Business Central without changing partners?
Sometimes. Many NAV partners have transitioned their consulting capability to Business Central. Verify the partner's Business Central certification status and references. Some partners struggled with the technology transition; the right partner has substantial Business Central project history, not just historical NAV expertise.
Will Microsoft eventually end NAV mainstream support entirely?
Already in process. Each NAV version has its mainstream-and-extended-support timeline; the latest extended-support window ends in 2028. Beyond that, custom-support is expensive and time-limited. Most DACH NAV customers should plan migration by 2026-2027.
What is the typical cost premium for cloud over on-premises Business Central?
Subscription versus perpetual-licence cost comparison: over 5-7 years, cloud typically costs 10-30% more in total than on-premises with maintenance. The cloud premium pays for: vendor-managed infrastructure, automatic upgrades, faster feature access, reduced internal IT burden. For most mid-market, the operational benefits justify the cost premium.