Migrating from Dynamics NAV or AX to Dynamics 365 for Manufacturing: What It Takes
If you are running a manufacturing operation on Dynamics NAV or Dynamics AX, you already know the platform has a shelf life. Mainstream support has ended or is ending, customizations are getting harder to maintain, and the gap between what the legacy system does and what the business needs keeps widening. The question is not whether to move. It is what the move actually looks like when the operation runs production orders, manages hundreds of BOMs, tracks lot traceability, and depends on MRP to keep the floor running.
Generic migration guides cover the financial and operational basics well enough. But manufacturing adds layers that those guides do not touch: BOM migration and validation, routing configurations, costing reconciliation, MRP regression testing, shop floor user transition, and the decision about whether to carry forward years of production history or start clean. This article covers all of it, for both NAV and AX, so the migration gets scoped against reality rather than assumptions.
NAV and AX: Two Platforms, Two Target Destinations
The migration path depends on which legacy platform is in place.
Dynamics NAV migrates to Dynamics 365 Business Central. NAV and Business Central share the same product lineage. Business Central is the cloud-native successor, and Microsoft provides a technical upgrade path from NAV 2018 and later. For manufacturers on earlier NAV versions (2016, 2015, or older Navision builds), the path involves intermediate upgrades or a reimplementation.
Dynamics AX migrates to Dynamics 365 Finance and Operations. AX 2012 R3 has a supported upgrade path to Finance and Operations using the data upgrade tooling Microsoft provides. Earlier AX versions (AX 2009 and below) require a reimplementation.
For manufacturers, the target platform also depends on the complexity of the operation. A mid-market discrete manufacturer on NAV will typically move to Business Central. An enterprise manufacturer on AX with multi-site operations, native process manufacturing, or advanced warehouse requirements will move to Finance and Supply Chain Management. The legacy platform determines the starting point. The manufacturing requirements determine the destination.
Upgrade or Reimplementation: The Decision That Shapes Everything
Before any data moves, the first question is whether to upgrade or reimplement. This decision has more weight for manufacturers than for most other industries because of the accumulated complexity in the legacy system.
A technical upgrade carries forward the existing database, configuration, and (where possible) customizations. It preserves historical data and minimizes disruption. It makes sense when the legacy system is relatively clean: standard manufacturing configuration, minimal customizations, and data structures that map well to the target platform.
A reimplementation starts fresh on Dynamics 365 and migrates only the data that needs to come across. It makes sense when the legacy system has accumulated years of BOM debt (inactive BOMs never cleaned up, inconsistent version control, orphaned routing records), heavy customization that no longer reflects how the operation actually runs, or manufacturing workflows that need to be redesigned rather than replicated.
For manufacturers specifically, several factors push toward reimplementation. If the legacy BOM structure has grown organically over a decade with no governance, carrying it forward means migrating a mess into a new system. If production order workflows were heavily customized in NAV or AX to work around platform limitations that Dynamics 365 handles natively, those customizations need to be retired, not migrated. If the operation has changed significantly since the original implementation (new product lines, new facilities, different manufacturing modes), a reimplementation allows the D365 configuration to reflect the current operation rather than the operation as it existed ten years ago.
Neither path is inherently better. The right choice depends on the state of the legacy system and the ambition of the migration. But the decision needs to be made deliberately, with manufacturing data complexity factored in, not defaulted to based on what is easier to sell.
Architecture Changes That Affect Manufacturing
The migration is not just a data move. The underlying platform architecture changes in ways that directly impact manufacturing configurations and customizations.
NAV to Business Central: C/AL to AL
Every C/AL customization in NAV must be rewritten as an AL extension for Business Central. There is no automated conversion. For manufacturers, this means every custom production order workflow, every modified BOM validation, every shop floor integration built in C/AL needs to be evaluated: rebuild in AL, replace with an ISV extension from AppSource, or retire because Business Central handles it natively.
The extension model in Business Central also changes how customizations are deployed and maintained. In NAV, customizations modified the base application directly. In Business Central, extensions sit on top of the base application and cannot modify it. This is architecturally cleaner but means some patterns that worked in NAV (direct table modifications, trigger overrides) need to be rethought in AL using events and subscribers.
For manufacturers with 10 or 15 custom objects touching production, this is manageable. For operations with 50+ custom objects across manufacturing, inventory, and shop floor, the C/AL to AL conversion becomes a significant workstream that needs its own timeline and testing plan. The NAV to Business Central upgrade guide covers the technical upgrade steps in more detail.
AX to Finance and Operations: On-Premises to Cloud
AX 2012 R3 X++ code carries forward to Finance and Operations, but it needs cloud-readiness evaluation. Direct SQL access patterns, which are common in AX manufacturing customizations for reporting and data extraction, break in the cloud architecture. Custom SSRS reports need to be reworked or replaced with Electronic Reporting or Power BI. Batch job patterns may need adjustment for cloud execution.
Manufacturing integrations are the biggest architectural concern. MES connections, SCADA interfaces, shop floor terminal integrations, and barcode scanning systems that connected to AX through direct database access or custom web services need new connectivity patterns. Finance and Operations exposes data through OData endpoints, data entities, and the Data Management Framework. Azure middleware (Logic Apps, Service Bus, or an iPaaS layer) typically replaces the direct integration patterns that worked on-premises.
What Manufacturing Data Needs to Migrate
Manufacturing data migration is significantly more complex than financial data migration. Here is what needs attention and where the risks sit.
BOMs, Routings, and Work Centers
Multi-level BOMs, phantom BOMs, BOM versions with effectivity dates, routing operations with setup and run times, and work center configurations all need to migrate. The structures are conceptually similar between NAV/AX and D365, but field mappings are not always 1:1. BOM version handling, phantom BOM behavior, and routing cost rate structures may differ between the legacy system and the target platform.
The bigger issue is data quality. Legacy BOM tables often contain years of inactive records, superseded versions that were never deactivated, and inconsistencies between what the BOM says and what the floor actually builds. Migrating this data without cleanup means the new system inherits the same problems. A BOM audit and cleanup before migration is not optional for manufacturers. It is what determines whether D365 planning and costing produce reliable output from day one.
Item Masters and Costing Data
Item cards, cost groups, standard costs, and cost rollup structures need to migrate. Legacy costing structures may not map directly to D365. NAV's costing methods and AX's cost group hierarchies have different architectures than their D365 counterparts. Standard costs need to be recalculated and validated in the new system. If the migration changes the costing method (FIFO to standard, for example), the impact on inventory valuation and margin reporting needs to be understood before go-live, not after.
Production Order History and Open Orders
Whether to migrate historical production orders is a judgment call. Most manufacturers need recent history (12 to 24 months) for reference, but migrating the full history of every production order ever created is rarely worth the effort. The more critical question is how to handle open and in-flight production orders during cutover. Orders that are mid-production at the time of migration need a clear plan: complete them in the legacy system before cutover, or migrate them in a defined state and pick them up in D365.
Lot and Serial Traceability
For manufacturers in regulated industries (food, pharmaceutical, medical device, aerospace), traceability data must survive the migration intact. A broken lot traceability chain means the manufacturer cannot trace a finished good back to its raw material lots, which is a compliance failure. The migration must preserve lot and serial number assignments, quality test results linked to lots, and the production order associations that tie everything together. This data needs to be validated post-migration, not just spot-checked.
ISV Add-Ons and Customizations
NAV ISV add-ons built on C/AL will not carry forward to Business Central. The ISV may have a Business Central version available on AppSource, or a different ISV may offer equivalent functionality. If neither exists, the functionality needs to be rebuilt as a custom AL extension or retired. AX ISV solutions have a better chance of carrying forward to Finance and Operations, but they still need compatibility testing against the current F&O version. Building an inventory of every ISV add-on and customization, with a disposition plan for each (migrate, replace, retire), is an early-stage activity that prevents surprises later.
How the Migration Process Works for Manufacturers
The process follows a predictable sequence, but each stage has manufacturing-specific considerations that generic migration guides skip.
Assessment and Scoping
Business process mapping against the target platform identifies gaps between what the legacy system does and what D365 covers natively. A customization inventory catalogs every modification to the legacy system and determines its disposition. An integration inventory documents every system that connects to NAV or AX. A data migration strategy defines what data moves, what gets cleaned, and what gets left behind.
For manufacturers, the assessment also needs to cover BOM and routing complexity, MRP configuration, costing methodology, quality management workflows, and shop floor integration patterns. These are the areas where generic migration scoping misses the most.
Environment Setup and Manufacturing Configuration
Before any data migrates, the D365 manufacturing module needs to be configured: BOMs, routings, work centers, machine centers, planning parameters, costing setup, production order types, flushing methods, and quality management (if applicable). This is not a data migration step. It is a system configuration step that requires manufacturing implementation expertise. Getting this wrong means the migrated data produces incorrect planning output, inaccurate costing, or broken production workflows.
Migration Tooling
For Business Central, RapidStart Services and configuration packages handle master data imports. The cloud migration tool supports database migration from NAV 2018 and later. For earlier NAV versions, data must be extracted, transformed, and loaded through configuration packages or custom migration scripts.
For Finance and Operations, the Data Management Framework and data entities handle structured data imports. Data entities exist for items, BOMs, routes, work centers, and production parameters. The framework supports data validation before import, which is critical for catching mapping errors before they reach the production environment.
Both toolsets have limitations for manufacturing data. Complex BOM structures with deep nesting, version history, and effectivity dates may require custom migration scripts to handle edge cases that the standard tools do not cover cleanly.
Testing, MRP Regression, and Costing Reconciliation
Standard migration testing covers production order creation, consumption posting, output posting, and financial integration. Manufacturing migrations need two additional validation steps that most generic guides overlook.
MRP regression testing compares planning output between the legacy system and D365. Run the planning engine against the same demand set (sales orders, forecasts, safety stock levels) in both systems. Compare the action messages: suggested production orders, purchase orders, quantities, and dates. Investigate every difference. Some differences are expected (D365 planning algorithms may optimize differently than legacy MRP). Others indicate configuration errors in planning parameters, lead times, lot sizing policies, or BOM structures that need correction before go-live.
Costing reconciliation verifies that cost rollups in D365 produce the same standard costs as the legacy system. Run the cost rollup for a representative sample of finished goods. Compare the rolled-up standard cost in D365 against the legacy system. If they differ, trace the variance through the BOM levels to identify where the discrepancy originates: material cost, labor rate, overhead rate, or BOM structure. A costing discrepancy discovered after go-live affects pricing, margin reporting, and inventory valuation. Discovering it during testing is the entire point of this step.
Cutover and Go-Live
Cutover planning for manufacturers involves more moving parts than a finance-only migration. Inventory needs to be frozen and counted. Open purchase orders, sales orders, and production orders need clear disposition. The final data load needs to run within a defined cutover window that is realistic for the volume of data involved. Go/no-go criteria should include BOM validation results, MRP regression results, costing reconciliation sign-off, and confirmation that shop floor users can execute production orders in the new system.
Where Manufacturing Migrations Go Wrong
Manufacturing ERP migrations fail for predictable reasons, and most of them are preventable.
Underestimating BOM cleanup is the most common. Migrating legacy BOMs without auditing them means the new system inherits inactive records, inconsistent version control, and structures that do not reflect current production. The result is unreliable MRP output and costing errors that take months to diagnose.
Assuming legacy costing maps cleanly is the second. Cost group structures, overhead allocation methods, and standard cost calculation logic differ between NAV/AX and D365. Migrating costs without reconciliation leads to margin discrepancies that erode confidence in the new system.
Skipping MRP tuning after migration is the third. Planning parameters (lot sizing, safety stock, lead times, dampeners) need calibration against real demand in D365. Parameters that worked in NAV or AX may produce different results in D365's planning engine. Without tuning, planners lose trust in the system and revert to spreadsheets.
Neglecting shop floor user training is the fourth. The common challenges in NAV to Business Central migration include user adoption, but for manufacturing this is amplified. Shop floor operators transitioning from a terminal interface they have used for years to a new system need hands-on training in a sandbox environment, not a slide deck.
Realistic Timelines for Manufacturing Migration
NAV to Business Central for a mid-market manufacturer typically runs 3 to 6 months, depending on BOM complexity, customization volume, and integration count. Add time for C/AL to AL conversion if there are significant manufacturing customizations.
AX to Finance and Operations for an enterprise manufacturer typically runs 6 to 18 months, depending on the number of legal entities, production sites, integration complexity, and whether the migration involves a reimplementation of manufacturing workflows. Multi-site rollouts with phased go-lives (pilot plant first, then additional sites) extend the timeline but reduce risk.
Both timelines assume 1 to 3 months of post-go-live stabilization where MRP tuning, costing adjustments, and shop floor adoption issues are addressed. Partners who quote timelines without this stabilization period are underestimating what manufacturing migration requires.
Frequently Asked Questions
Does NAV migrate to Business Central or Finance and Operations?
NAV's migration path leads to Business Central. They share the same product lineage, and Microsoft provides a technical upgrade path from NAV 2018 and later. However, if the manufacturing operation has outgrown the mid-market tier (multi-site, native process manufacturing, advanced warehouse), the migration may target Finance and Operations instead, which is effectively a reimplementation rather than an upgrade.
When should a manufacturer choose reimplementation over upgrade?
When the legacy system has accumulated significant BOM debt, heavy customization that no longer reflects current workflows, or manufacturing processes that have changed substantially since the original implementation. A reimplementation allows the D365 configuration to be built around the current operation rather than carrying forward decisions made a decade ago.
Can production order history be migrated from NAV or AX?
Yes, but most manufacturers choose to migrate only recent history (12 to 24 months) for reference. Migrating the full history of every production order is rarely worth the effort. The more critical decision is how to handle open and in-flight production orders at cutover.
How do you validate that MRP produces the same results after migration?
Run the planning engine against the same demand set in both the legacy system and D365. Compare action messages: suggested production orders, purchase orders, quantities, and dates. Investigate every difference. Some are expected (different planning algorithms). Others indicate configuration errors in planning parameters, lead times, or BOM structures that need correction before go-live.
Get Your Migration Scoped
Every manufacturing migration has variables that determine the timeline, risk, and cost: BOM complexity, customization volume, integration count, regulatory requirements, and the state of the legacy data. Folio3 Dynamics brings 200+ certified Microsoft Dynamics professionals, over 20 years of manufacturing implementation and migration experience, and a migration methodology built around production environments where downtime is not an option.