Translating APIs, web services, Dataverse coupling, and automation into data entities, OData, business events, dual-write, and Azure Integration Services
How every Business Central integration surface — standard and custom API pages, OData and SOAP web services, configuration packages, job queue entries, Power Automate flows, Dataverse virtual tables, and file/EDI feeds — maps to D365 data entities, OData, custom services, business events, dual-write, Logic Apps, and the batch framework; with an effort class per integration instance, disposition codes, and ownership assignments.
What you will be able to do
Classify every Business Central integration surface and name its D365 replacement
Explain when to use OData versus DMF versus business events versus dual-write for a given pattern
State that existing BC–Dataverse couplings and mappings do not transfer to D365 F&SCM without redesign
Describe the effort-class model that sizes each integration instance for delivery planning
Identify the ownership model: who triages, who rebuilds, and who signs off each surface
Introduction
Business Central and Dynamics NAV estates accumulate integration surfaces over years of operation — standard APIs, custom API pages, legacy SOAP and OData web services, scheduled jobs, Power Automate flows, Dataverse couplings, partner EDI, file exchanges, and configuration packages.
The integration inventory
Before any redesign begins, the programme must produce a complete integration register. For every interface, capture:
Target integration surfaces in D365 F&SCM
D365 Finance and Supply Chain Management provides a different integration architecture. The principal surfaces are:
Mapping BC surfaces to D365 targets
Business Central's v2.0 REST API exposes standard API pages (/api/v2.0/customers, /api/v2.0/salesOrders, etc.) and custom API pages defined in AL. Each returns company-scoped JSON using BC field names and navigation properties.
The effort-class model
Each integration instance receives an effort class based on complexity, not surface type:
Disposition decision tree
```text Is the interface still active and business-critical? No → RETIRE (document and decommission) Yes → continue
Ownership and governance
Integration transitions fail when ownership is unclear. Define for every instance:
False-parity risks from shared Microsoft vocabulary
Business Central and D365 F&SCM share Microsoft branding, Azure AD, Power Platform, and Dataverse. This creates a false sense of compatibility:
Knowledge check
Summary
Every Business Central integration surface requires an explicit disposition — retire, replace with standard, redesign, or rebuild. The effort scales with instance count, not pattern count, and shared Microsoft vocabulary creates false-parity risks that only surface during integration testing if not identified during discovery.