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.

Also consider:Microsoft Dynamics 365 F&O · SAP Business ByDesign

Häufig gestellte Fragen

When does support for Dynamics NAV expire?

For NAV 2018, the last major version before Business Central, mainstream support ended on 10 January 2023; extended support with security and critical fixes only runs until 11 January 2028. The immediately preceding versions have expired in stages: NAV 2013 (January 2023) and NAV 2015 (January 2025) no longer receive updates, NAV 2016 has been out of extended support since April 2026, while NAV 2017 still receives security updates until 11 January 2027. After the respective extended support ends, there are neither patches nor Microsoft assistance, so the urgency of the migration to Business Central depends heavily on your specific NAV version, compliance requirements and your own IT roadmap.

How long does a NAV-to-Business Central migration take on average?

For mid-market setups with moderate customisation depth, the typical project timeframe is 6 to 12 months from initial assessment to stabilised production. With extensive custom code, many industry add-ons or multi-country structures, 12 to 24 months is realistic, as code conversion and testing then account for the largest share. A pure technical upgrade along the version chain is usually faster than a greenfield re-implementation, but drags technical debt along with it. The duration is determined above all by the depth of the C/AL customisations, data quality and the number of third-party system interfaces.

Which NAV versions does Microsoft's Cloud Migration Tool support?

There is no direct cloud migration from NAV: Microsoft's approach is to first lift the on-premise solution to Business Central on-premises (version 14) and then to at least version 25, before the Cloud Migration Tool replicates the data to the online environment via Azure Data Factory. NAV 2015 to 2018 follow this standard path directly via version 14, while older versions such as NAV 2013 or 2009 need additional intermediate upgrades (for example via NAV 2018). The technical prerequisite is at least SQL Server 2016 and a database compatibility level of 130 or higher. On the code side, the txt2al converter (tied to the version 14 platform) is used to transform C/AL objects into AL extensions.

What does a Business Central licence cost per user?

In the cloud subscription, Business Central is billed per named user, and Microsoft raised list prices as of 1 November 2025: Essentials has since been around 80 USD per user per month, Premium around 110 USD. The Team Member licence for read-only and light users remained unchanged at around 8 USD per user per month. Premium adds mainly manufacturing and service management over Essentials, which is why manufacturing companies generally need Premium. Euro-billed list prices deviate depending on exchange rates and regional price lists, and implementation and add-on costs come on top.

What happens to our C/AL custom code during the migration?

C/AL code is converted largely automatically into modern AL extensions using the txt2al tool; in practice, experience shows a substantial share converts automatically while the rest requires manual rework. Old patterns such as form-based logic cannot be transferred one-to-one and must be rebuilt in Business Central standard patterns or page extensions. For very heavily customised setups with several hundred custom objects, a greenfield re-implementation is often more economical than attempting to rescue all the legacy code. A code analysis before the project starts uncovers unexpected complexity and should therefore be planned as a mandatory step.

Can we keep working productively in NAV during the migration project?

Yes — the migration project runs in parallel with ongoing NAV operations, so day-to-day business continues unchanged until the final cutover. However, changes to NAV custom code during the migration phase must be synchronised with the emerging AL codebase, which is why a code freeze is usually recommended for the final phases. The actual switch typically takes place over a weekend; after that, the NAV database is generally set to read-only and Business Central goes live. Go-live is followed by a hypercare phase of about four to eight weeks with increased consulting availability, as the Business Central interface differs noticeably from the familiar NAV UI.

Can we migrate to Business Central on-premises instead of the cloud?

Yes — Business Central continues to be available as an on-premises variant as well, so staying in your own data centre remains technically possible. However, Microsoft invests its further development primarily in the cloud version, and new features often appear first or exclusively in the SaaS variant. On-premises offers more room for deep customisation and direct database access, but in return requires your own infrastructure, updates and operations. For most mid-sized companies, the cloud variant is the strategically recommended choice, unless a specific compliance or data residency requirement speaks against it.