Moving From Dynamics NAV to Business Central in 2026

Dynamics NAV Upgrade Paths, AL Conversion, Real Costs, and What to Build Next

If your company has run Dynamics NAV for 10, 15, or 20 years, you already know a NAV to Business Central migration isn't a simple version bump. That database holds years of financial history, custom tables, modified posting routines, C/AL code, reports, workflows, third-party add-ons, and integrations your team uses every day.

So the real question for 2026 is whether you rebuild the NAV system you have inside Business Central, or use the move to set up an ERP, data, and AI foundation that will hold up for the next decade.

You can't answer that until you understand the mechanics. Microsoft supports migration from eligible on-premises NAV versions to Business Central online, but the route depends on your NAV version, how heavily the system was customized, and whether you choose a full migration or a reimplementation. Microsoft's documentation also states that C/AL customizations must be converted to AL extensions on the full migration path.

In practice, every NAV project has four jobs:

1. Pick the correct, supported upgrade path.
2. Decide what happens to your customizations and data.
3. Keep migration risk and downtime under control.
4. Design the destination for the next ten years, not the last ten.

The fourth job matters more than it used to. Business Central now sits inside a much larger Microsoft stack that includes Fabric, Power BI, Copilot Studio, MCP, Azure Logic Apps, and AI agents.

What you're actually moving to

Most people picture the project as NAV in, Business Central out. That's technically accurate, but it leaves out most of what the new platform can do. A more realistic target looks like this:

Each layer does a different job. That's why we treat NAV migration as a modernization program rather than a database conversion.

Step 1: Your NAV version decides the route

A common assumption is that any NAV customer can jump straight to the latest Business Central release. You can't.

Microsoft's current supported paths to Business Central 2026 release wave 1 (version 28) take NAV 2015, 2016, 2017, and 2018 through Business Central 14, then Business Central 25, and then version 28. C/AL customizations have to be converted to AL along the way. Older NAV versions have a longer road.

Microsoft's migration documentation confirms these routes and notes that versions before Business Central 14 can't move directly to the cloud. The matrix also changes over time. Starting with Business Central 2025 release wave 1, Microsoft no longer supports a direct upgrade from BC14 to the latest release; BC25 is now the intermediate step.

This is why "we're on NAV 2018" isn't enough to produce an estimate. A credible plan starts with:

• Exact NAV version and build
• SQL Server version
• Database size and number of companies
• Number of objects, split into modified standard objects and custom objects
• Size of the C/AL code footprint
• ISV solutions
• Integrations
• Reporting dependencies

In our experience, how far your system has drifted from standard NAV tells you more about cost and risk than the version number does.

Step 2: Full migration or reimplementation

Microsoft describes two very different approaches.

Full migration keeps as much of your existing application and data as the supported architecture allows. You upgrade the application and database, convert C/AL to AL, resolve schema and application differences, validate historical data, install compatible extensions, and finish the cloud migration. It fits companies with valuable history and a lot of business-specific functionality they want to keep. One catch: Microsoft notes that data in tables with code customizations can't come forward unless those customizations are rebuilt as extensions.

Reimplementation starts with a clean Business Central setup and brings over only the data you need: customers, vendors, items, chart of accounts, opening balances, selected posted transactions, essential setup, and master data. It makes sense when NAV has built up years of technical debt, or when you'd rather redesign processes than preserve them. Microsoft provides a Business Central 14 reimplementation route for this scenario.

Database size alone shouldn't make the call. Here's the framework we use:

There's no universal answer. It comes down to how much business value is sitting in what you've already built.

Step 3: Converting C/AL to AL (the part most teams underestimate)

Business Central is extension-based. Microsoft describes version 28 as fully AL-based, with the base application itself delivered as an AL extension, and C/SIDE is no longer the development model. A heavily customized NAV system can't be copied into Business Central online. The custom layer has to be rebuilt as extensions.

Microsoft's customization migration playbook covers exporting C/AL objects, converting them to AL, creating an AL project, fixing compilation errors, refactoring, and testing the extensions. In practice the work runs like this:

1. Inventory the customizations. Modified tables, pages, reports, and codeunits; custom tables, reports, XMLports, and queries; option fields; .NET interop; custom integrations.
2. Compare against the standard baseline. Diff your NAV application against the matching Microsoft standard version so you know what Microsoft already provides and what your team built.
3. Export the C/AL application. Microsoft's workflow uses Export-NAVApplicationObject with the -ExportToNewSyntax option before running the Txt2Al conversion tool.
4. Convert the syntax. The tool generates first-pass AL files. Getting them to compile is the easy part.
5. Refactor. This is where experienced NAV developers earn their fee. The goal is to make the business requirement work correctly inside the extension model, which often means redesigning how the logic is attached, not just fixing compile errors.

Different object types need different treatment:

Events replace direct modification

This is the biggest mindset shift for NAV developers. In classic NAV, you opened a standard codeunit, inserted your logic, and compiled the modified application. In Business Central, Microsoft's base application raises events, and your extension subscribes to them to run customer-specific logic.

That keeps your code separate from Microsoft's, which is what makes future upgrades manageable. Microsoft recommends this event-driven approach over carrying forward the old modified-base-application model. A migration is your chance to clear out that modification debt rather than convert it line for line.

Keep a schema change register

Removing fields, renaming fields, changing data types, changing keys, or splitting and merging tables all create data conversion work. Microsoft warns that breaking schema changes like removing or renaming fields can stop extensions from synchronizing. On any heavily customized project, we log every significant change: old and new object, old and new field, transformation rule, validation rule, and rollback considerations.

Step 4: Inventory every integration and ISV

Some NAV systems look simple until someone lists the integrations. A mature environment may connect to CRM, ecommerce, EDI, banks, payment providers, shipping, warehouse management, manufacturing systems, payroll, reporting tools, document management, and tax systems.

Classify each one:

This can swing the budget significantly. A five-company NAV deployment with three integrations can be easier to migrate than a single company with 25 undocumented interfaces.

Step 5: Know where migrations actually go wrong

Data loss gets the attention, but most failures come from somewhere else:

• Undocumented C/AL code that quietly affects posting, pricing, inventory, or financial processes.
• Poor data quality. Duplicate customers, invalid dimensions, and obsolete items all surface during migration.
• Unsupported add-ons. An ISV may have no compatible Business Central or cloud version.
• Integrations that read NAV SQL tables directly instead of using supported APIs.
• Workflows that need to be redesigned, not converted.
• Reports built on NAV SQL structures that no longer exist in the same form.
• Large databases, where historical and log tables stretch migration time.

Step 6: Rehearse in a sandbox, then reconcile

Never validate a migration only in production. Microsoft's cloud migration guidance recommends running dry runs in a sandbox rather than in a production environment the business is already using, and recommends at least two dry runs before cutover. We plan for three rehearsals, each with a different question:

Rehearsal 1: Can we move the environment? Validate database conversion, extensions, data migration, schema, errors, and integration connectivity.

Rehearsal 2: Does the business still work? Test procure-to-pay, order-to-cash, record-to-report, inventory, manufacturing, warehouse, payments, reporting, and approvals.

Rehearsal 3: Can we finish inside the cutover window? Time a production-sized run end to end: backup, data transfer, upgrade, extension installation, validation, integration activation, and user readiness.

A migration isn't done when the database loads. It's done when the new environment produces the business results you expect. Build reconciliation into the test plan from the start, with agreed tolerances and documented sign-off:

• Finance: trial balance, general ledger, AR, AP, bank balances, sales tax balances
• Inventory: item quantities, inventory value, warehouse quantities, lot and serial data where used
• Sales: open orders, posted invoices, customer balances
• Purchasing: open orders, posted invoices, vendor balances

Step 7: Plan the cutover and downtime

Manufacturers and distributors running extended shifts worry most about downtime, and "we'll do it over the weekend" isn't a plan. The team needs measured timings from rehearsal.

Microsoft notes that many cloud migrations can run with minimal user downtime. For large environments, it suggests options such as using an Azure SQL Database copy of the source database to speed up migration, along with a defined change freeze and a rollback plan.

A cutover schedule we'd use:

• T-14 days: Freeze major application changes.
• T-7 days: Complete the final rehearsal.
• T-1 day: Final backup and validation.
• Cutover: Stop NAV users and integrations, capture final data changes, run the final migration, apply final extensions and configuration, validate data, reconcile, reactivate integrations, release to pilot users, get business sign-off, then release to everyone.
• After go-live: Enhanced support and monitoring.

Write the rollback plan before cutover begins.

Step 8: Size the data deliberately

Microsoft's cloud migration guidance recommends keeping individual migration runs under 30 GB where practical, notes that some admin tasks become restricted once Business Central online storage passes 80 GB, and recommends trimming unnecessary history and log data and migrating companies in manageable groups.

You can still keep your history. You just need a plan for where each type of data lives:

This cuts migration volume without losing analytical value.

What does a NAV to Business Central migration cost?

Microsoft doesn't publish a NAV migration price, because the cost depends on your NAV version, customization volume, C/AL complexity, number of companies and integrations, ISV solutions, database size, historical data needs, reporting, manufacturing and WMS requirements, user count, training, and cutover complexity.

It's more useful to build a cost model than to chase a single number. We split the budget into five workstreams:

These are planning categories, not Microsoft benchmarks. A fairly standard NAV environment sits toward the low end. A manufacturer with heavily modified NAV, multiple companies, complex warehouse processes, extensive C/AL, EDI, ecommerce, CRM integration, custom reports, and several ISV products is a much larger project.

User count is rarely the biggest cost driver. Customization and integration complexity usually are. A company with 30 users and 150 custom objects may need more redevelopment than a 100-user company running close to standard NAV.

Keep licensing separate from implementation

Microsoft's current US list pricing, effective November 1, 2025, is $80/user/month for Essentials, $110/user/month for Premium, and $8/user/month for Team Members, all billed annually. 

• 50 Essentials users: 50 × $80 × 12 = $48,000 per year
• 50 Premium users: 50 × $110 × 12 = $66,000 per year
• 100 Essentials users: 100 × $80 × 12 = $96,000 per year

These are license calculations only, not implementation estimates. For a fuller breakdown of license types, see our guide to Business Central pricing and licensing. Manufacturing and service companies should look closely at Business Central Essentials vs Premium, since Premium adds manufacturing and service management capabilities.

Budget separately for ISV apps, Azure, integration services, Copilot and agent usage, Power Platform, Fabric, Power BI, third-party services, and migration tooling. A credible business case shows licensing, implementation, data and integration, and ongoing support as separate lines.

Score your complexity before requesting proposals

Before you ask partners for quotes, rate your environment on each factor:

You'll get far more defensible estimates this way than by asking "how much does a NAV migration cost?" For a rough starting number, try our ERP implementation cost calculator.

After NAV: building the architecture for data and AI

Once the migration mechanics are under control, the bigger opportunity shows up. Business Central becomes the transactional system of record. Fabric provides the enterprise data layer. Power BI delivers governed analytics. Copilot Studio gives users an agent interface. MCP and APIs expose controlled Business Central capabilities. Logic Apps and Power Platform orchestrate processes across systems.

Where Copilot Studio and MCP fit

Microsoft documents connecting Copilot Studio agents to Business Central through the Business Central connector or MCP server. For former NAV customers, that opens up questions a static NAV report never could answer:

• A CFO asks which customers grew revenue but lost gross margin over the last four quarters.
• An operations lead asks which suppliers account for the biggest rise in late deliveries.

Answers like these can combine Business Central data, Fabric analytical data, and AI reasoning. The rule we hold to: AI works on governed data and controlled business capabilities. No agent gets unrestricted access to your ERP database.

Fabric gives you a second chance with your history

Rather than forcing years of NAV history into the operational ERP, you can separate transaction processing from enterprise analytics. Fabric and OneLake let you integrate and analyze data across sources, and Microsoft's BC2Fab work is designed to bring Business Central data into Fabric through Open Mirroring for analytics and AI.

That shifts the conversation from "we need our NAV reports in Business Central" to "what should the business be able to analyze after the migration?" The answer can span finance, sales, inventory, supply chain, CRM, ecommerce, manufacturing, and customer service.

Automate selectively

Not every process should become an agent. If a process is rule-based, like requiring finance approval on purchase orders over $50,000, a workflow is enough. If it needs judgment, like flagging unusual purchase orders and explaining why they look unusual, AI can add real value.

We use a simple division of labor: agents reason, workflows orchestrate, Business Central transacts, Fabric supplies context, and people approve high-risk decisions.

A seven-phase roadmap

1. Discovery. Document NAV version, database, companies, customizations, C/AL, ISVs, integrations, reports, and workflows.
2. Assessment. Choose full migration or reimplementation, and decide what data moves, which customizations survive, which integrations change, and what gets retired.
3. Technical modernization. Convert C/AL to AL and move modifications into extensions and events.
4. Business Central implementation. Configure finance, sales, purchasing, inventory, manufacturing, warehouse, security, and workflows.
5. Data and integration. Set up APIs, integrations, Fabric, Power BI, and external system connections.
6. Testing and rehearsal. Technical, functional, integration, and user acceptance testing, reconciliation, and cutover rehearsal.
7. AI and automation. Once the foundation is stable, add Copilot, Copilot Studio, MCP, agents, Logic Apps, and advanced automation.

Holding AI until phase seven keeps it from distracting the team during the core ERP migration.

Your NAV migration checklist

Version: What exact NAV version and build are you on? Which intermediate upgrades are required? Is your route currently supported by Microsoft?

Customization: How many standard objects are modified? How much C/AL exists? Which customizations are business-critical, which can be replaced by standard Business Central, and which should become extensions?

Data: How large is the database? Which history is needed operationally, which can be archived, and what belongs in Fabric? What reconciliation rules will you use?

Integration: How many interfaces exist? Which depend on NAV SQL? Which can move to APIs, and which need Logic Apps or Power Platform? Which ISVs support the target architecture?

Risk: How many rehearsals will you run? What's the rollback plan and change freeze period? How will you time a production-sized run?

Cost: What are the implementation, licensing, ISV, integration, data and analytics, and ongoing support costs?

Future architecture: Is Business Central just replacing NAV, or is it becoming the foundation for data, AI, and automation?

Frequently asked questions

Can I upgrade directly from NAV to the latest Business Central?
No. NAV 2015 through 2018 move through Business Central 14 and then BC25 before reaching version 28. Older versions need additional intermediate upgrades first.

Do my C/AL customizations carry over?
Not as-is. On the full migration path, C/AL customizations must be converted to AL extensions. Data in tables with code customizations can't come forward until those customizations are handled as extensions.

Should I choose full migration or reimplementation?
Full migration suits companies with valuable history and business-critical customizations. Reimplementation suits companies with heavy technical debt that want to redesign processes. Customization, data value, and technical debt should drive the decision, not database size.

How much does Business Central cost per user in the US?
At current list price, Essentials is $80, Premium is $110, and Team Members is $8 per user per month, billed annually. Implementation, migration, and integration costs are separate.

How do we minimize downtime?
Run at least two sandbox rehearsals, time a production-sized run, set a change freeze, and document a rollback plan before cutover.

Start with an assessment, not a demo

For most NAV customers, the first step toward Business Central should be a detailed look at your current environment, not a generic product demo. A proper assessment maps your NAV version, customizations, C/AL code, ISV dependencies, integrations, data volume, reporting, business processes, and migration route before implementation begins.

What you get back is more useful than an upgrade quote: a NAV to Business Central modernization roadmap built around your system.

Book a NAV Migration Assessment with Dynamics Square