How to turn IFS's Company–Site–Warehouse hierarchy and Code Part structure into a defensible D365 structure of legal entities, sites, financial dimensions, and operating units — and why the Site is the central design hinge.
The most consequential design decision in any IFS migration — the one that every other configuration depends on — is the organisational structure. How many legal entities does D365 need? Which IFS Sites become D365 Sites and which become dimension values? What replaces the multi-code-part context that IFS stamps on every voucher row?
IFS structures the enterprise around four levels, each with a distinct operational role.
D365's organisational model inverts the emphasis. The Legal Entity — stored in CompanyInfo and partitioning almost every transactional table via DataAreaId — is the dominant primitive. Sites and Warehouses exist as operational refinements within a Legal Entity, not as peers to it.
The IFS Site is the design hinge of the migration because it carries two kinds of meaning simultaneously:
IFS's Code Parts B through J contribute to the organisational model in a way that has no direct D365 structural equivalent. They are the analytical context carried on every voucher row: cost centre, project, department, counterpart, and up to five freely configurable slots.
The net structural result of the organisational mapping follows a consistent pattern.
IFS and D365 both describe the same enterprise; they do so through different structural choices, and the migration translates one into the other.