How to classify every Business Central company by purpose — legal entity, operating unit, dimension, consolidation shell, archive or retirement — and design the D365 organisation model that replaces a flat company list with a governed hierarchy.
In Business Central, a company is the primary organisational boundary. It is a data-isolated container within an environment: customers, vendors, items, ledger entries, dimensions, and configuration all live inside a company.
Each environment is an independent application instance with its own version, country localisation, extensions, and database. A production tenant typically has one production environment plus one or more sandboxes.
Legal entity (DataAreaId / CompanyInfo) — the statutory boundary. Every financial transaction, every posting profile, every customer and vendor record is scoped to a legal entity. Creating one implies compliance cost. Operating unit — a non-statutory node in an organisation hierarchy.
Every source company receives exactly one classification. The matrix below provides the decision criteria:
This produces two mandatory legal entities, a consolidation design decision, a dimension/operating-unit decision, and two retirements — not six legal entities.
BC consolidation companies aggregate data from operational companies. The migration must decide how this function is handled in D365:
If two BC companies trade with each other (using IC Partner Codes and intercompany journals/documents), both must become legal entities in D365. D365 intercompany trade operates exclusively between legal entities — it requires intercompany accounting policies, trading partners, and due-to/due-from accounts.
Many BC installations use separate companies where D365 would use a financial dimension. The classic pattern: a UK entity with three regional branches, each maintained as a separate company so that regional P&L reports can be produced without dimension filtering.
BC companies are data-isolated. "Customer 10000 — Contoso Ltd" in Company A and "Customer C-100 — Contoso Limited" in Company B are independent records with no cross-reference. They may represent the same real-world party — or different parties who happen to share a name.
One production environment per geography/deployment (typically one for the entire programme); Multiple Tier-2 sandboxes for parallel workstreams (migration rehearsal, UAT, integration testing); Developer environments for X++ extension work; A governed data-refresh strategy from production to sandbox.
[!IMPORTANT] Freeze the organisation model before starting any configuration workstream. Changing the legal-entity list mid-programme forces rework across posting profiles, account structures, master data, and security — the four most labour-intensive configuration areas.
A Business Central company is a flexible container. A D365 legal entity is a statutory boundary with compliance cost. The migration programme's first structural decision is to classify every source company by purpose and assign a target disposition.