Business Central C/AL to AL conversion for customized NAV systems

Why C/AL code has to become AL for Business Central

In NAV, developers changed Microsoft's own objects directly in C/SIDE. They added a field to the customer table. They inserted a line into the sales posting codeunit. It worked. However, every new version meant merging those edits into fresh base code by hand. Upgrades became expensive projects.

Current Business Central does not allow that. Microsoft delivers the base application as its own apps. Customers add behavior through extensions written in AL with Visual Studio Code. Business Central online accepts nothing else. So conversion is a must for anyone leaving NAV with custom code they still need.

What the C/AL to AL conversion tools do

Microsoft provides Txt2AL. This tool reads objects exported in the newer text syntax and writes AL files. Brand new custom objects, such as your own tables, pages and codeunits, convert almost directly. Simple additions to standard objects come out as table extensions and page extensions.

Code changes inside standard objects are different. The tool cannot decide which event should carry logic that sat in the middle of a posting routine. That remainder is where the real effort of a conversion lies. A developer must judge everything else.

Moving modified code into event subscribers

For each changed standard function, we find what the modification was for. Then we look for a published event at the right point in current Business Central. Usually one exists. The custom logic moves into a subscriber codeunit, and the base code stays untouched. Updates then apply cleanly.

Sometimes the old change has no purpose left, because standard Business Central now does the same thing. We retire those instead of converting them. Where no suitable event exists, we redesign the requirement. Or we ask Microsoft for an event through its public request process. Code that used .NET interop gets rewritten with AL modules or Azure functions for cloud use.

How we run a Business Central C/AL to AL conversion

First, we compare your database against the unmodified NAV version it started from. That gives an exact list of every changed and added object. We tag each item with its owner in the business and one of the decisions above. The list becomes the scope. You agree it before conversion starts.

Next, we convert the code into one or more extensions in source control. We compile them against the target Business Central version and deploy to a sandbox. Upgrade codeunits move data from old custom fields into the new extension tables. Then users run their daily processes in test, and we correct what they find.

Conversion shortcuts that cost more later

The tempting shortcut is one large customized app. Then you carry on. That blocks a move to Business Central online. It also leaves each future update as painful as before. We advise against it, except as a brief stepping stone.

The opposite mistake is converting everything faithfully. Old systems collect reports nobody runs and fields nobody fills. Usage data and a frank talk with each team lead often cut a good share of the list. As a result, the project gets shorter and the system stays lighter to maintain.

Business Central C/AL to AL conversion questions

Can a C/AL to AL conversion run automatically?

Partly. The Txt2AL tool converts object syntax and handles additions such as new tables, fields and pages. Changes inside Microsoft's own code need a developer to move the logic to event subscribers. That hand work most often sets the size of the project.

Do we have to convert before moving to Business Central online?

Yes. Business Central online runs only extensions. So any customization you want to keep must exist as an AL extension first. Data then moves with the cloud migration tool once the on-premises database runs a supported version.

What happens to data in our custom fields?

It is preserved. Custom fields on standard tables become fields in a table extension. Upgrade code copies the values across during the technical upgrade. We run that on a copy of your database and compare record counts and sample values before the real cut-over.

Does a very old NAV version change the conversion?

Older NAV versions often need an extra upgrade step first. Only then can you export objects in the syntax the tool reads. Classic reports and forms need a transform first. The principle is the same, with more stages on the way.

Will a third-party add-on in our NAV database be converted too?

Most often not by us. The add-on's publisher often sells a current extension version. The right path is to install that and migrate its data. We list each add-on in the comparison and ask its publisher what it offers now.

Related upgrade and development pages

Code conversion is one stage of a wider NAV to Business Central move. These pages cover the upgrade project around it. They also describe the AL development practices the converted code should follow. Read them together to plan the whole move. Our consultants can walk your team through each stage, and we answer questions during US business hours. A clean Business Central C/AL to AL conversion makes every later step easier. For the product detail, see The Txt2AL conversion tool on Microsoft Learn.