When businesses start planning a NAV to Business Central upgrade, the question that generates the most anxiety is almost always the same: what happens to our bespoke development? Years of C/AL customisations, add-ons, and integrations built specifically for the business represent a significant investment, and the prospect of losing them, or having to rebuild everything from scratch, is enough to put some organisations off starting the conversation at all.
The short answer is that your customisations do not simply disappear, but they do need to be assessed individually. Business Central runs on AL extensions, not C/AL. That is a fundamental architectural change, and it means every customisation in your NAV environment has to be evaluated and one of four decisions made: replace it with standard Business Central functionality, rebuild it as an AL extension, replace it with a supported AppSource application, or retire it. The right answer varies for every item on the list.
This post explains how that assessment works, what each option involves, and why the retail and sports angle changes the calculus significantly compared to a generic ERP environment.
In NAV, customisation typically meant modifying the base application objects directly. A developer would alter a table, form, or codeunit in the NAV source code to change how the system behaved. This worked, but it created a maintenance problem: every time NAV released a new major version, those modifications had to be manually merged with the updated base code. Major upgrades were expensive and disruptive partly because of this accumulation of merges.
Business Central uses a different model. Customisations are built as AL extensions, which sit alongside the base application rather than inside it. When Microsoft releases an update, the base application updates independently. Extensions are designed to survive those updates without manual intervention. This is one of the genuine long-term benefits of moving to Business Central: the cost and disruption of future version upgrades is structurally lower, because the architecture does not allow the kind of base code modification that made NAV upgrades so expensive.
The implication for your existing customisations is that nothing can simply be carried across. C/AL code does not run in Business Central SaaS at all. Every piece of bespoke NAV development has to be dealt with explicitly, which is why a thorough customisation assessment is the foundation of any credible upgrade project.
Replace with standard Business Central functionality. Business Central is a significantly more capable product than NAV in many areas. Functionality that required bespoke development in NAV, because NAV did not support it natively, is often available as standard in Business Central. In BC4's experience, a meaningful proportion of customisations in any NAV environment fall into this category: they were workarounds for NAV gaps that Business Central has simply solved. Identifying these is the most valuable part of the customisation assessment, because it reduces the rebuild scope and cost directly.
Rebuild as an AL extension. For customisations that address genuine business requirements not covered by standard Business Central functionality, the right approach is to rebuild the logic as an AL extension. This is not a conversion of C/AL to AL; it is a proper rebuild in the modern language, designed to work with Business Central's architecture and survive future updates. The effort required depends on the complexity of the original customisation and whether the underlying requirement is still the same as when it was first built.
Replace with an AppSource application. The Business Central AppSource marketplace contains certified extensions covering a wide range of functionality: industry-specific add-ons, integrations with third-party platforms, and enhancements to standard modules. For customisations that addressed a requirement shared by many businesses, there is often an AppSource application that covers the same ground more robustly and with ongoing vendor support. Checking AppSource before committing to a rebuild is always worth doing.
Retire. Some customisations were built for requirements that no longer exist, or for processes that have changed beyond recognition. Others were workarounds for NAV quirks that simply do not apply to Business Central. Retiring a customisation reduces cost, reduces maintenance overhead, and simplifies the system. In BC4's project experience, a proportion of customisations in any NAV environment are candidates for retirement, and the scoping conversation is often the first time the business has reviewed whether those customisations still serve a purpose.
The four-option framework applies to every NAV upgrade. What changes in retail and sports environments is the nature and scale of the customisations being assessed.
A mid-market manufacturer or distributor might have a limited set of bespoke customisations: a custom approval workflow, a modified purchase order form, a handful of report layouts. The assessment is manageable and the rebuild scope is contained.
A multi-site retailer running LS Retail on top of NAV is a categorically different situation. LS Nav, the retail layer built on Dynamics NAV, is itself a discontinued product. LS Retail replaced it with LS Central, which runs on Business Central. Moving from LS Nav to LS Central is a platform migration in its own right, running concurrently with the broader NAV to BC upgrade. On top of that, retailers typically carry a further layer of bespoke development built on top of LS Nav: custom POS receipt layouts, bespoke discount and pricing logic, loyalty scheme integrations, tender type rules, kiosk interfaces, and eCommerce connectors.
Each of those needs to be assessed against the four options. Some POS logic, for example, will be covered by LS Central natively. Some loyalty functionality is available through LS Central's built-in loyalty module. Other elements, particularly custom integrations with third-party ticketing, membership, or eCommerce platforms, will require a rebuild or replacement. The scope of that work is what makes retail and sports upgrade projects longer and more complex than the generic ERP equivalent.
POS customisations. Bespoke POS logic built in C/AL, such as custom receipt formats, modified tender type handling, loyalty integration rules, and staff discount logic, cannot run in Business Central SaaS. Each element needs to be assessed: does LS Central cover it natively, is there an AppSource extension that handles it, or does it need to be rebuilt as an AL extension? For most retailers, the answer is a combination of all three across different parts of the POS configuration.
Loyalty scheme integrations. Loyalty programmes built on LS Nav often carry years of member data, complex tier logic, and reward rules that were implemented as bespoke code. The data migration is a distinct workstream. The loyalty logic itself needs to be assessed: LS Central has a native loyalty module that covers a significant proportion of standard requirements. Custom tier rules or integrations with external CRM or loyalty platforms require explicit assessment and, in most cases, a rebuild.
eCommerce connectors. NAV eCommerce integrations were built for NAV's SOAP-based web service architecture. Business Central uses REST and OData APIs. Even integrations that connected to standard platforms, such as Shopify or WooCommerce, require rebuilding rather than reconfiguring. Vendors in this space typically maintain separate NAV and BC connector products, and the migration from one to the other is a connector replacement project in its own right.
Ticketing and membership integrations. Sports clubs frequently built integrations between NAV and their ticketing or membership platforms as custom C/AL code. These integrations need to be rebuilt as AL extensions or, where the ticketing platform has released a Business Central connector, replaced with the vendor's supported solution. Either way, this is not a configuration task; it is a rebuild, and it needs to be scoped and costed explicitly.
The customisation assessment is not just a cost exercise. It is also an opportunity to rationalise a system that has accumulated years of development decisions, some good and some not. Businesses that use the upgrade as a moment to review what they actually need, retire what they do not, and rebuild what matters properly on AL extensions, arrive in Business Central with a cleaner, more maintainable system than the one they left.
The AL extension architecture means that future Business Central updates do not require the same level of manual intervention that NAV upgrades did. Extensions are designed to survive updates. That changes the long-term maintenance cost of the platform and reduces the risk of being caught in the same position in five years, where accumulated technical debt is making the next transition more expensive than it should be.
BC4 has delivered both technical upgrades and clean-start reimplementations for retailers and sports organisations. In both cases, the customisation assessment is where the project is shaped and where the most important decisions get made. Getting it right at the start is the single most effective thing a business can do to control cost and outcome.
BC4 offers a free upgrade assessment that maps your NAV customisations and integrations, applies the four-option framework to each one, and gives you a clear picture of rebuild scope, cost, and timeline. Get in touch to arrange a call.
No. Business Central uses AL extensions, not the C/AL code that NAV customisations were built in. C/AL does not run in Business Central SaaS at all. Every customisation has to be assessed individually and one of four decisions made: replace with standard Business Central functionality, rebuild as an AL extension, replace with an AppSource application, or retire. A thorough assessment at the start of the project determines what that looks like for your specific environment.
The customisation assessment, which is the first substantive phase of any credible upgrade project, maps every bespoke development in your NAV environment. For each one, the question is whether the underlying business requirement still exists and whether Business Central or an AppSource application already covers it. In most NAV environments, a meaningful proportion of customisations were workarounds for limitations that Business Central has addressed natively. Identifying those early reduces rebuild scope and cost significantly.
C/AL was NAV's customisation language. Modifications were made directly to NAV's base application objects, which created a merging problem at every major version upgrade. AL extensions are separate from the Business Central base application. They run alongside it rather than inside it, which means Microsoft's regular updates to Business Central do not require manual merging of your customisations. This makes the long-term maintenance of a Business Central environment structurally cheaper than maintaining a heavily customised NAV environment was.
LS Nav and LS Central are distinct products. LS Nav is discontinued; LS Central is the Business Central-native successor. Moving from one to the other is a platform migration in its own right, running alongside the broader NAV to BC upgrade. Customisations built on LS Nav in C/AL need to go through the same assessment process: replace with LS Central native functionality (the coverage is significant), rebuild as AL extensions, replace with supported AppSource applications, or retire. BC4 specialises in exactly this transition for retail and sports environments.
AL extensions are specifically designed to survive Business Central's biannual update releases without manual intervention. This is one of the key architectural differences from NAV, where base code modifications had to be manually merged with each major version update. Getting your customisations properly built as AL extensions during the upgrade project is what secures this benefit for the long term.