Re-platforming QXtend, the Integration Platform and Cloud EDI onto Azure

How QAD's integration estate — QXtend message contracts, low-code orchestration with monitoring and reprocessing, and partner document exchange — is re-expressed on D365 data entities, business events and Azure integration services.

What you will be able to do

Introduction

On most paths integration is one workstream among fourteen. On this one it carries a disproportionate share of the estate's operating behaviour, and it is also the area where the public evidence is strongest — which makes it the module where this path can be most concrete.

Inventory by contract, not by tool

The first mistake available is organising the inventory by which product carries a flow. Flows pass through more than one product, appear in two places, and the tool is about to change anyway.

Choosing the target mechanism

The reference architecture draws the primary line clearly: bulk data through the data management framework; event-like partner, shop-floor and EDI flows through Azure integration and business events. Getting each flow on the right side of that line is most of the design.

Preserving the QXtend contracts

QXtend's public documentation covers the concepts that matter for the target design: the enterprise-application-integration and service-oriented posture, SOAP and XML messaging, QDoc-based exchange, receiver restrictions, WSDL generation and schema versioning.

Rebuilding the operational surface

The Integration Platform provides, as product features: monitoring across flows, queue visibility, error visibility, reprocessing of failed messages, and operator collaboration around exceptions.

Cloud EDI and the partner channel

Covered operationally in the Procurement, Sales & Trade module; here it is the integration architecture that matters.

Analytics and the reporting estate

The reporting side of integration deserves an honest question before any migration: which extracts exist because the business needs data elsewhere, and which exist because reporting on the source was difficult?

Extraction discovery and the cutover dependency

The gap register records this as high severity with low confidence: public sources do not quantify batch or export limits, throttling, or high-volume extraction patterns, and cutover duration and delta strategy cannot be committed until tenant-side extraction tests are complete.

Knowledge check

Summary

The integration estate carries a large share of this migration, and the evidence supporting its design is the strongest on the path. Inventory by contract rather than by tool, capturing delivery guarantees, idempotency rules and failure behaviour alongside payload and trigger.