It's the objection that holds back more migrations than any other: «we've had years of custom development in Navision, if we migrate we'll lose all of that». It's a fair concern, but the answer is almost always more reassuring than expected. Here's what actually happens to each type of customisation.
First things first: they're reviewed one by one, not as a block
There's no «all or nothing». Every piece of custom development in your Navision is analysed separately and ends up in one of three places:
- It's already built into Business Central. This happens more often than people think: functionality that was once custom-built because Navision didn't include it is standard today.
- It's rebuilt as an extension. This is the modern way to customise Business Central: code kept separate from the ERP's core, in the AL language.
- It no longer makes sense. Over the years, some development becomes obsolete because the process it solved has changed or is no longer used. Migrating is also the moment to tidy up.
Why extensions are better than classic customisations
In Navision, customisations were almost always built by modifying the standard code directly. It worked, but it had a hidden cost: every Microsoft update could break those changes, because they touched the same code Microsoft was also touching.
Extensions written in AL solve exactly that problem: they're added «alongside» the standard, without modifying it. Microsoft can update Business Central as normal and your extension keeps working, because it never touched the code being updated.
It's not just a change of technology: it's no longer having to fear every update.
What about integrations with other systems?
They're reviewed with the same logic: online store, e-banking, EDI with customers or suppliers, POS… Business Central has standard connectors for many of these cases that had to be built from scratch in Navision, so the integration often ends up simpler, not more complex, in the new system.
What information you should have ready
To build this inventory accurately, it helps to have to hand:
- A list of the custom development you can remember (even informally, without technical documentation).
- What external integrations are currently active.
- If you have a current maintenance partner, ask them for the customisation object list or change history, if one exists.
It's fine if there's no formal documentation: part of the assessment work is precisely rebuilding that inventory from the live system.
Frequently asked questions
How much does it cost to rebuild a customisation as an extension?
There's no single figure, because it depends entirely on how the original customisation was built and how complex the logic behind it is. A form with a couple of extra fields or a simple validation is usually sorted in a few hours of development. A customisation that automates a whole process, touches several tables or replicates an entire workflow specific to your business needs considerably more work, closer to a small project in its own right. That's exactly why the initial assessment we run before any migration always breaks the estimate down piece by piece, development by development, rather than handing you one lump figure for «all the customisations» — which is also the same logic we apply when estimating the overall cost of migrating from NAV to Business Central.
Can I keep using custom-built reports?
Yes, and in most cases you end up in a better position than before. Reports are migrated as extensions just like any other piece of custom development, so the ones you actually still need keep working without losing any of their original logic. What changes is that Business Central integrates natively with Power BI, which means several reports that used to require custom development in Navision — because there was no other way to get that view of the data — can now be built as a standard interactive dashboard instead, often with better filtering and visualisation than the original custom report ever had.
What if a piece of development is so old nobody knows what it's for any more?
It happens far more often than people expect, especially in companies that have been on the same ERP for over a decade with different people passing through the finance or IT department. During the assessment we don't just look at the code: we check with the people actually using the system today whether that specific development is still genuinely in use, or whether it's a leftover from a process that no longer exists. If nobody can explain what it's for and nobody is using it, migrating is the ideal, no-cost moment to retire it for good, instead of dragging it into the new system just because «it's always been there».
In summary
Your custom development isn't lost when you migrate: it's reviewed one piece at a time and almost always ends up in better shape than in Navision, as extensions that don't break with every update. The fear of «losing what we have» usually disappears as soon as that detailed inventory is done.
If you'd like to know what would happen to your specific customisations, check out our Navision to Business Central migration service or tell us what you have customised and we'll tell you, piece by piece, which option fits best.