What the migration actually requires — phase by phase — so your team can plan with realistic expectations and avoid the common pitfalls.
This is an updated and expanded version of our earlier guide, What a NAV to Business Central Migration Really Looks Like. For a quick look at the questions we encounter most often during migrations, take a look at our Top FAQs for Migrating from NAV to Business Central post.
Most Dynamics NAV users know they must consider an ERP migration sooner or later. The support end dates are public, the security patches stopped years ago, and the NAV consultant pool gets a little thinner each year. What keeps organizations on NAV longer than they intend to stay isn't ignorance of the problem; it's the reasonable fear that migration is riskier, more expensive, and more disruptive than staying put.
That calculation has shifted. Microsoft ended mainstream support for all NAV versions, with NAV 2016 passing its final extended support date in April 2026 and NAV 2018 following in January 2028. After those dates, new vulnerabilities go unpatched at the platform level, with no Microsoft safety net regardless of severity. The real cost of waiting on a NAV upgrade isn't just the migration bill that eventually arrives; it's the compounding exposure that accumulates in the meantime. And on the other side, Microsoft commissioned Forrester Consulting to quantify what moving to Business Central delivers: a composite organization in a recent Total Economic Impact study saw an ROI of 265% with payback in under six months.
This guide walks through the major phases of a NAV to Business Central migration so your team can approach the project with realistic expectations about what it requires and how to avoid common pitfalls.
In this guide:
- Assess your NAV environment
- Choose your migration approach
- Clean your data
- Audit your customizations
- Configure the system
- Test thoroughly
- Plan your cutover
- What to expect after migration
Start with an Assessment of Your NAV Environment
Before you start any planning conversations, the project needs a clear picture of the current system. That means documenting the NAV version in use, the degree of customization on top of the base product, the number of active integrations, and the volume and quality of existing data. It is also important to consider your business processes and assess which ones were borne out of NAV's limitations, and whether you should optimize them.
A NAV environment's version matters more than most teams initially expect. If your team is running NAV 2013, 2015, or 2016, it would not be possible to go directly to the latest version of Business Central online, and an intermediary step such as Business Central 14 would be necessary. Each intermediate step requires its own testing cycle, and teams that don't account for this early often find themselves mid-project with a scope and timeline that no longer match the original plan.
Customization depth is another major variable. NAV allows C/AL code modifications that sit in the base layer of your environment, while Business Central was rebuilt with a more scalable extension model. A clear and early inventory of what was customized, by whom, and whether these customizations still reflect current business processes is one of the most valuable things a team can do before engaging a migration partner. In almost all cases, customizations have direct analogues in Business Central that are either a part of the core solution offering or are available as an ISV solution through Microsoft's Marketplace.
Choose Your Migration Approach: Upgrade or Reimplementation
There are two primary paths from NAV to Business Central. An upgrade moves your data and configurations forward from the existing environment. It generally preserves more of what was built and is a reasonable route when the NAV implementation is relatively standard and the primary goal is getting off an unsupported platform without redesigning operational processes.
A reimplementation starts fresh in Business Central and migrates only the data, not the logic or configurations. It takes longer and requires more organizational investment upfront, but it tends to produce a cleaner outcome: a system that reflects how the business operates today rather than how it operated when NAV was first installed. A manufacturer running NAV 2017 with 40 or more customizations, an active EDI integration, and several third-party add-ons is almost always a reimplementation candidate, even if the team's instinct is to preserve what's working. The cost of carrying that complexity forward into an upgrade usually exceeds the cost of starting clean.
Neither path is universally better. The right choice depends on how much technical debt the current environment carries and how closely existing processes align with Business Central's native functionality. Getting an experienced partner to assess this early prevents a costly course-correction mid-project.
Clean Data Makes for a Better Start
Data quality and hygiene is where migrations most reliably run into trouble. The assumption that NAV data is clean, because it has been in active use for years, is one of the more expensive ones a team can carry into a project.
A data audit helps surface duplicate records, outdated customer and vendor master data, closed transactions that were never fully reconciled, and fields populated inconsistently over time. Carrying these errors into Business Central makes them harder to find and fix while your team is learning to use the platform, and it may erode their trust in it.
The right approach is to define upfront which data will migrate, run a structured cleansing pass before any test migration begins, and then validate migrated data against known benchmarks from the source system. This step has a direct effect on your migration's effectiveness and the volume of cleanup teams face six to twelve months post-launch.
Audit Your Customizations
This is a phase most teams underestimate. The technical process of moving C/AL customizations into AL extensions is not a straight translation. It requires understanding what the original customization was doing, whether native Business Central functionality now covers that need without additional code, and where gaps still exist that require new development.
Some customizations that felt essential in NAV turn out to be unnecessary in Business Central. The platform has matured considerably since the NAV era, and functionality that required custom code a decade ago is available natively now. Others will need to be rebuilt, and some will be better addressed through third-party ISV solutions that extend Business Central rather than custom development from scratch. Western Computer's integrations and custom development practice is specifically structured around this work, bridging NAV customizations to Business Central's extension architecture.
The timeline for this phase depends almost entirely on customization volume and complexity. A standard NAV environment with limited modifications might complete this work in a matter of weeks. A heavily customized environment can extend the project by months. The important thing is to sequence this work early, before configuration begins, so that dependencies between custom logic and core setup are visible before they create problems downstream.
Configure the System to Reflect Your Operations
Once the project scope is defined, the implementation team will set up your chart of accounts, dimensions, posting groups, workflows, and approval structures that reflect how the business actually runs.
A common mistake at this stage is treating Business Central as a direct replacement for NAV and configuring it to mirror the old system as closely as possible. The platform's architecture is different enough that a mirror configuration introduces unnecessary complexity. Business Central has stronger native capabilities in areas like financial dimensions, workflow automation, and reporting through Power BI. Teams that invest time understanding how the new system is designed to work, rather than forcing it to behave like the old one, get more from the platform and encounter fewer problems at go-live.
Integration setup also happens in this phase. Business Central connects natively with Microsoft 365, Teams, and the Power Platform, which opens workflow and reporting options that were not available in NAV. Third-party integrations, whether with warehouse management systems, EDI platforms, or CRM tools, need to be rebuilt or reconfigured. They do not carry forward from NAV automatically, and teams that assume otherwise will discover the gap at the worst possible time.
Test Thoroughly and Involve Your Users
User acceptance testing is the step organizations most consistently shortchange when a project timeline comes under pressure. It is also the most predictable source of post-go-live issues.
A complete UAT cycle should involve actual users running actual workflows against representative data, not just technical resources running predefined test scripts. At minimum, every core financial workflow and business-critical integration should have a documented pass result before the cutover date is locked.
It is worth considering operating both systems simultaneously leading up to your cutover date as it can provide additional assurance, but it is not a substitute for thorough planning and testing.
Planning Your Cutover
Cutover requires a detailed sequence of steps, clear ownership for each, and agreed decision points for what happens if something doesn't go as planned. The practical work includes a final data extract and load from NAV, restricting access to the legacy system, validating opening balances and key transaction data in Business Central, and enabling users to begin operating in the new environment.
For most mid-market manufacturing and distribution companies, cutover happens over a weekend or a short planned downtime window. The first two to four weeks after launch will generate a volume of questions and minor issues that the internal team cannot absorb alone. Having dedicated support resources in place for that window, whether internal or from a managed support services partner, is the difference between a launch that stabilizes quickly and one that drags into months of reactive problem-solving.
What to Expect After the Migration
Business Central is a continuously updated platform. Microsoft releases two major updates annually, and the extension-based architecture means those updates apply without overwriting custom logic. That is a tangible operational advantage compared to the maintenance overhead of NAV, where upgrades required substantial partner engagement each time. For organizations wondering what specifically changes after the move, Western Computer's NAV to Business Central service overview outlines what the platform unlocks: automatic updates, built-in Copilot capabilities, native Power BI reporting, and access to the Microsoft AppSource ecosystem.
The productivity gains that motivated the migration, cleaner reporting, faster month-end close, better integration between finance and operations, take time to fully materialize. Teams that invest in training before go-live, not just during onboarding, and set realistic expectations about the ramp-up period reach stable productivity faster than those that treat learning as something users can catch up on after launch.
The most useful first step for any organization still on NAV is a structured assessment of what the migration actually involves for their specific environment: version, customization depth, integration complexity, and data quality. Without that picture, timeline and budget estimates are guesswork. Western Computer offers a no-commitment NAV migration readiness assessment designed to give teams exactly that clarity before any migration work begins.
