Replace IDO-based application access, ION middleware and direct SQL consumers with D365 data entities, custom services, business events and Fabric — after establishing what the deployment model actually permits.
Integration on a CloudSuite Industrial programme has an unusual first task: establishing what is technically permitted before establishing what is technically desirable.
The adapter describes the integration layer as three things, and they behave differently enough to warrant separate treatment.
The posture decision is a short investigation with a binary-ish outcome and a large architectural consequence.
The playbook's extraction architecture is a medallion pattern with a specific traceability requirement, and both halves matter.
The Development module produced the classification: every externally consumed IDO is entity-shaped, method-shaped or mixed. This module turns that classification into target contracts.
Where a source application event handler existed to trigger an integration, the target pattern is a business event — and the change is architectural rather than technical.
ION gets its own inventory, its own owners and its own cutover sequencing, and the gap register is unambiguous that this separation is required rather than advisable.
The customisation surfaces give this the only discard disposition in the set, and the reasoning is that no equivalent exists rather than that the requirement is illegitimate.
The reporting classification from the Development module — operational document, statutory output, analytical report, disposable workbench — determines what lands here.
Confirm the extraction posture first. Deployment model, support boundary, administrative surfaces and tenant-specific access rules determine whether SQL-first extraction is even available, and that is an environment question rather than a functional one.