C/AL to AL conversion explained: process, pitfalls and timeline

What changed between C/AL and AL

C/AL customisations modified Microsoft's base objects directly — you changed table 36, page 42, codeunit 80. AL forbids exactly that. Custom code lives in extensions: separate apps that add table fields, page controls and event subscribers without touching the base application.

The toolchain changed with it. Development moved from the classic C/SIDE environment to Visual Studio Code with the AL Language extension, Git-based source control and per-app packaging. This is what makes Business Central's continuous updates possible: Microsoft can upgrade the base application because your code no longer lives inside it.

The conversion process

• Export and delta: extract customised objects and compute the delta against the matching standard NAV version, so only genuine customisations are in scope.
• Mechanical conversion: Microsoft's Txt2AL tooling converts C/AL syntax to AL and produces table/page extension scaffolding. Treat the output as raw material, not a result.
• Event-based refactoring: logic that was written inside base objects is re-attached through event subscribers and interfaces. This is the real engineering work.
• Report rebuild: classic and heavily modified RDLC reports are restructured; many are better replaced with Word layouts or standard reports plus a small extension.
• Dependency cleanup: .NET interop is replaced with native AL, HttpClient-based calls or an Azure Function where server-side .NET is unavoidable.

The pitfalls that cost weeks

Three patterns cause most overruns. First, hidden base-app modifications: a single changed line in codeunit 80 from 2012 that nobody documented, discovered only when posting behaves differently. A disciplined delta analysis at the start prevents the surprise.

Second, .NET add-ins and file-system access. Business Central online has no server file system and no arbitrary .NET, so integrations built on flat-file exchange need redesigning around APIs, Azure Blob storage or email.

Third, report volume. Databases often carry hundreds of report objects of which a fraction is used. Print-usage analysis before conversion routinely cuts the report workload in half.

Quality gates worth enforcing

A conversion is done when it compiles — a good conversion is done when it passes gates: zero compiler warnings, the AppSourceCop or PerTenantExtensionCop analyzers clean, no usage of obsoleted methods, and compliance with Microsoft's Universal Code requirements so the app is cloud-ready even if you deploy on-premises first.

Automated tests for critical posting routines pay for themselves at the very next Business Central release wave.

How long does it take?

For orientation: a NAV database with a few hundred customised objects converts and refactors in four to eight developer-weeks; large environments with thousands of modified objects become multi-month work packages best cut into fixed-price milestones per functional area.

The variable that moves the estimate most is not object count — it is how deeply base behaviour was modified, which is exactly what the up-front assessment measures.