Can you move Dynamics NAV customizations to Business Central?

Yes, you can move Dynamics NAV customizations to Business Central, but you cannot lift them across directly. NAV customizations were built in C/AL code, which Business Central no longer supports. Instead, they need to be rebuilt as AL extensions, a modern, cloud-compatible development model. The good news is that most business logic can be recreated, and in many cases the migration is an opportunity to simplify and standardize what was previously over-customized. The sections below walk through what happens during the migration, how to assess what is worth rebuilding, and what to expect in terms of effort.

What happens to NAV customizations during a Business Central migration?

During a NAV to Business Central migration, your existing C/AL customizations do not transfer automatically. Microsoft’s migration tools can move your data and base configuration, but any custom code written directly in the NAV application, modified tables, pages, codeunits, or reports, must be evaluated and rebuilt manually in AL extensions. This is one of the most technically demanding parts of a Business Central upgrade.

The reason is architectural. Dynamics NAV allowed developers to modify the base application code directly. Business Central uses a layered extension model where customizations sit on top of the standard application without touching the core. That shift protects you from breaking changes during future updates, but it means your old customizations cannot simply be imported.

In practice, a migration project typically starts with a full inventory of your NAV customizations, which objects were modified, how extensively, and what business process they support. This is exactly the kind of structured ERP transformation analysis that separates a well-managed migration from a chaotic one. Without this inventory, teams often discover mid-project that they have far more custom code than anticipated.

What’s the difference between C/AL customizations and AL extensions in Business Central?

C/AL (Client/Application Language) is the development language used in Dynamics NAV, where developers modified the base application objects directly. AL extensions are the development approach in Business Central, where customizations are packaged as separate modules that extend, but do not alter, the standard application. The key difference is that C/AL changes are embedded in the core, while AL extensions are layered on top of it.

This distinction has major practical consequences. C/AL customizations break whenever Microsoft updates the base application, because your changes are tangled with Microsoft’s own code. AL extensions are designed to survive updates cleanly, because they interact with the standard application through defined event hooks and interfaces rather than direct modifications.

For organizations moving from NAV to Business Central, this means the migration is not just a technical port, it is a shift in development philosophy. AL extensions require developers to think in terms of events and interfaces rather than direct table or page modifications. The benefit is a much more maintainable and upgrade-safe solution over the long term.

Which NAV customizations can be rebuilt in Business Central?

The vast majority of NAV customizations can be rebuilt in Business Central as AL extensions. This includes custom fields and tables, modified pages and forms, custom reports, integrations with external systems, and business logic encoded in codeunits. However, some approaches that were common in NAV, such as modifying core Microsoft objects directly, require a different implementation strategy in AL.

A few categories deserve specific attention:

Custom fields and tables: These can be recreated using table extensions and field extensions in AL, often with minimal complexity.
Modified pages and forms: Page extensions allow you to add fields, actions, and logic to standard pages without replacing them entirely.
Custom reports: NAV reports built in C/AL can be rebuilt using AL report extensions or new report objects, though complex layouts may require additional effort.
Integrations: Connections to external systems, whether via web services, file imports, or APIs, can typically be rebuilt using AL and Business Central’s native API framework.
Heavily modified core logic: Where NAV code modified Microsoft’s own business logic directly (for example, posting routines), the equivalent in Business Central uses event subscribers. This is achievable but requires careful design.

The one area where rebuilding is genuinely difficult is when customizations relied on undocumented internal NAV behavior or on database-level access patterns that Business Central’s cloud architecture does not support. These cases are rare but worth identifying early.

How do you decide which customizations are worth migrating?

Not every NAV customization deserves to be rebuilt in Business Central. The right approach is to evaluate each customization against three questions: Does it support a genuine business requirement? Is that requirement not already covered by standard Business Central functionality? And does the value it delivers justify the cost of rebuilding it?

Business Central has evolved significantly since the NAV era. Many customizations that were necessary in NAV, because the standard product lacked the functionality, are now available out of the box in Business Central. Before committing to rebuilding a customization, it is worth checking whether the standard application already handles the same need.

A structured assessment typically categorizes customizations into three groups:

Rebuild: The customization supports a business process that is not covered by standard Business Central and the process is important enough to justify the development cost.
Replace with standard: Business Central’s native functionality now covers the same need. The customization can be retired and users can be trained on the standard approach instead.
Retire: The customization was built for a process that no longer exists, or the business case for maintaining it has weakened. It can be dropped entirely.

This evaluation is also a good moment to question whether some historical customizations were ever the right solution. A Business Central migration gives you a clean opportunity to simplify your system and reduce technical debt that has accumulated over years of NAV development.

How long does it take to migrate NAV customizations to Business Central?

The time required to migrate NAV customizations to Business Central depends primarily on the volume and complexity of your custom code. A lightly customized NAV environment might complete the technical migration in a few weeks. A heavily customized system with dozens of modified objects, complex integrations, and custom reports can take several months of development and testing work.

Beyond development, the timeline is also shaped by testing. Every rebuilt extension needs to be validated against your business processes, not just technically, but in terms of whether it behaves the way your users expect. Test management is one of the areas where migration projects most commonly underestimate effort, particularly when regression testing is needed across interconnected processes.

A realistic timeline for a mid-sized NAV migration with moderate customization typically looks like this:

Inventory and assessment: Two to four weeks
Development of AL extensions: Six to sixteen weeks, depending on complexity
Testing and user acceptance: Four to eight weeks
Cutover preparation and go-live: Two to four weeks

These ranges assume a focused team with clear scope. Scope creep, adding new requirements mid-project or discovering undocumented customizations late, is the most common reason migrations take longer than planned. Starting with a thorough inventory and a realistic assessment of what needs to be rebuilt is the most effective way to keep the project on track.

How Optinus helps with NAV to Business Central migrations

We support organizations through every phase of a NAV to Business Central migration, from the initial assessment of your customization landscape through to go-live and post-migration support. Our approach is grounded in hands-on experience with real ERP migrations at multinational organizations, not just methodology frameworks.

Customization inventory and impact analysis: We map your existing NAV customizations, assess their business value, and identify what to rebuild, replace, or retire before development begins.
Extension development and technical migration: Our consultants rebuild your relevant customizations as AL extensions, designed to be upgrade-safe and maintainable over the long term.
Test management: We plan and execute structured testing, including regression testing and user acceptance testing, to validate that rebuilt functionality works correctly across your business processes.
Cutover and go-live support: We manage the transition from your NAV environment to Business Central with meticulous cutover planning, real-time monitoring, and hypercare support after go-live to protect operational continuity.
Change management: We help your users adapt to the new system and standard processes, reducing resistance and driving genuine adoption rather than just delivering training sessions.

We work both on-site and remotely, across the Netherlands, Belgium, and internationally, wherever your team is based. If you want a clear picture of what your migration involves before committing to a roadmap, our ERP migration services include a structured assessment that gives you that baseline. Ready to discuss your NAV to Business Central project? Contact us and we will help you map out the right path forward.

home|

blog|