How do you keep customizations when migrating from Dynamics NAV?

When you migrate from Dynamics NAV to a modern platform like Microsoft Dynamics 365 Business Central, you cannot simply carry your customizations across as they are. NAV customizations were built using C/AL code and the classic development environment, neither of which exists in Business Central. This means every customization needs to be evaluated, rewritten in AL code, replaced by standard functionality, or retired. The sections below walk through exactly how to approach each of those decisions.

What happens to customizations when you migrate from Dynamics NAV?

When you migrate from Dynamics NAV, your existing customizations do not transfer automatically. NAV was built on C/AL code and a monolithic architecture, while Business Central runs on AL code and an extension-based model. Every customization must be individually assessed and then either rewritten as an AL extension, replaced by native Business Central functionality, or removed entirely.

This is one of the most time-consuming parts of a NAV migration, and it is often underestimated in the planning phase. The older your NAV version, the more likely it is that a significant portion of your customizations overlap with features that Business Central now handles out of the box. That overlap can actually reduce the total migration workload, but only if you identify it early.

The architecture shift also matters for ongoing maintenance. In NAV, customizations were often baked directly into the base application, making upgrades difficult. Business Central’s extension model keeps customizations separate from the core, which makes future updates far less disruptive. That is one of the real long-term gains of making the move properly.

Which types of NAV customizations can be carried over?

Not all NAV customizations are equally complex to migrate. The types that can be carried over most reliably are those that address genuine business logic gaps, are well-documented, and have a clear functional owner who can validate them during testing. Purely cosmetic or workaround customizations are usually poor candidates for migration.

Here is a practical breakdown of common customization types and their typical migration path:

Custom reports and document layouts: These can often be recreated in Business Central using RDLC or Word layouts, though the underlying data model may have changed.
Custom fields and tables: These can be rebuilt as AL extensions, but each one needs to be validated against the Business Central data model to avoid duplication.
Workflow automations: Many NAV workflows can be replaced by Business Central’s native workflow engine or Power Automate, reducing the need for custom code.
Integration connectors: Custom integrations with third-party systems almost always need to be rewritten, as the API architecture in Business Central is fundamentally different.
Role-tailored pages and UI modifications: These can be rebuilt using AL page extensions, often with less effort than the original NAV development required.

The key question for each item is not whether it can be carried over, but whether it should be. That requires a structured assessment before any development work begins.

What’s the difference between rewriting and replacing a NAV customization?

Rewriting means taking the existing NAV customization and rebuilding it in AL code as a Business Central extension, preserving the same business logic. Replacing means retiring the customization entirely and using standard Business Central functionality instead. The distinction matters because rewriting carries development cost and ongoing maintenance, while replacing reduces technical debt.

Rewriting makes sense when the customization addresses a process that is genuinely unique to your business and not covered by any standard feature or available AppSource extension. Examples include highly specific calculation logic, industry-specific compliance requirements, or deeply embedded operational workflows that your teams depend on daily.

Replacing makes sense when Business Central has evolved to cover what was once a gap in NAV. Microsoft has added a significant amount of functionality to Business Central in recent years, and many customizations that were necessary in NAV 2013 or 2016 are now redundant. Replacing rather than rewriting reduces your total cost of ownership and makes future upgrades simpler.

A third option worth considering is substituting a customization with a certified AppSource extension. This gives you maintained, supported functionality without the cost of custom development, and it is often the most practical route for common business requirements.

How do you assess which customizations are still worth keeping?

Assessing which NAV customizations are worth keeping starts with a full inventory of everything that has been modified in your current system. For each item, you evaluate three things: whether it is still actively used, whether Business Central covers the same need natively, and what the cost of rebuilding it would be relative to the business value it delivers.

A structured approach to this assessment typically follows these steps:

Inventory all customizations: Document every modified object, custom table, report, and integration in your NAV environment. Many organisations discover customizations at this stage that nobody actively uses.
Map to Business Central standard functionality: For each customization, check whether Business Central already handles the requirement. This step alone often eliminates a large portion of the list.
Validate with business owners: Present the inventory to the relevant process owners and ask them to confirm whether each customization is still needed. Avoid making these decisions in IT without business input.
Estimate rebuild effort: For anything that survives the first three steps, get a realistic effort estimate for rewriting it in AL. This feeds directly into your project budget and timeline.
Prioritise by business impact: Rank the remaining customizations by how much disruption their absence would cause, and use that to guide sequencing decisions.

This kind of structured As-Is analysis is something Optinus applies as part of data migration management and broader transformation planning. Starting with a clear picture of what you have prevents costly surprises later in the project.

What causes customization migration projects to go over budget?

Customization migration projects most often go over budget because the full scope of customizations was not properly inventoried at the start, because hidden dependencies between custom objects were discovered late, or because business owners changed requirements during development. Each of these problems is avoidable with the right preparation.

Undocumented customizations are a recurring issue in older NAV environments. When a system has been in use for ten or fifteen years, it is common to find modifications that were made by consultants who are no longer involved, with no documentation and no clear business owner. Discovering these during development rather than during assessment adds unplanned work directly to the project.

Dependency chains are another frequent source of overruns. A customization that looks straightforward in isolation may rely on a modified base table that also underpins several other objects. Changing one triggers a cascade of rework that was not visible in the initial estimate.

Scope creep during the rewrite phase is also common. Once the migration project is underway, business stakeholders sometimes request enhancements rather than like-for-like replacements. Without clear scope governance, these additions accumulate and push both timelines and costs beyond what was planned.

The most reliable way to avoid these issues is to complete a thorough assessment before committing to a development budget, and to maintain strict scope discipline throughout the project. You can explore our full range of services to see how we structure that process from the start.

How Optinus helps with Dynamics NAV customization migration

Migrating from Dynamics NAV is not just a technical exercise. It requires clear decisions about what to keep, what to replace, and what to retire, all while keeping the project on time and on budget. That is exactly where we help.

Full customization inventory and As-Is analysis: We document everything in your current NAV environment before a single line of AL code is written, so there are no surprises mid-project.
Fit-gap analysis against Business Central standard functionality: We identify which customizations are already covered natively, reducing unnecessary rebuild work and technical debt.
Structured assessment to prioritise what is worth keeping: We work with your business owners to validate each customization against current operational needs, not assumptions from years ago.
Hands-on project management throughout the migration: Our consultants have delivered real ERP migrations at leading multinationals, so we manage scope, timelines, and stakeholder expectations based on experience, not just methodology.
Test management and go-live support: We cover testing and cutover so that your transition to Business Central does not disrupt daily operations.

If you are preparing for a NAV migration and want to start with a clear picture of where you stand, get in touch with our team or learn more about what we do.

home|

blog|