Practical guide
Existing ERP or a native ERP core: choosing the architecture
A distribution platform can operate as an execution layer beside the existing ERP or include a native ERP and accounting core for the agreed scope. The choice depends on data ownership, accounting maturity, integrations and the migration boundary.
- Implementation: from baseline to controlled scale
- Green Line Trading: product traceability, customer master data and delivery control
- For IT directors
In detail
The existing-ERP model preserves that system as the agreed owner of master data and accounting facts while the platform runs distribution execution. It limits replacement scope but requires observable exchange.
A native core brings execution and accounting into one platform for the selected scope. Accounting policy, opening balances, migration, local requirements and acceptance still need explicit design.
How it is applied
- Map current systems, data owners and critical integrations.
- Decide which processes stay in ERP, move to the platform or operate jointly.
- Compare integration risk with migration and accounting-process risk.
- Select the first production scope and its acceptance criteria.
Practical checklist
- Master data and accounting facts have an agreed owning system.
- The migration boundary is documented by entity and document.
- Local requirements are confirmed in the project rather than assumed.
- The team understands how the first production scope will expand.
Scope and limits
Neither model is universally better. Architecture follows process and data discovery; availability of a native core does not require replacement of the current ERP.