Blog
From C/AL to AL: what a conversion actually involves
When people picture a NAV to Business Central upgrade they imagine moving data. The data matters, but the technical heart of the project is something else entirely: converting your customisations from C/AL to AL. Understanding what that involves is the difference between a realistic budget and an unpleasant surprise.
C/AL and AL are two different worlds
C/AL was the language of classic NAV. Code lived inside the base application — you opened a standard object and edited it directly. That power is exactly why old NAV systems are so hard to upgrade: your logic and Microsoft’s logic were tangled together in the same objects.
AL is the modern language of Business Central, and it works on a completely different principle. Your code lives in extensions — separate packages that sit alongside the standard application and hook into it through events, without ever modifying Microsoft’s objects.
Why it matters: once your customisations are clean extensions, Microsoft’s twice-yearly updates stop being a project. The base application updates underneath you while your code keeps running on top. That is the whole reason the conversion is worth doing.
Why modified base objects are the expensive category
Split your customisations into three groups: untouched standard, fully custom, and modified standard. The first group is free, the second moves across fairly mechanically — but the third, the modified base objects, is where the real work lives.
Every change someone once made directly inside a standard object now has to be lifted out and re-expressed as an extension. There is no automatic equivalent, because the whole point of AL is that you can no longer edit those objects in place.
Why it matters: an honest estimate counts modified base objects, not lines of code. Two systems with the same number of customisations can differ wildly in cost depending on how deeply those customisations reached into the standard application.
Three outcomes for every modification
Going through the modifications one by one, each lands in one of three places:
- Re-expressed as an event subscriber. Most logic that reacted to a standard action — validating a field, defaulting a value — converts to a subscriber that listens for the matching event.
- Rebuilt as a custom extension object. Genuinely bespoke functionality is rebuilt as new tables, pages and codeunits in your own extension.
- Dropped entirely. If Business Central now ships the feature as standard — approval workflows, document emailing, bank reconciliation imports — the customisation is retired, not converted.
Here is what a typical conversion looks like. A C/AL change that defaulted a dimension when the customer changed becomes a subscriber:
codeunit 50100 "Sales Header Subscriber"
{
[EventSubscriber(ObjectType::Table, Database::"Sales Header", OnAfterValidateEvent, "Sell-to Customer No.", false, false)]
local procedure OnAfterValidateSellToCustomer(var Rec: Record "Sales Header")
begin
Rec.Validate("Shortcut Dimension 1 Code", GetDefaultDepartment(Rec."Sell-to Customer No."));
end;
}Why it matters: the third outcome is the most valuable one. Every customisation you drop is saved twice — once in the conversion, and again in every future maintenance and upgrade hour you no longer pay for it.
Tooling helps, but does not do the job
Conversion tooling exists and is genuinely useful: it inventories objects, flags the modified ones, and scaffolds the extension structure. But it cannot decide whether a given modification should be re-expressed, rebuilt or dropped — that judgement needs someone who understands both the original business intent and current Business Central.
Why it matters: treat any quote that implies a tool does the conversion automatically with suspicion. The tool accelerates the mechanical parts; the decisions are human, and the decisions are where quality is won or lost.
Testing is not optional
Because each modification is rewritten rather than copied, you must prove that the new AL behaves like the old C/AL. That means testing every converted process — posting routines, custom reports, integrations — against known results from the live NAV system.
Why it matters: the conversion is the riskiest part of the upgrade precisely because the code changes shape. Disciplined testing against the old system is what turns that risk into confidence before go-live.
Facing a NAV to Business Central upgrade and want to know what your customisations will really cost to convert? Tell us your story and we will run the object audit and give you an honest, free estimation.