Good Business Central customization is mostly about restraint. The code you write has to live alongside Microsoft’s own code and survive every update Microsoft ships. Get the approach right and updates are routine. Get it wrong and every release becomes a small project. This is how we approach it, and what to ask of any partner you hire.
At a glance
- Customise through extensions written in AL. Never change the base application.
- Per-tenant extensions are for what is unique to you. AppSource apps are for problems many companies share.
- There are two major releases a year. Test against the next one before it reaches production.
- Integrate through APIs and Power Automate, not through the database.
- Do not port old NAV customisations as they are. Much of it is standard now.
- Keep the source code in a repository you control.
Business Central customization starts with extensions
In the NAV years, developers edited the standard code directly. Fast on the day, expensive on every upgrade, because each change had to be merged by hand. Plenty of companies stopped upgrading.
Business Central online does not allow that. You extend instead: table extensions for new fields, page extensions for changed screens, and event subscribers for new logic that hooks into events the standard code raises. The base app stays untouched, which is what lets Microsoft update it underneath you.
If the event you need is not there, do not copy the standard logic into your extension. Find another route or request the event from Microsoft. Copied standard code is one of the most common reasons an extension breaks after an update.
Per-tenant extension or AppSource app
A per-tenant extension is built for one company and installed only in that company’s environment. Use it for your own processes, reports and rules.
An AppSource app is a product that many companies install. Check AppSource before commissioning anything. The trade-off is that you accept the vendor’s design and depend on them to keep up with Microsoft’s releases.
Our rule of thumb: buy what is standard in your industry, build what makes you different.
Living with two major releases a year
Microsoft ships one major Business Central release in spring and one in autumn, with smaller updates in between. You can schedule an update within a window. You cannot skip it.
So an extension is never finished on go-live. Three habits keep it upgrade-safe. Use only what Microsoft exposes for extensions. Treat obsolete warnings from the compiler as tomorrow’s errors. And run your extensions against the preview of the next release in a sandbox as soon as it is available. That is routine software maintenance, not a new project every six months.
Integrations through APIs
Business Central ships standard APIs for common data, and you can add your own API pages in an extension. Power Automate covers simple flows.
Connecting a webshop, a warehouse system or a CRM is often the largest part of the work. It needs error handling, logging and a clear decision on which system owns which data. Plan it as proper API development. If Dynamics 365 Sales or Customer Service is part of the picture, use Dynamics 365 developers who know both sides.
Moving from NAV and C/AL
On an older NAV installation, resist converting everything. Ask two questions of each customisation: is this still used, and does standard Business Central now do it? A good share can usually be dropped.
What remains should be redesigned as extensions. Conversion tools turn C/AL into AL, but the output is old logic in new syntax. Data also has to be moved and reconciled, and that is where timelines tend to slip. Treat it as database work from day one.
Testing and owning the code
AL comes with its own test framework. Automated tests are the cheapest insurance against a release breaking your processes. Run them on every change and on every new Microsoft version.
Make sure the source lives in a version-controlled repository you have access to. If a previous partner handed over only the compiled app file, nobody else can maintain it. Unsure what you have? A code audit is a sensible first step.
Frequently asked questions
Not in Business Central online. All customization happens in extensions on top of the standard application, which is exactly why updates no longer require a large upgrade project.
Both are written in AL. A per-tenant extension is built for one company, while an AppSource app is a product many companies install.
If they use only the events and objects Microsoft exposes, they usually keep working. Test them against the new version in a sandbox before it reaches production anyway.
Business Central comes with country-specific localisations, including Danish. A partner who works in the same market knows those features and the local practices around them, and shares your time zone.
The short version
Extend, never modify. Test against every release. Integrate through APIs. Keep the code in your own hands. Done that way, Business Central customization stays an asset rather than a bill that arrives twice a year. See our Business Central development services.
Want a second opinion on your extensions or a NAV system that needs to move on? Get in touch.
