Integration surfaces, reporting and analytics migration

Maps every Maconomy integration surface — REST services, Workspace/iAccess service layer, file and batch exchanges, direct SQL feeds, Business Objects universes and BPM reporting — to the D365 equivalents: data entities, OData, custom services, business events, dual-write, Azure Integration Services, Power BI and Electronic Reporting.

What you will be able to do

• Inventory every Maconomy integration surface by type, direction, volume and owner
• Classify each surface against the D365 integration pattern best suited to its workload
• Explain why direct SQL consumers cannot be repointed to D365 application tables
• Map the Business Objects reporting estate to Power BI, Electronic Reporting and financial reporting
• Define the effort class for each integration surface instance based on complexity, volume and redesign scope

Introduction

Maconomy exposes its data and processes through several integration surfaces that evolved across the 2.x and 3.x generations: SOAP/WSDL services per module, REST endpoints introduced progressively across releases, the Workspace Client desktop service layer (deprecated from 3.0), iAccess/portal services for self-service users, file and…

Inventorying the source integration estate

The integration inventory is the single most important discovery artefact for this domain. Without it, the programme cannot estimate redesign effort, identify deprecated surfaces, or sequence the build.

Target integration patterns in D365

The Data Management Framework package API is the correct channel for bulk data loads — both during migration and for ongoing high-volume integrations. It supports:

Reporting and analytics migration

Every report, dashboard, inquiry, and scheduled output in the Maconomy estate must be classified by business purpose before a target technology is selected:

Effort classification per integration surface

The table below assigns an effort class per instance of each integration surface. This is not a per-pattern estimate — it is per-integration-instance, because the same pattern (e.g. "file interface") can range from trivial to complex depending on the payload.

Project Operations integration considerations

When the programme selects Project Operations Integrated with ERP, the integration landscape gains a permanent additional layer:

Integration redesign rules

Regardless of the specific source surface, every integration redesign follows these principles:

Discovery items and honest gaps

The following surfaces are not fully specified in the source material and must be confirmed through client discovery:

Knowledge check

Summary

The Maconomy integration estate is broad but follows a discoverable pattern: services (SOAP/REST) for transactional operations, files for batch exchanges, direct SQL for reporting and analytics, and Business Objects for the managed reporting layer. None of these surfaces transfers mechanically to D365.