How a Top North American Commercial Vehicle Manufacturer Connected D365 F&O with Legacy Systems Without Disrupting Operations
What happens when a global manufacturing giant needs to modernize its operations without grinding critical business processes to a halt? The answer is not a rip-and-replace approach – it is a carefully engineered integration strategy that lets modern and legacy systems co-exist, communicate, and complement each other.
Are you planning an ERP upgrade but worried about what happens to the legacy systems your operations depend on? If so, this is for you.
One of North America’s leading commercial vehicle manufacturers faced exactly this dilemma. With decades of investment in legacy financial and warehouse management systems, a hard cutover to a new ERP was not an option. Yet the need for a modern, scalable platform was undeniable. Their solution? Introduce Microsoft Dynamics 365 Finance & Operations (D365 F&O) as the new operational backbone – while keeping their legacy systems in play for financial control – and build robust, bi-directional integrations to bridge both worlds.
At CloudFronts, we had the privilege of architecting and implementing those integrations. This blog walks you through three core data flows: Spot Purchase Orders, Advance Shipment Notices (ASN), and Goods Receipt Notes (GRN) – and what it really takes to make a modern ERP talk to a legacy system without missing a beat.
Why Replace When You Can Integrate?
Legacy systems in large manufacturers are not just old software. They carry years of financial logic, vendor relationships, and compliance configurations that are too risky to discard overnight. Replacing them introduces enormous operational and compliance risk. Doing nothing, however, is not an option either.
The approach our client took – and one we increasingly recommend for manufacturers, distributors, and large enterprises – is a co-existence model:
- a. D365 F&O handles modern purchasing, warehouse, and receiving operations
- b. The legacy system retains financial control and warehouse management authority
- c. Azure Integration Services (Logic Apps, Blob Storage, Table Storage) acts as the middleware — orchestrating, transforming, and routing data between the two systems automatically
This means the business gets the agility of a modern ERP on day one, without putting financial operations at risk. The three integrations do the heavy lifting.
Architecture at a Glance
Before diving into each integration, it helps to understand the overall data flow pattern and the Azure services involved:
| Component | Role |
| D365 F&O | System of record for purchasing and receiving operations |
| Legacy System | Retains financial control, inventory management authority |
| Azure Logic Apps | Parent-child middleware: orchestrates, transforms, and routes data |
| Azure Blob Storage | Checkpoint management for reliable incremental processing |
| Azure Table Storage | Full execution logs for traceability, audit, and failure replay |
The three integrations work in concert:
- a. Spot Purchase Orders flow from D365 F&O → Legacy System (outbound)
- b. Advance Shipment Notices (ASN) flow from Legacy System → D365 F&O (inbound)
- c. Goods Receipt Notes (GRN) are created in D365 F&O via mobile app and transmitted to the Legacy System (outbound)
Integration 1: Spot Purchase Orders — D365 F&O to Legacy
Business Problem
A Spot Purchase Order is an ad-hoc purchase order raised outside of long-term contracts — often for urgent material procurement. Spot POs are created and managed in D365 F&O by procurement teams. However, the legacy system is the system of financial record, meaning every Spot PO created in D365 must be reflected in the legacy system for financial commitment tracking and vendor payment processing.
Without integration, this would require manual re-entry – a process prone to error, delay, and duplication.
How the Integration Works
Parent Logic App – Spot PO Orchestrator
The primary Logic App runs on a scheduled recurrence and uses a checkpoint mechanism stored in Azure Blob Storage to fetch only incremental changes – purchase orders created or modified since the last successful run. This ensures efficiency and prevents reprocessing of already-handled records.
The workflow determines the operation type required for each PO:
- 1. Create: A new Spot PO line needs to be registered in the legacy system
- 2. Update: A quantity or delivery date change has been made to an existing PO line
- 3. Cancel Line: A specific line on the PO has been cancelled
- 4. Cancel Header: The entire purchase order has been cancelled
For each scenario, the Logic App fetches enriched data from multiple D365 F&O OData entities and constructs a structured JSON payload tailored for the legacy system’s API.
| ⚙ Tech Note: OData Entities Used PurchaseOrderHeaders, PurchaseOrderLinesV2, PurchaseLineDataEntities, WHSPurchLines, StatusCustomDatas |
Child Logic App – SendRequest (Reusable)
Rather than embedding API communication logic directly in the orchestrator, we separated it into a reusable child Logic App. This child app receives the constructed payload, retrieves an OAuth 2.0 Bearer token, and executes the HTTP POST call to the legacy system’s API endpoint.
This modular design pays dividends during maintenance: any change to authentication logic or API communication is made once in the child app and automatically applies to all parent integrations.
Failed Record Handler
Every enterprise integration needs robust failure recovery. When an API call fails:
- Failure details are logged to Azure Table Storage for full traceability
- An automated email notification is sent via SMTP to alert the support team
- A separate Process-FailedRecord Logic App enables replay and reprocessing without manual re-entry
Sample Payload – Spot PO Create
| Sample JSON Payload: { “userId”: “JSMITH”, “order”: “456789”, // Last 6 digits of D365 PO number “vendor”: “VEND001”, “receiptLoc”: “SITE01”, “vendorOvrdCd”: “14”, “lineItems”: [{ “orderLine”: “001”, “item”: “ITEM001”, “openQty”: 10, “deliveryDate”: “061526”, // MMddyy format for legacy compatibility “comment”: “MPSSYS order – JSMITH” }] } } |
| ✓ Business Impact: Zero manual re-entry of purchase orders between systems. Every Spot PO created or changed in D365 F&O is automatically reflected in the legacy system within minutes. |
Integration 2: Advance Shipment Notices — Legacy to D365 F&O
Business Problem
An Advance Shipment Notice (ASN) is a notification sent by the legacy WMS to the receiving system, informing it of an incoming shipment before it physically arrives. D365 F&O needs to receive ASNs to create Inbound Load Headers and Load Lines – enabling warehouse teams to prepare for receiving.
Without this integration, receiving teams in D365 would be blind to incoming shipments until trucks arrived at the dock – eliminating any opportunity for advance dock scheduling, labor planning, or inventory pre-positioning.
The Hybrid Integration Approach
This integration presented an interesting technical challenge: the standard D365 F&O Inbound ASN V5 API supports a well-defined XML format, but the business required additional fields beyond what the standard API supports.
The solution was a two-step Hybrid ASN Integration approach:
- Insert via Standard ASN V5 API: The legacy system sends an XML payload to D365’s standard connector endpoint using the Inbound ASN V5 entity. This creates the Inbound Load Header and Load Lines.
- Enrich via Custom Header & Line APIs: Immediately after insertion, PATCH calls are made to custom Header and Line APIs to populate the additional business-specific fields that the standard XML does not support.
| ⚙ Tech Note: API Endpoint Pattern Insert: POST {{BASE_URL}}/api/connector/enqueue/{{ACTIVITY_ID}}?entity=Inbound ASN V5 Enrich: PATCH on InboundLoadHeaders and WHSASNWorkData |
Smart Insert vs. Update Determination
To handle scenarios where an ASN might be re-sent for corrections or resynchronization, the integration includes a check before processing:
- a. A GET call is made to the Header API using the LoadId
- b. If the LoadId already exists in D365, the XML insert is skipped and only the PATCH updates are applied
- c. If the LoadId is new, the full insert-then-update flow executes
This idempotent design prevents duplicate inbound loads from being created when the legacy system re-sends an ASN.
One nuance worth noting: in D365’s standard ASN structure, the LoadId, ShipmentId, and LicensePlateNumber must carry the same value. The legacy system’s outbound ASN payload is configured to honour this requirement – ensuring clean data entry into D365’s warehouse management layer.
| ✓ Business Impact: Warehouse teams now receive advance visibility of incoming shipments directly in D365 F&O, enabling proactive dock planning and reducing receiving processing time. |
Integration 3: Goods Receipt Notes: D365 F&O to Legacy
Business Problem
A Goods Receipt Note (GRN) is the formal record that goods have been physically received and inspected. Receiving staff use a mobile application on the warehouse floor to record receipts directly in D365 F&O. The challenge: the legacy system needs to know about every receipt to complete the financial transaction – vendor payment, inventory value posting, and purchase order closure all depend on it.
The GRN integration closes this loop automatically, eliminating what would otherwise be a daily manual upload task.
How the Integration Works
Incremental Polling with Checkpoint Management
The GRN Logic App runs on a one-minute recurrence, polling D365 F&O’s WarehouseWorkLines entity for newly created warehouse Pick work transactions. Using a checkpoint stored in Azure Blob Storage, it fetches only records created after the last successful run.
| ⚙ Tech Note: OData Filter $filter=CreatedDateTime1 ge {Checkpoint} and WarehouseWorkType eq ‘Pick’ |
Data Transformation and Vendor Enrichment
Raw warehouse work line data from D365 requires transformation before the legacy WMS can understand it:
- a. Purchase order numbers are derived from the SourceOrderNumber field
- b. Line numbers are zero-padded to match legacy format expectations
- c. A vendor account lookup is performed against the PurchaseOrderHeaders entity to construct the LPNID – a unique identifier used by the legacy WMS for receipt matching
- d. Default user handling is applied for records where the originating user is not captured
This enrichment step is critical: it bridges the semantic model of D365’s warehouse management layer with the data contract expected by the legacy WMS API.
Payload Persistence Before Transmission
Every transformed GRN payload is written to Azure Table Storage with a composite RowKey before the outbound API call is made. This serves two purposes:
- Traceability: a complete audit trail of every receipt transmitted
- Recovery: if the outbound call fails, the persisted payload can be retried without needing to re-query Dynamics 365
Outbound Transmission via Shared Child Logic App
Like the Spot PO integration, GRN outbound communication is handled by the same reusable child Logic App- enforcing consistency in authentication, logging, and error handling across all outbound integrations. The endpoint, payload, and operation type are passed dynamically, keeping the child app truly generic.
| ✓ Business Impact: Receipt data reaches the legacy system within minutes of being recorded on the warehouse floor. No manual uploads. No end-of-day batch files. Vendor payments and PO closures happen faster and with full accuracy. |
Lessons Learned: What Makes ERP-to-Legacy Integration Work
Having implemented all three integrations, we have distilled a set of architectural principles that made the difference between a fragile point-to-point connection and a robust, production-grade solution:
1. Checkpoint-Based Incremental Processing
Never query for all data every time. Using a persisted timestamp checkpoint stored in Azure Blob Storage ensures the integration fetches only what has changed — keeping API load low and processing time short regardless of data volume growth.
2. Modular Parent-Child Architecture
Separating orchestration (parent) from communication (child) is essential for maintainability at scale. When the legacy system’s API authentication mechanism changes, you update one child Logic App, not three parent integrations.
3. Idempotent Design
Every integration must be safe to run multiple times without creating duplicates. The Insert vs. Update check in the ASN integration, and the checkpoint advancement logic in Spot PO and GRN, are examples of idempotency built in from the start – not bolted on afterward.
4. Failure Visibility and Recovery
Silent failures are the enemy of operational trust. Every integration logs failures to Azure Table Storage, sends email alerts, and provides a replay mechanism. Support teams always know when something went wrong – and have a clear path to fix it.
5. Data Enrichment at the Integration Layer
When the source system’s data model does not match the target system’s requirements, the integration layer must bridge that gap. Whether it is vendor lookups, date format conversions, or derived field calculations, the Logic Apps handle transformation so that neither D365 F&O nor the legacy system needs to be modified.
The Bottom Line
You do not have to choose between modernizing your ERP and protecting your operations. With the right integration architecture, a modern platform and a legacy system can co-exist – each doing what it does best, with data moving reliably between them.
By implementing Spot PO, ASN, and GRN integrations on Azure Logic Apps and D365 F&O, this client achieved:
- a. Real-time purchase order synchronization between their new and legacy systems
- b. Automated advance shipment visibility for warehouse teams in D365 F&O
- c. Seamless goods receipt recording from mobile devices to legacy WMS – without manual re-entry
- d. Full audit trails and failure recovery mechanisms that satisfy both IT and finance compliance requirements
Take a moment to look at your own environment. Are there manual handoffs between your ERP and other systems? Data that gets re-entered by hand? Reports that depend on someone remembering to run a process? Those are the gaps an integration strategy can close.
| Ready to connect your modern ERP with your legacy systems? Reach out to CloudFronts to explore what a connected ERP environment could look like for your business. |
Connect with CloudFronts to get started at transform@cloudfonts.com
