Dynamics NAV to Business Central Migration: Complete Guide [2026]

Why NAV to BC is Different

Dynamics NAV and Business Central are uniquely positioned within the Dynamics portfolio: BC is the direct, cloud-native successor to NAV. This lineage dramatically simplifies migrations compared to other paths (GP→BC, AX→F&O). Microsoft specifically designed BC to make NAV upgrades manageable by providing:

• C/AL to AL code conversion toolkit that automates most translation work
• Database schema compatibility patterns that align NAV data structures with BC
• Assisted setup wizards that configure BC based on NAV configuration data
• Partner ecosystem and documentation specifically focused on NAV upgrades

This guide assumes you're running NAV 2009 through NAV 2018. Earlier versions (NAV 2005 and older) are extremely rare but follow similar principles with additional modernization effort.

Understanding Your NAV Version

NAV version significantly impacts migration effort. The platform evolved substantially across releases:

Version-Specific Migration Complexity

NAV Version	Release Year	Migration Effort	Code Conversion Complexity	Key Challenges
NAV 2009	2009-2015	High	Complex (30-40% manual rework)	Significant C/AL modernization; legacy patterns; limited documentation
NAV 2013	2013-2016	High	Complex (25-35% manual rework)	More modern patterns; still requires substantial code review
NAV 2015	2015-2018	Medium	Moderate (20-25% manual rework)	Windows client still dominant; fewer API-based extensions
NAV 2016	2016-2019	Medium	Moderate (15-20% manual rework)	Web client introduced; extension model beginning to emerge
NAV 2017	2017-2020	Low-Medium	Low-Moderate (15-20% manual rework)	Extension model well-established; closer to BC architecture
NAV 2018	2018-2024	Low	Low (10-15% manual rework)	Closest to BC; Web client mature; AL code already in use; straightforward conversion

Recommendation: If running NAV 2009-2015, budget extra 4-8 weeks for code modernization. NAV 2016+ conversions are straightforward.

C/AL to AL Code Conversion

What Gets Converted Automatically

Microsoft's Conversion Toolkit automatically translates approximately 70-85% of C/AL code to AL. The conversion handles:

• Language syntax: Most C/AL language constructs (variables, functions, loops, conditional logic) convert directly to AL equivalents
• Event handlers: C/AL trigger-based code converts to AL event subscribers
• Table and page definitions: Most schema conversions happen automatically
• Reports: Report definitions and RDLC layout conversions are automatic
• Codeunit and table logic: Core business logic typically converts well

What Requires Manual Review and Rework

The remaining 15-30% of code requires manual attention. Common patterns that need rework:

Code Pattern	Issue	AL Alternative	Effort
Dynamic field references	C/AL FIELD function not supported in AL	Use record variant or redesign with AL types	Medium
Database API calls	Direct SQL Server interactions not allowed in BC cloud	Migrate to BC table APIs and queries	High
COM objects (Word, Excel automation)	COM not supported in cloud AL	Use Power Automate, Excel add-in, or document generation APIs	High
Windows API calls	No direct Windows API access in AL	Use BC HTTP client, REST APIs, or reconsider requirement	High
Registry access	No Windows registry access in cloud	Store configuration in BC extension settings or database	Low-Medium
File system operations	Limited; cloud restrictions on file access	Use Blob storage, Azure File Share, or document management integrations	Medium
Performance-critical loops	AL execution model differs; some patterns are slower	Redesign using batch processing or AL performance best practices	Medium
Custom sorting/filtering logic	Some C/AL patterns don't translate cleanly to AL query logic	Use BC query objects or redesign filter logic	Low
Legacy reports with complex calculations	RDLC layout issues; complex AL-in-report logic	Rebuild as AL-based reports or migrate to Power BI	Medium-High
Form/page customization with VB script	VB customization not supported	Redesign as AL extensions or accept standard BC pages	Medium

Code Conversion Process

Step 1: Pre-conversion assessment (Week 1)

• Analyze NAV codebase size, complexity, and customization count
• Document all third-party extensions and integrations
• Identify high-risk code patterns (COM, file access, dynamic calls)
• Estimate rework effort

Step 2: Automated conversion (Week 2)

• Run Microsoft Conversion Toolkit against NAV codebase
• Generate AL code and conversion report
• Review conversion warnings and flagged sections

Step 3: Code review and rework (Weeks 3-6)

• AL developers review converted code systematically
• Fix compilation errors and warnings
• Redesign problematic patterns (COM, file access, etc.)
• Unit test converted code against test data
• Update integration points for cloud-first patterns

Step 4: Integration testing (Weeks 5-8)

• Test end-to-end business processes with converted code
• Validate third-party integrations work with AL code
• Performance test and optimize slow queries
• User acceptance testing with power users

Data Migration for NAV

NAV Data Compatibility with BC

NAV's database structure aligns reasonably well with BC, simplifying data migration. Core tables (customers, vendors, items, GL accounts, transactions) migrate with minimal transformation.

Data Migration Approach

Phase 1: Data Preparation (Weeks 1-2)

• Export NAV data from production system
• Clean master data (remove duplicates, obsolete records)
• Validate GL balance integrity
• Archive historical transactions older than 5-7 years (optional)

Phase 2: Mapping and Transformation (Weeks 2-4)

• Map NAV GL accounts to BC GL accounts (often 1:1 mapping)
• Define customer/vendor master data translation rules
• Determine item master data migration scope
• Plan data flow for multi-company scenarios

Phase 3: Test Migration (Weeks 4-6)

• Perform full data migration to BC test environment
• Validate customer/vendor/item record counts
• Verify GL balance tie-out (opening balances, revenue, expenses)
• Test transaction history accuracy
• Identify data issues and refine mapping

Phase 4: Production Migration (Cutover Day)

• Final data extract from NAV production
• Load to BC production environment
• Validate critical balances and counts
• Enable users in BC

Historical Data Approach

Most organizations migrate 5-7 years of detailed transaction history and archive older data. This balances:

• Operational need for recent history (tax, audit, customer inquiries)
• Performance impact of large transaction tables
• Storage costs in cloud environment

Archive strategy: Retain NAV in read-only mode for 12-24 months post-go-live for historical reference.

Timeline and Phasing for NAV Migrations

Fast-Track Timeline (3-4 months)

For organizations with NAV 2016+, clean data, and limited customizations:

• Week 1: Assessment, scoping, code analysis
• Weeks 2-4: Code conversion, data mapping, testing
• Weeks 4-5: UAT and user training
• Week 6: Go-live and 2-week parallel run
• Weeks 7-8: Stabilization and support

Standard Timeline (4-6 months)

For most NAV 2013-2018 deployments:

• Week 1: Assessment and planning
• Weeks 2-3: Code conversion toolkit run; pre-conversion fixes
• Weeks 4-7: Manual code rework, integration testing
• Weeks 6-8: Data migration preparation and testing
• Weeks 8-10: Full UAT cycle with user training
• Week 11: Go-live and cutover
• Weeks 11-14: Post-go-live support (4 weeks intensive)

Extended Timeline (6-9 months)

For NAV 2009-2013 with extensive customization:

• Weeks 1-4: Extended assessment; code modernization planning
• Weeks 5-12: Significant manual code rework; architecture modernization
• Weeks 10-16: Integration testing and validation
• Weeks 14-18: UAT and stabilization phase
• Week 19: Go-live
• Weeks 19-26: 8-week support phase (higher risk projects)

Customization Strategy for NAV

Types of NAV Customizations

NAV customizations typically fall into distinct categories:

Category A: Core Business Logic (15-25% of customizations)

• Custom posting routines (GL, AP, AR)
• Workflow automation (approval chains)
• Integration with external systems (ERP, CRM, WMS)
• Specialized costing or valuation logic
• Migration approach: Convert C/AL to AL; requires careful refactoring and testing

Category B: User Interface and Reports (30-40% of customizations)

• Custom forms and pages
• Reports and RDLC layouts
• Menu customizations
• Data entry shortcuts
• Migration approach: Many can be redesigned as BC pages; consider Power BI for reports

Category C: Workflow and Automation (15-20% of customizations)

• Batch jobs and scheduled processes
• Data import/export routines
• Email notifications and alerts
• Migration approach: Convert to Power Automate workflows; simpler and more maintainable than C/AL code

Category D: Legacy or Obsolete Features (20-30% of customizations)

• Customizations for obsolete business processes
• Features that BC handles better out-of-the-box
• Workarounds no longer needed with BC design
• Migration approach: Do not migrate; retire the customization

Customization Migration Decision Matrix

Customization Criterion	Migrate/Convert (Tier 1)	Reimagine (Tier 2)	Retire (Tier 3)
Business Criticality	Core to operations	Nice-to-have; adds efficiency	Legacy; rarely used
Effort to Convert	Low-Medium	Medium	N/A
Ongoing Maintenance	Required; changes often	Moderate; stable logic	N/A
AL Code Complexity	Straightforward patterns	Workarounds or UI logic	N/A
Example	Order validation logic, GL posting routines	Custom reports, approval workflows, data imports	Legacy special pricing, obsolete reporting, old data migration

NAV-Specific Considerations

Multi-Company Scenarios

If running multiple companies in NAV, BC's approach differs slightly:

• NAV: Separate databases per company (common)
• BC: Single tenant; multiple companies as separate entities within same instance
• Migration approach: Migrate each NAV company database into separate BC companies within single BC tenant, or maintain separate BC tenants if preferred

Localization and Regulatory Features

NAV supports many country-specific localizations (UK, US, DE, FR, IT, etc.). Check if your NAV localization is available in BC:

• Most major localizations (US, UK, DE, FR) are supported in BC
• Some niche localizations may not have BC equivalents
• Budget additional effort if localization requires custom reimplementation

Third-Party Add-ons and Extensions

If running third-party NAV add-ons (accounting integrations, industry-specific modules, specialized functionality):

• Check if vendors offer BC equivalents
• Plan for add-on migration or replacement during NAV→BC project
• Integrations may be simpler in BC (REST APIs vs. NAV interop)

Migration Costs and Budget Planning

Cost Component	NAV 2018 (Simple)	NAV 2013-2016 (Standard)	NAV 2009-2012 (Complex)
Consulting & Planning	$5K-$15K	$10K-$25K	$20K-$40K
Code Conversion & Rework	$10K-$30K	$25K-$60K	$60K-$150K
Data Migration Services	$3K-$8K	$5K-$15K	$10K-$25K
Testing & QA	$5K-$15K	$10K-$25K	$20K-$40K
Training	$2K-$8K	$5K-$15K	$10K-$25K
Post-Go-Live Support (3-4 weeks)	$3K-$10K	$8K-$20K	$15K-$35K
Licenses (Year 1)	$3K-$15K	$8K-$30K	$15K-$50K
Total Estimate	$31K-$101K	$71K-$190K	$150K-$365K

Cost savings vs. on-premises NAV: Migrating to BC typically reduces 5-year total cost of ownership by 30-50% due to eliminated infrastructure costs, reduced licensing, and lower ops overhead.

Partner Selection for NAV Migrations

Right-sizing partner expertise to your NAV version and complexity is critical. Evaluate partners on:

• NAV version expertise: Have they migrated your specific NAV version successfully?
• AL development capability: Do they have certified AL developers? Can they handle code conversion?
• Industry vertical experience: Have they migrated similar organizations in your industry?
• Post-go-live support: Can they provide intensive support during stabilization phase (weeks 1-4)?
• Size and scale: Have they managed similar-sized implementations? What's their team structure?
• References: Speak directly with references; ask about actual timelines and support quality

Frequently Asked Questions