A Dynamics NAV to Business Central upgrade should not start with the question, “How do we recreate everything?” It should start with, “What still earns its place?” Many NAV customisations were built around old constraints, local habits or reporting gaps. Rebuilding them by default can increase scope, cost, testing and future support without improving the business.
Should every NAV customisation move into Business Central?
The safest answer is often no.
Copying every old customisation can feel like risk control because users recognise the process and leaders avoid difficult decisions. In practice, it can do the opposite. It can carry old friction into a cloud ERP environment that was meant to reduce manual work, improve visibility and make future change easier.
A NAV-to-Business Central migration is not just a technical move. It is a chance to test the business operating model behind the system. Which processes still protect control? Which reports still guide decisions? Which fields, approvals, integrations and routines exist only because NAV once lacked a cleaner route?
Microsoft’s implementation guidance for Dynamics 365 points to a clear sequence: start with fit-to-standard, then use fit-gap analysis where standard functionality does not meet a valid business need. That order matters. If the project begins with a list of legacy modifications, the team can end up designing Business Central around the old system rather than the business.
The practical question is not whether customisation is bad. It is whether a customisation still creates measurable value.
A custom field that supports margin control, compliance, traceability or industry-specific fulfilment may deserve to be rebuilt as a Business Central extension. A bespoke report that no one can explain, a manual export created for an old spreadsheet, or an approval step built around a former manager’s preference may not.
That distinction has real commercial weight. Every unnecessary Business Central customisation adds design time, build effort, test scripts, training content, documentation and future maintenance. It can also complicate updates and make support harder. For IT leaders, that means a more complex core. For finance and operations leaders, it can mean slower adoption and less trust in the new system.
The strongest migration scopes are usually the ones that are selective early. They protect functionality that supports control, continuity and performance. They remove workarounds that add no current value. They use standard Business Central functionality where it fits. They reserve extension-based development for the processes that genuinely differentiate the business or protect operational discipline.
This is where early advisory work pays for itself. Before scope is locked, leaders need a clear view of which NAV customisations should be kept, replaced, redesigned or retired. Without that review, the project may preserve exactly the problems the upgrade was supposed to solve.
Old NAV workarounds should be tested, not protected
A NAV workaround is worth keeping only when it still supports a current business need better than standard Business Central functionality. Familiarity is not enough. The test should be business value, not habit: does the workaround improve control, visibility, compliance, margin, speed or operational reliability now?
Many NAV estates carry years of small fixes. A field added for one customer. A report created for a former finance process. A posting routine shaped around an old approval chain. A manual export built because two systems did not talk to each other at the time.
Each may have been sensible when it was created. That does not mean it deserves a place in the new cloud ERP.
The Earn Its Place Test
Before rebuilding a NAV customisation in Business Central, ask five questions:
- What current problem does it solve? If the answer refers to an old process, the case is weak.
- Who uses it and how often? A monthly exception report needs a different level of scrutiny from a daily warehouse control.
- What happens if it is removed? Look for real consequences: missed compliance checks, slower invoicing, stock errors, margin leakage or manual rework.
- Can Business Central standard functionality replace it? Standard functionality should be tested before extension-based development is scoped.
- What will it cost to rebuild, test, train and maintain? The build cost is only one part. Long-term support and future update impact matter too.
| Old NAV input | Current business test | Risk if copied by default | Better decision |
| Bespoke approval field | Does it still protect spend control? | Adds steps no one owns | Keep only if tied to a live approval rule |
| Legacy finance report | Does it answer a current board question? | Recreates reporting clutter | Replace with standard reporting or Power BI where suitable |
| Manual data export | Is the receiving process still needed? | Preserves spreadsheet dependency | Redesign the integration or retire the export |
| Custom posting logic | Does it protect compliance or margin? | Adds testing and support risk | Rebuild only with a clear business case |
This is where process-first discovery prevents expensive drift. The project team should map current-state work, define the future state, then decide what Business Central needs to support. That sequence stops old technical debt being dressed up as business requirement.
The buyer implication is straightforward. If a business copies every workaround, it may protect short-term comfort but weaken long-term control. If it tests each workaround properly, it can keep the processes that matter and reduce the drag that made NAV harder to run.
Data, reports and routines can clutter Business Central from day one
A clean Business Central environment needs clear migration boundaries. Not every historic record, report, field or user routine belongs in the live system. The right data strategy protects continuity while keeping the new ERP usable, trusted and easier to support.
This is one of the most common NAV-to-Business Central migration traps. Leaders focus on custom code because it looks complex, yet old data and reporting habits can create just as much drag.
A full historical migration may sound reassuring. Finance can see the past. Operations can search old transactions. Users feel nothing has been lost. The problem is that volume is not the same as value. If historic data is duplicated, poorly structured, inconsistent or no longer used for daily decisions, it can make Business Central harder to reconcile and harder to trust.
The live system should hold what the business needs to operate well now. That usually means active master data, open items, current suppliers and customers, inventory information, balances, live orders, required compliance records and the operational history needed for service or reporting. Older detail may still matter, but it may be better placed in archive, Power BI, document storage or a reporting environment rather than carried into the core ERP.
A practical migration decision should separate four choices
| Migration choice | Use it when | Business benefit |
| Bring | The data is needed for daily processing, compliance or open work | Protects continuity |
| Transform | The data is useful but needs cleansing, mapping or restructuring | Improves trust and reporting |
| Archive | The data is needed for reference, audit or historic analysis | Reduces live-system clutter |
| Retire | The data, report or routine no longer supports a current need | Cuts noise and support effort |
Reports need the same discipline. A NAV report should not move across just because someone once asked for it. The better question is: what decision does this report support now?
Some reports can be replaced by standard Business Central views. Some belong in Power BI. Some need redesign because the management question has changed. Some should disappear because they only expose data no one acts on.
User routines also need review. If teams have spent years working around NAV limitations, their habits may be part of the problem. Recreating every click path, export, spreadsheet and manual check can reduce adoption because Business Central starts life feeling like the old system with a new interface.
The goal is not a thin system. It is a trusted one. When data is cleaner, reports answer real questions and routines reflect the future process, users can build confidence earlier. That confidence reduces support tickets, speeds training and gives leaders a clearer view of cost, stock, cash and operational performance.
Keep what creates value, remove what creates drag
The best NAV to Business Central migration keeps valuable functionality and removes avoidable complexity. The aim is not a “vanilla” system at any cost. The aim is a cleaner operating platform where customisation is deliberate, owned and easier to support.
A customisation should survive when it protects something the business still needs: margin control, regulatory compliance, stock accuracy, customer service, production flow, financial governance or a genuine competitive process. It should not survive because “we have always done it this way.”
The Keep, Replace, Redesign, Archive, Retire checklist
| Decision | Use when | Leadership question |
| Keep | The function still supports control, compliance, performance or continuity | What value would be lost without it? |
| Replace | Standard Business Central functionality now covers the need | Why pay to rebuild what already exists? |
| Redesign | The old idea is valid, but the process or technology is outdated | What would the future process look like if we were not constrained by NAV? |
| Archive | Historic information is needed for audit or reference, not daily work | Where should this sit without cluttering the live system? |
| Retire | The item no longer has a clear owner, use case or business value | What risk are we really removing by letting it go? |
This checklist should sit near the front of the project, before budgets and timelines harden. Once every requested customisation is in scope, removing it becomes politically harder. Early decisions protect delivery confidence.
For senior leaders, this is a governance issue as much as a technical one. Each Business Central customisation should have a named business owner, a clear reason, an understood maintenance impact and a testing route. That gives IT fewer exceptions to support. It gives finance and operations clearer accountability. It gives the project team a stronger basis for controlling cost and change requests.
FAQs
Should we rebuild all NAV customisations in Business Central?
No. Rebuild only the customisations that still support current business value, control, compliance, visibility or operational performance.
What is fit-to-standard in Business Central?
Fit-to-standard means testing whether standard Business Central functionality can support the business process before custom development is considered.
When should a NAV customisation become a Business Central extension?
A customisation should become an extension when the need is current, valuable, not covered well by standard functionality and worth maintaining over time.
How much historical NAV data should move into Business Central?
Move the data needed for live operations, open work, compliance and trusted reporting. Archive older data where it is needed for reference but not daily processing.
