C/AL to AL: The Complete Migration Cheat Sheet (2026 Edition)
If you learned C/AL in the Dynamics NAV era, the good news is that most of your knowledge still applies. AL, the language of Microsoft Dynamics 365 Business Central, kept the core concepts — tables, pages, codeunits, triggers but modernized the syntax and moved everything to an extension-based model. C/AL and the classic C/SIDE environment were retired back in Business Central version 15 (2019), and as of 2026 we are already 13 major versions into the fully AL-based world.
This cheat sheet maps the most common C/AL patterns to their AL equivalents so you can migrate old code (or old skills) quickly.
1. The big picture: what changed
| Concept | C/AL (NAV) | AL (Business Central) |
|---|---|---|
| Development tool | C/SIDE (Object Designer) | Visual Studio Code + AL Language extension |
| Customization model | Modify base objects directly | Extensions only never modify the base app |
| Object files | Stored in the database | Plain-text .al files in a project, version-controlled with Git |
| Deployment | Import .fob / .txt files | Publish .app packages (extensions) |
| New object types | — | Table extension, page extension, enum, interface, report extension, permission set |
2. Object declaration
In C/SIDE you created objects through the Object Designer. In AL, every object is code. A table now looks like this:
table 50100 "My Customer Rating"
{
DataClassification = CustomerContent;
fields
{
field(1; "Customer No."; Code[20])
{
TableRelation = Customer."No.";
}
field(2; Rating; Integer) { }
}
keys
{
key(PK; "Customer No.") { Clustered = true; }
}
}
Instead of modifying the standard Customer table, you extend it:
tableextension 50100 "Customer Ext" extends Customer
{
fields
{
field(50100; "Loyalty Level"; Option)
{
OptionMembers = None,Bronze,Silver,Gold;
}
}
}
3. Syntax cheat sheet
| Task | C/AL | AL |
|---|---|---|
| Declare a function | PROCEDURE MyFunc@1() : Boolean; | procedure MyFunc(): Boolean |
| Local variables | VAR section in a separate window | var block written inline above begin |
| Text constants | Text001@1000 : TextConst 'ENU=Hello'; | HelloLbl: Label 'Hello'; |
| Options | OptionString property on a field | Prefer enum objects (extensible!) |
| Case of keywords | IF ... THEN ... ELSE (uppercase) | if ... then ... else (lowercase) |
| Record filtering | SETRANGE, SETFILTER, FINDSET | Same methods, lowercase: SetRange, SetFilter, FindSet |
| Dialogs | MESSAGE, ERROR, CONFIRM | Message, Error, Confirm — plus ErrorInfo for actionable errors |
| .NET interop | DotNet variables | Not available in the cloud — use HttpClient, JsonObject, XmlDocument AL types instead |
4. Enums replace Options
The single most useful new concept. Options in C/AL could not be extended by other developers; enums can:
enum 50100 "Loyalty Level"
{
Extensible = true;
value(0; None) { Caption = 'None'; }
value(1; Bronze) { Caption = 'Bronze'; }
value(2; Silver) { Caption = 'Silver'; }
value(3; Gold) { Caption = 'Gold'; }
}
5. Events replace direct modifications
In NAV you would edit Codeunit 80 to change posting behavior. In AL you subscribe to events instead, so your change survives every upgrade:
codeunit 50100 "Sales Post Subscriber"
{
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Sales-Post",
OnBeforePostSalesDoc, '', false, false)]
local procedure CheckLoyaltyOnPost(var SalesHeader: Record "Sales Header")
begin
// your logic here, upgrade-safe
end;
}
6. Web services and files
Old patterns that relied on DotNet, FILE, or automation objects need rethinking in the cloud:
- HTTP calls: use the built-in
HttpClient,HttpRequestMessage, andHttpResponseMessagetypes. - JSON: use
JsonObject,JsonArray,JsonToken. - Files: there is no server file system in SaaS. Use
InStream/OutStreamwithUploadIntoStreamandDownloadFromStream, or Blob storage.
7. Tools that do the heavy lifting
- Txt2AL — converts exported C/AL .txt objects into .al files. A great starting point, though the output usually needs cleanup.
- AL Language extension for VS Code — IntelliSense, snippets (type
ttable,tpage,tcodeunit), and one-key publishing with F5. - AZ AL Dev Tools / AL Code Outline — community extension that massively speeds up refactoring.
- Cloud migration tooling — for moving data from NAV on-premises to Business Central online once your customizations are extensions.
8. Upgrade path reality check (2026)
If you are still on an old NAV version, you cannot jump straight to the current release. Older on-premises deployments must first upgrade to an intermediate supported version before moving to version 28 (2026 release wave 1), and all customizations must be converted to extensions before a cloud migration. Budget real time for this — the technical conversion is often the easy part compared to testing.
Final thoughts
C/AL knowledge is not wasted — it is the foundation. The business logic, table structures, and posting routines you know from NAV are still recognizably there. What changed is how you touch them: through extensions, events, and modern tooling. Learn enums, events, and the VS Code workflow, and you are 80% of the way to being a productive AL developer.
Have a specific C/AL pattern you are struggling to convert? Drop it in the comments and I will cover it in a future post.
Comments
Post a Comment