How QAD's sales and purchase documents translate to D365, and why customer release schedules, Cloud EDI partner logic and supplier schedules are a separate re-platforming workstream rather than a data migration.
The document half is straightforward. Sales orders map to sales orders, purchase orders map to purchase orders, customers and vendors reshape into the party-plus-account model, price lists become trade agreements. The concept mapping rates the base document translations as composite with medium confidence, which is a normal migration.
The target separates the party — an organisation or person — from the role it plays. One party can be a customer in one legal entity, a vendor in another, and both in a third. The concept mapping rates both customer and supplier as composite mappings for exactly this reason.
The base sales order maps directly. Header, lines, quantities, dates, prices, delivery terms — all standard.
The purchase side mirrors the sales side, with the mapping rated composite and the note that scheduling, consignment and subcontracting behaviour must be validated before final target design.
Price lists map to trade agreements reasonably cleanly, with agreement journals controlling how prices are created and approved.
This is the half that is not a data migration, and it needs to be scoped as its own body of work.
Three posting families touch this module, and the third is the one to be careful about.
The partner track has its own cutover, running alongside the data cutover with its own rehearsal and its own criteria.
The trade documents map cleanly and the partner estate does not, and the two need separate plans. Reshape customers and vendors into the party-plus-account model while preserving trading-partner identifiers as jointly owned integration reference data.