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. This is the technical companion to our upgrade checklist, which covers the whole project.
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.
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.
The route runs through BC14
C/AL cannot be converted straight from just any NAV version. The pivot point is Business Central version 14 (spring 2019), the last platform that runs C/AL and understands AL at the same time. The classic route: bring your C/AL code forward to BC14, export the objects and run Microsoft’s txt2al converter to turn them into AL files, then fix everything the converter cannot express.
How long the road to that pivot is depends on where you start. From NAV 2017 or 2018 it is a short trip. From NAV 2013 or 2009 the code and data hop through intermediate versions first, each hop with its own compilation and data upgrade. This is where tooling earns its keep: the multi-hop route is slow and error-prone by hand, which is why we built our own conversion and upgrade tooling. It has carried systems from as far back as NAV 2009 forward, including solutions with thousands of objects.
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. 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.
A reliable 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. 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.
A typical modification has two halves. The logic half becomes a subscriber. A C/AL change that defaulted a dimension when the customer changed, for example, converts to this:
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;
}The data half, the fields someone added to a standard table, becomes a table extension (with a page extension to show them):
tableextension 50100 "Customer Ext" extends Customer
{
fields
{
field(50100; "External System Code"; Code[20])
{
Caption = 'External System Code';
DataClassification = CustomerContent;
}
}
}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.
What has no SaaS equivalent
Some C/AL constructs cannot be converted at all, and finding them belongs in the audit, not the build.
.NET interop is the big one. C/AL could call arbitrary .NET assemblies; Business Central SaaS does not allow that. Many uses map to native AL types the platform has since gained (HttpClient for web calls, JSON and XML handling, regular expressions). The remainder move out of BC entirely, typically into an Azure Function that BC calls over HTTPS.
The same applies to anything that touches the server file system, drives COM/Automation objects (that Excel automation someone wrote in 2012), or reads the SQL database directly. None of these are blockers; all of them are redesign work that a good audit prices in advance.
Code conversion is not the data upgrade
Converting objects and upgrading data are two separate workstreams, and quotes sometimes blur them. The data side moves your tables’ contents through every schema change between your version and the target, company by company, with upgrade codeunits handling fields that were renamed, split or restructured along the way. It is mostly mechanical, but it is where the run-time goes, and it is what the trial migration in the data cleanup checklist is there to prove.
Tooling helps, but does not do the job
Conversion tooling, ours included, inventories objects, flags the modified ones, converts the mechanical parts and scaffolds the extension structure. What no tool can do is 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.
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.
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 a conversion number you can budget against? Tell us your story and we will run the object audit.