Company databases, branches and the topology decision
Classify every company database and every branch before any legal entity is created, and understand why branch is the single most consequential organisational call on this path.
What you will be able to do
Classify every company database as legal entity, merge candidate, archive or retirement
Decide what each branch becomes, using registration, tax, inventory ownership and reporting duty as the tests
Separate warehouse and site topology from statutory topology
Anticipate the cross-database collisions that appear the moment companies share an application
Record the organisational decisions that every later workstream depends on
Introduction
Organisational modelling is where a SAP Business One migration is won or lost quietly. The decisions are taken early, they look administrative, and they are close to irreversible: a legal entity created because nobody challenged an assumption stays in the close calendar, the security model and the chart-maintenance workload for the life…
The company database as a migration boundary
In SAP Business One, each company lives in its own database on SQL Server or SAP HANA. Configuration, master data and transactions are contained within it. Nothing crosses the boundary unless someone built an integration to make it cross.
Branch: classify it, never default it
Multi-branch functionality exists in modern Business One releases. What a branch means is a client and localisation decision, and the same estate frequently uses branches inconsistently across its company databases.
Warehouses, sites and the layer that does not exist in the source
Source warehouses map to D365 warehouses — but the mapping is composite, not direct, because the target expects a site above the warehouse and the source usually has no explicit equivalent.
Distribution rules, projects and the analytical layer
Two more source constructs surface in the topology conversation because clients often use them organisationally.
What breaks when isolated companies share one application
This is the consequence that surprises teams most, and it is worth walking through deliberately.
Producing the topology decision record
The output of this module is a document, not a diagram. For every company database and every branch it records:
Knowledge check
Summary
Organisational modelling turns a set of isolated company databases into a governed multi-entity design, and the decisions are close to permanent.