Business Central's code has a lineage going back to a Danish accounting package in the 1980s. How C/AL and C/SIDE came to be, why Microsoft bought it, the long road from modifying the base objects to extending them, the version where C/AL was switched off, and what each step since has added to AL. For developers who want to know why things are the way they are, and for everyone else who has wondered what the consultant meant by "that was a NAV thing".
Every Business Central developer inherits habits, object numbers and vocabulary from a product that is older than most of them. Table 27 is Item because it was Item in 1990. The "Mgt." suffix on codeunits, the 50000 object range, the word "codeunit" itself: all of it comes from a language called C/AL that was retired in 2019 and whose ghost is in every AL file. This is the history, as short as it can be while still explaining why things are the way they are.
Three Danes (Jesper Balser, Peter Bang and Torben Wind) founded PC&C in Copenhagen in 1984 and shipped an accounting package for the IBM PC. In 1987 came Navigator, a multi-user, character-based system that was unusual for the time: it had its own development environment and its own language built in, so that partners could change the application without touching the kernel. That environment became C/SIDE (Client/Server Integrated Development Environment) and the language C/AL (Client/Server Application Language). C/AL was a Pascal-flavoured language with a small set of object types (tables, forms, reports, dataports, codeunits), a database engine of its own, and a deliberately limited feature set: no classes, no pointers, no direct SQL. The limits were the point. A business consultant could read it, and the database could not be corrupted by it.
The object model from that era is the one we still use: numbered objects, numbered fields, a table with triggers (OnInsert, OnValidate), and a codeunit as the unit of logic. Object numbers below 50000 were the product's; 50000 to 99999 were the customer's. That convention is still in app.json today.
In 1995 the Windows version shipped as Navision Financials, the company renamed itself Navision Software, and the product began its run as the mid-market ERP that partners could bend to almost any industry. That flexibility was C/AL's great strength and its long-term curse. A partner could open any object in C/SIDE, change it, and ship the customer a modified product. Every customer became a fork of the base application. Thousands of vertical solutions were built this way; so were thousands of upgrade nightmares, because every new version from Navision had to be merged, object by object, with every customer's modifications. In 2000 Navision merged with Damgaard (makers of Axapta, which would become Dynamics AX and later Finance and Supply Chain) to form NavisionDamgaard.
In July 2002 Microsoft acquired Navision for about $1.45 billion, its largest acquisition at the time, mainly for the partner channel and the mid-market position. The product became Microsoft Business Solutions Navision, then in 2005 Microsoft Dynamics NAV. For a long while Microsoft left C/AL and C/SIDE alone; the big investments went into the client and the platform. Dynamics NAV 5.0 (2007) was the last of the classic era. NAV 2009 introduced the three-tier architecture and the RoleTailored client, with pages replacing forms (and, for a transition period, both coexisting, which was painful). NAV 2013 dropped the native database and became SQL Server only. NAV 2015 added the tablet client. The language itself changed little; the business logic written in 1998 still compiled.
The merge problem had to be solved if the product was ever going to move to the cloud, because Microsoft could not run a cloud service where every tenant was a fork. The answer came in stages. NAV 2016 (October 2015) introduced events: publishers and subscribers, so that partner code could hook into the base application at defined points without modifying it. It also added Try functions and much wider .NET interop. The same release shipped Extensions v1: a way of packaging a set of deltas to base objects and installing them as a unit. It was clumsy (you still worked in C/SIDE and generated deltas) but it was the first time "do not modify the base" was a supported path.
NAV 2018 (December 2017) was the real turn. It shipped Extensions v2 and with them a new language, AL, written in Visual Studio Code with a Microsoft-built AL extension, compiled to an .app package. AL kept C/AL's object model and most of its syntax (deliberately, so that C/AL developers could read it on day one) but added the things extensions needed: table extensions and page extensions as first-class objects, a manifest, dependencies, symbol files, and a modern editor with IntelliSense and a debugger. For a while developers used both: C/SIDE for the base and for customers who would not move, VS Code for new work. A tool called txt2al converted C/AL text exports to AL, imperfectly.
In April 2018 Microsoft launched Dynamics 365 Business Central: NAV, rebuilt as a cloud service, with a new web client and a new name. On-premise followed in October 2018 (version 13), and the version numbering continued from NAV's internal numbers, which is why Business Central started at 12 and 13. The 2018 wave 2 and 2019 wave 1 releases (versions 13 and 14) still supported C/AL and C/SIDE alongside AL, and version 14 (April 2019) was the last. It was the designated migration release: a customer on 14 could still run C/AL customisations and could convert them to extensions in place.
Version 15 (October 2019) removed C/SIDE and C/AL entirely. The base application itself became an AL extension (the "Base Application" app) sitting on a "System Application" of foundational modules, and everything else was an extension on top. From that point, modifying the base application was not just unsupported; it was impossible online. Every customer was on the same code, and the twice-yearly release waves became possible. That is the single most important thing that ever happened to the product, and it is why the fit-gap conversation is what it is: the question is no longer "can we change it" but "should we extend it".
AL has had a new runtime with every major release, and most of the language features that make modern extensions clean arrived in the first few years after version 15:
Access = Internal; report extensions arriving soon after in 18.SetLoadFields and partial records, the biggest performance tool the language has; the obsolete lifecycle formalised with tags.ErrorInfo with actions, the foundation of modern error handling. AL-Go for GitHub arrived the same year.Through all of it the syntax a C/AL developer learned in 1998 still mostly reads the same. That continuity was a choice, and it is why so many of the people building Business Central extensions today started on Navision Financials.
target: Cloud exists: the service could not run arbitrary code from every tenant.If you have one of those, or an extension written by someone who learned on C/SIDE and never quite left, the AL code check is the place to start. Most of us learned there too; it is not a criticism, it is a map.