Why a QAD programme is governed by topology, companion-product disposition and an honest admission about what public documentation does not reveal — long before any field mapping begins.
QAD Adaptive ERP is a manufacturing ERP with a clear centre of gravity: automotive and industrial manufacturing on one side, regulated life sciences and medical device on the other. It is genuinely strong there.
"QAD" in a scoping conversation usually means the whole estate. In migration terms it is five distinct source domains, each with a different target home.
QAD organises the business through a three-level structure — domain, entity, site — and none of the three maps cleanly onto D365.
Most paths in this library start their posting module from a documented mechanism. This one cannot, and pretending otherwise would be the single most damaging thing this path could do.
The posting rules for this adapter list ten transaction families — purchase receipt, purchase invoice, sales shipment, sales invoice, production issue, production completion, inventory adjustment, quality disposition, intercompany, and EDI-driven shipping and invoicing.
QAD's two strongest verticals produce migrations that look nothing like each other, and a programme that does not identify which one it is running will scope the wrong risks.
On most paths, integration is a workstream. On this one it is close to being the point.
The modules that follow use the same fourteen domains as every path on this site. Their character on this path is shaped by the evidence posture.
Obtain tenant extracts for the organisation model, posting configuration, item and lot genealogy, and the integration inventory. Nothing downstream is trustworthy without them. Run a product-scope workshop. What is core ERP, what is EQMS, what is Cloud EDI, what is DSCP, what is Integration Platform — and who owns each in the target.
QAD Adaptive ERP is a multi-product estate, not a single ERP, and the migration is a multi-platform re-projection rather than a lift. Three things dominate: the domain, entity and site topology decision, which is a blocker and is not settleable from documentation;