Inventory the Acumatica integration estate across contract-based REST, DAC-based OData, SOAP, screen-based APIs, import and export scenarios and webhooks, then map each workload onto the right D365 pattern — and find the generic inquiries acting as production interfaces before they are switched off.
The adapter describes the source integration layer as contract-based REST endpoints, DAC-based OData for analytics and read scenarios, SOAP, legacy screen-based APIs, import and export scenarios, push notifications and webhooks. Seven surfaces.
Every integration record needs the same fields, regardless of which surface it sits on.
The mapping error this module exists to prevent is source-technology-to-target-technology. It is neat, it is fast, and it preserves architectural choices that were made for reasons that no longer apply.
They deserve their own unit because they are the characteristic Acumatica integration surprise.
Data Management Framework for bulk. Packages, recurring integration jobs, staging tables with validation, and a proper error path. The design work is sequencing — entities have dependencies and the framework will not infer them.
Authentication. The source uses OAuth and OpenID with client registrations. The target uses Microsoft Entra ID application registrations with service principals. Both are standards-based, which makes the translation conceptually simple and administratively substantial: every consuming application needs a new registration, new consent,…
The migration's own data movement is an integration workload, and the source material gives an explicit hierarchy:
Acumatica's integration estate spans contract-based REST, DAC-based OData, SOAP, screen-based APIs, import and export scenarios, push notifications and webhooks — plus generic inquiries, which are not an integration surface until you find out what reads them.