The object model, extension surfaces and the triage discipline
How Business Central's AL object model — tables, pages, codeunits, reports, queries, XMLports and control add-ins — maps to D365 Finance and Supply Chain Management's X++ extension model, and the structured triage method that turns a customised BC estate into a right-sized target backlog.
What you will be able to do
Name every AL object type and explain its closest D365 X++ counterpart
Explain the C/AL to AL migration arc and why it created the estate you are now triaging
Distinguish AppSource applications from per-tenant extensions and explain how each is treated during migration
Apply the seven-disposition triage method to classify every object by recovered business intent
Size only what survives triage, avoiding the common trap of estimating the entire source estate
Introduction
Business Central and Dynamics 365 Finance and Supply Chain Management are both Microsoft products, share Dataverse connectivity and sit under the same commercial umbrella. That proximity is misleading.
The BC object model
Business Central's application is built from typed objects, each identified by a numeric ID within a defined range and belonging to a named app (or, in the NAV lineage, a modification layer).
The C/AL to AL arc
Understanding the estate you are triaging requires understanding how it was created.
AppSource versus per-tenant extensions
The distinction matters for migration planning because the two carry different obligations.
The D365 extension model in contrast
D365 Finance and Supply Chain Management uses X++ — an object-oriented language compiled into .NET assemblies and deployed as packages containing one or more models.
The seven-disposition triage
Every object, extension, AppSource app and integration surface in the source estate must receive exactly one of seven dispositions before sizing begins.
Applying triage to BC-specific surfaces
Compare the modified object against the exact source build (the same NAV/BC version and CU) to isolate the delta. Recover the business intent of each modification. Many modifications implemented workarounds for limitations that no longer exist in D365 — validate before assuming the requirement persists.
Sizing after triage
Only objects with a disposition of X++ extension, integration or (partially) Power Platform enter the sizing model. The sizing unit is the recovered requirement, not the source object.
Knowledge check
Summary
Business Central's AL object model and D365's X++ extension model solve similar problems — customised ERP behaviour — through fundamentally different mechanisms. No conversion path exists between them. The migration is a structured requirement-recovery exercise, not a code translation.