How do you handle custom code during a Dynamics NAV migration?

When you migrate from Dynamics NAV to Business Central, your custom code does not transfer automatically. Every modification, extension, and customisation built directly in the NAV codebase needs to be reviewed, rewritten, replaced, or retired before the migration can succeed. The approach you take to custom code handling is one of the biggest factors in whether your ERP migration runs smoothly or stalls. The sections below walk through the most important questions you will face during that process.

What happens to custom code when you migrate from Dynamics NAV?

Custom code built in Dynamics NAV does not carry over to Business Central in its original form. NAV customisations were typically written directly into the base application using C/AL code, which Business Central no longer supports in the same way. Every piece of custom functionality needs to be inventoried, assessed, and consciously handled before or during the migration.

In practice, this means your migration team needs to produce a full inventory of all modifications made to the NAV codebase. This includes changes to standard tables, forms, reports, and codeunits, as well as any integrations with third-party systems. Without this inventory, it is impossible to scope the migration accurately or estimate the effort involved in rebuilding or replacing functionality.

The assessment phase is where many organisations underestimate the work involved. Custom code that was written years ago, by developers who may no longer be available, often lacks documentation. Reverse-engineering what a customisation does and why it exists takes time, but skipping this step creates serious risk later in the project.

Which types of NAV customisations are hardest to migrate?

The NAV customisations that create the most difficulty during a Business Central migration are those that modify core base objects, rely on deprecated functionality, or are deeply embedded in standard processes. These require the most analysis and carry the highest risk of disrupting business operations if handled incorrectly.

Specifically, the most challenging categories include:

Direct base object modifications: Changes made to standard NAV tables, pages, or codeunits that interweave with Microsoft’s own logic are difficult to isolate and rebuild cleanly.
Complex report customisations: Heavily modified RDLC or Word-based reports often need to be redesigned from scratch rather than converted.
Legacy integrations: Custom-built connections to external systems using older API patterns or direct database access are frequently incompatible with Business Central’s architecture.
Undocumented workarounds: Code written to fix a bug or handle an edge case, with no documentation, requires significant investigation to understand before any decision can be made.
Industry-specific logic: Sector-specific calculations or workflows built entirely in C/AL often have no equivalent in standard Business Central and must be rebuilt as extensions.

The common thread across all of these is complexity combined with poor documentation. The harder a customisation is to understand, the harder it is to migrate safely.

Should you rewrite, replace, or retire custom NAV code?

For each piece of custom NAV code, you have three options: rewrite it as a Business Central extension, replace it with standard Business Central functionality or a third-party app, or retire it if the business need no longer exists. The right choice depends on whether the customisation still serves a genuine business purpose and whether that purpose can be met more efficiently another way.

A structured review of your custom code inventory should categorise every item against these three options. A useful way to frame the decision:

Rewrite when the functionality is genuinely unique to your business and provides competitive value that standard software cannot replicate.
Replace when Business Central’s standard functionality has evolved to cover what the customisation was originally built to do, or when a certified app from the Microsoft AppSource marketplace meets the need.
Retire when the original business reason for the customisation no longer applies, or when usage data shows the feature is rarely or never used.

In many organisations, a significant proportion of custom code falls into the retire category. Business needs change, standard ERP functionality improves, and some modifications were workarounds for problems that no longer exist. Retiring unnecessary code reduces complexity, lowers maintenance cost, and makes the migration faster. Reviewing your ERP transformation services options early helps you understand which approach fits your situation.

How does the extension model in Business Central change custom development?

Business Central replaces NAV’s direct base object modification approach with an extension model built on AL code. Instead of changing Microsoft’s base application directly, all custom functionality is built as a separate layer that sits on top of the standard product. This is a fundamental architectural shift that changes how custom development works and how it is maintained over time.

The extension model offers real advantages. Because customisations no longer touch the base application, Microsoft updates and new releases can be applied without breaking custom functionality. Extensions are versioned, deployable through the Business Central admin centre, and easier to test in isolation. For organisations that struggled with NAV upgrades precisely because of accumulated custom code, this is a meaningful improvement.

However, the extension model also imposes constraints. Not everything that was possible with direct C/AL modification can be replicated cleanly in AL extensions. Some patterns that were common in NAV, such as modifying core table structures in ways that affect standard processes, are deliberately restricted. This is by design, but it means that rewriting custom NAV code for Business Central is not always a straightforward translation. It often requires rethinking the underlying approach.

Understanding this shift early in your ERP migration planning helps you set realistic expectations for the development effort involved and avoid underestimating the rewrite work.

What are the biggest risks of poor custom code handling during a NAV migration?

Poor custom code handling during a Dynamics NAV migration creates risks that can delay go-live, increase costs significantly, and in serious cases cause data integrity problems or operational disruption after cutover. The risks are highest when custom code is migrated without proper assessment or when the full scope of customisations is not understood until late in the project.

The most common risks include:

Scope underestimation: Discovering additional custom code mid-project forces unplanned development work that pushes timelines and budgets.
Data integrity issues: Custom code that affects how data is structured or processed can cause problems during data migration if not properly accounted for in the migration design.
Go-live failures: Functionality that appears to work in testing but behaves differently in production, due to incomplete custom code handling, is one of the most common causes of difficult go-lives.
Post-go-live instability: Poorly rebuilt extensions can introduce bugs or performance issues that surface only under real production load, requiring urgent fixes during the most sensitive period after cutover.
Loss of institutional knowledge: When custom code is rebuilt without fully understanding why it was built, important business logic can be lost, creating process gaps that users only discover after go-live.

The underlying cause of most of these risks is the same: insufficient investment in the assessment and planning phase before development begins. Organisations that treat custom code handling as a technical task rather than a business-critical workstream consistently encounter more problems during migration.

How Optinus helps with Dynamics NAV custom code migration

We work with organisations migrating from Dynamics NAV to Business Central and understand that custom code handling is one of the most underestimated workstreams in any ERP migration. Our approach combines structured assessment with hands-on delivery, drawing on experience from real migrations at multinational organisations rather than theoretical frameworks.

Here is how we support you through this process:

Custom code inventory and assessment: We map every NAV customisation, document its purpose, and categorise it as rewrite, replace, or retire, giving you a clear picture of scope before development begins.
As-Is/To-Be analysis: We analyse your current processes and data structures to ensure that rebuilt functionality genuinely serves your future business needs, not just your historical ones.
Test management: We design and execute testing procedures that specifically target rebuilt custom functionality, reducing the risk of go-live failures and post-cutover instability.
Cutover and data migration management: We manage the transition from NAV to Business Central end-to-end, including hypercare and aftercare, so that operational continuity is protected throughout.
Microsoft Dynamics expertise across the full programme: We are active across Microsoft Dynamics 365 and other ERP platforms, covering every role from project manager to business architect.

If you are preparing for a NAV to Business Central migration and want to understand the full scope of what custom code handling involves, explore our project and programme management services to see how we structure this work. Or get in touch with us directly to discuss your specific situation and what a structured approach would look like for your organisation.

home|

blog|