What happens to my open POs at cutover?

Open purchase orders are migrated as open transactions into Dynamics 365 using the Data Management Framework. You import remaining quantities, not original quantities. Partially received POs must reflect what's already been received to avoid double-posting. Imported PO lines via Purchase order lines V2 can also ignore your normal system line increment unless you send line numbers explicitly — important when EDI acknowledgements expect stable references.

How do EDI trading partners handle the switch to Dynamics 365?

They don't handle it automatically — you handle it for them. D365 has no native EDI support, so you must rebuild EDI maps using middleware or an ISV. Each trading partner needs 60–90 days advance notice, updated connection endpoints, and a testing window. Run parallel EDI feeds from both old and new systems during the transition period.

How do I migrate customer pricing rules to Dynamics 365?

Legacy pricing must be mapped into D365 Trade Agreements or Unified Pricing Management. Extract every active price rule, classify by type (customer-specific, volume-tier, contract, promotional), and import using data entities like 'Open sales price journal lines V2.' Do not prefill final line prices if you expect D365 to reevaluate trade agreements — the engine will not recalculate prefilled values. This is consistently the most underestimated workstream in distribution migrations.

How long does a distribution ERP migration to Dynamics 365 take?

A well-structured migration for a mid-market distributor typically runs 6–12 months from assessment through go-live. The phased approach — finance first, then inventory/EDI, then order management — spreads risk and keeps order velocity uninterrupted during transition. EDI re-onboarding alone needs at least 90 days of lead time.

Distribution ERP Migration to Dynamics 365 Without Disrupting Orders

A distribution ERP migration to Microsoft Dynamics 365 is not a software project. It is an order velocity preservation exercise. If EDI feeds break, customer pricing resolves wrong, or open sales orders vanish during cutover, the damage is measured in lost shipments, chargeback penalties, and trading partner trust that takes months to rebuild.

When you move from a legacy system — whether that is an aging AS/400 setup, Dynamics GP, or a disjointed mix of accounting software and warehouse management — you are fundamentally rewiring the supply chain. You are not just moving tables; you are translating decades of hard-coded business logic into a highly relational transactional engine.

This guide covers the specific data complexities, technical constraints, and phased cutover patterns that distribution and wholesale companies face when moving to Dynamics 365 — whether that is F&SCM (Finance & Supply Chain Management) or Business Central. It is written from direct experience migrating complex distribution ERP environments, not from a generic project management template.

If you want the broader ERP migration framework first, start with The Ultimate ERP Data Migration Checklist.

Why Wholesale Distributors Are Moving to Dynamics 365

The migration wave is structural, not speculative. Several forces are converging.

Legacy system end-of-life pressure. Dynamics GP is approaching end of life. Every version of Dynamics AX (2009 through 2012 R3) has exited Microsoft's support lifecycle — no security patches, no compliance updates, no technical assistance when something breaks. Dynamics NAV users face the same trajectory. The cost of maintaining these systems now outpaces the cost of migrating.

Real-time inventory has become a competitive requirement. Distribution Strategy Group reported in March 2026 that distributors are carrying more stock and prioritizing forecasting, while only 31% of respondents said they had high confidence in their inventory data (distributionstrategy.com). Distributors operating across multiple warehouses, drop-ship arrangements, and 3PL partners cannot wait for nightly batch updates. D365 Supply Chain Management connects procurement, inventory, and fulfillment to the financial ledger in real time, eliminating the reconciliation delays that legacy batch systems create.

Multi-channel order complexity keeps growing. Distributors now process orders through EDI, B2B portals, marketplaces (Amazon, eBay), Shopify B2B storefronts, and inside sales — often simultaneously. A modern ERP must serve as the single system of record across all of them.

AI-driven demand planning. D365's 2026 releases introduce AI agents that go beyond basic Copilot features. For distributors, that means demand sensing and forecasting built on actual SKU-customer history, not spreadsheet guesswork. But that only works if you migrate sufficient historical data.

Distribution ERP migration is harder than a generic ERP migration because the data carries executable business logic: customer pricing matrices with quantity breaks and contract rules, vendor cost structures with landed cost and rebate calculations, warehouse detail down to bin and license plate, and open document linkages — sales orders tied to purchase orders tied to inventory allocations — that cannot be recreated casually (learn.microsoft.com). A single sales order in a legacy system might be a flat record. In Dynamics 365, that same order touches the customer record, inventory allocation, warehouse bin locations, financial dimensions, and the general ledger. Migrate any of those objects out of sequence, and you break referential integrity across the entire ERP.

If you want the scoping framework for what belongs in the new system, read What Data Should You Actually Migrate to Your New ERP?. For distributors, the answer is almost never "everything."

The EDI Trap: Why Your Trading Partner Maps Won't Migrate

This is where distribution migrations diverge sharply from every other industry. Dynamics 365 does not natively support EDI translation — not X12, not EDIFACT, not any standard B2B document format. Your legacy EDI maps, translation rules, and trading partner configurations cannot be lifted and shifted into D365. They must be rebuilt.

Celigo's Dynamics 365 EDI documentation frames the gap explicitly: D365 lacks native X12 and EDIFACT support, so organizations must use external EDI systems or integration platforms to translate documents, validate trading partner requirements, and create ERP transactions (celigo.com). The ERP handles core business processes by design; dedicated systems handle EDI complexity.

Most distributors have 20–200 active EDI trading partners. Each partner has specific document requirements, field mappings, timing rules, and compliance expectations. When you switch ERPs, every one of those relationships needs to be re-validated.

Your options for D365 EDI integration

Approach	Best for	Trade-off
Embedded ISV (e.g., STAEDEAN EDI Studio, Insight Works)	Distributors wanting EDI inside the D365 UI	Limited scalability for complex multi-partner setups
Managed EDI / VAN (e.g., SPS Commerce, Transalis)	Companies without in-house EDI expertise	Ongoing service fees; less direct control
iPaaS middleware (e.g., Celigo, Cleo, Boomi)	High-volume distributors needing API-first automation	Requires integration skills to configure and maintain
In-house custom build	Large orgs with dedicated integration teams	Highest maintenance burden; hardest to scale

Danger

Do not wait until UAT to test EDI. EDI trading partners — especially big-box retailers — dictate their own testing schedules. If you need to recertify an ASN (856) with Walmart or Target, you are on their timeline. Start EDI re-onboarding at least 90 days before your ERP cutover.

The practical sequence: select your EDI integration approach during the design phase, begin partner-by-partner testing at least 90 days out, and run parallel EDI feeds (old and new) for at least two weeks before cutover. If your plan says "we'll migrate EDI later," assume the cutover plan is incomplete. Manual order entry may keep a few customers alive for a day, but ASN, invoice, routing, and 3PL event continuity will not survive on manual heroics.

Note that Microsoft's OData integration surface is synchronous, relatively low-volume, and subject to throttling (learn.microsoft.com). That is fine for some integrations. It is not how you want to discover during cutover weekend that your retail partner's 850, 855, 856, and 810 flows still live in a separate map layer.

Migrating Pricing Matrices and Trade Agreements

Pricing is where distribution migrations consistently underestimate effort by 3–5x. A typical distributor does not have a single price list. They have:

Customer-specific negotiated prices (one price for Customer A, a different price for Customer B, on the same SKU)
Volume-tiered pricing (buy 100 units, get a lower unit price)
Contract pricing with date ranges and exclusivity rules
Promotional pricing with start/end dates
Vendor rebate structures that affect margin calculations
Price group hierarchies (customer groups, item groups, combination rules)

In legacy systems, these rules are often held together by custom code, auxiliary SQL databases, or hardcoded logic that nobody has documented in years.

How D365 handles pricing

Dynamics 365 handles pricing through Trade Agreements — the system's mechanism for managing sales prices, purchase prices, line discounts, multiline discounts, and total discounts at the customer, group, or global level. Trade agreements use a priority hierarchy: Table (specific customer) → Group → All.

Microsoft is also rolling out Unified Pricing Management (UPM), a newer framework that centralizes pricing rules and adds price attribute support. UPM migration is structured across Commerce versions 10.0.46 through 10.0.48, with price adjustments migration support arriving in version 10.0.47 (learn.microsoft.com). If you are implementing D365 Commerce alongside SCM, evaluate whether UPM is the right target for your pricing rules versus traditional trade agreements.

The technical reality

Standard D365 data entities do not support the direct export of posted trade agreement lines. You must first convert posted lines to unposted lines (using the "Generate to journal" function), then export via the Data Management Framework using entities like "Open sales price journal lines V2" or "Open purchase price journal lines V2." Importing works the same way in reverse — load pricing data into open trade agreement journals, validate, then post.

For distributors with 10,000+ active price lines across customer-item combinations, this is not a weekend spreadsheet exercise. It requires scripted extraction, automated transformation, and multiple validation rounds.

Two edge cases catch teams constantly:

Prefilled prices bypass the pricing engine. If imported sales or purchase lines already contain price or discount values, trade agreements are not reevaluated on those imported lines. If the goal is to let D365 calculate contract pricing, do not prefill final prices and assume the engine will fix it. It will not (learn.microsoft.com).
Variant explosion creates redundant records. Microsoft warns against exploding trade agreements for every product variant if only one dimension truly affects price — that creates large numbers of redundant records that slow the system and complicate maintenance (learn.microsoft.com).

Tip

Enter Trade Agreements with a strictly defined effective date to avoid conflicts with historical data. This ensures price calculations resolve correctly from day one. Validate pricing with real order scenarios — customer contracts, expired promos, volume tiers, alternate UOMs — not just item-master spot checks.

For a deeper look at why the standard VAR approach ("here's a spreadsheet template, fill it in") breaks down with complex pricing data, see Why ERP Migrations Fail at the Data Layer: 9 Core Patterns.

Open Order Cutover: Handling Sales and Purchase Orders

At any given moment, a mid-market distributor might have 500–5,000 open sales orders and purchase orders in various states: confirmed, partially shipped, backordered, or awaiting receipt. These orders span the cutover — they existed in the old system and must continue in the new one without losing line-level detail, shipment history, or customer commitments.

Microsoft's own guidance defines migration data as "master data such as customers, products, and vendors, or open transactions such as open sales orders, open purchase orders, stock on hand, and open balances." Closed historical transactions should not be migrated into the production ERP (learn.microsoft.com).

Warning

Do not migrate historical closed transactions into Dynamics 365. Microsoft explicitly advises against using the ERP as a data warehouse. Migrating 10 years of closed sales orders bloats your database, increases storage costs, and slows system performance. Migrate only master data, open transactions, and necessary GL balances.

The volume-based decision

A practical rule from experienced D365 implementers: if you have fewer than ~100 open sales orders, hand-key them during the cutover weekend. It sounds primitive, but it eliminates mapping errors and can be done by a small team in a few hours (erpsoftwareblog.com).

If you have 1,000+ open orders, build an automated import ahead of time and test it repeatedly before go-live. The import should be scripted, version-controlled, and rehearsed in at least two full-scale dress rehearsals. The go-live weekend execution should be a button push, not a scramble.

The middle ground — 100 to 1,000 orders — depends on complexity. If you have changed your item numbering structure, even 200 orders can be painful to import because every line requires item number translation. If your SKUs have not changed, 500 orders can be straightforward. For orders that carry contract pricing, allocations, direct-delivery links, or EDI acknowledgements, do not treat them as simple just because the count is low.

For high-volume automated imports, use DMF entities like Sales order headers V2 and Sales order lines V2. Headers must exist before lines.

The minimum data shape we like to see before the first rehearsal:

legacy_order_no,line_no,status,qty_ordered,qty_shipped,qty_open,warehouse,requested_ship_date,pricing_ref,edi_partner

A solid distributor cutover does four things: closes everything that can be fully shipped and invoiced before the freeze, migrates only the remaining open quantity and financial state, preserves the legacy order number as an external reference, and separates standard, backordered, and direct-delivery logic instead of forcing one import path.

Partial shipments, backorders, and direct deliveries

Partially fulfilled orders are the hardest edge case. The new system must reflect the correct remaining quantity, not the original order quantity. If a legacy order for 1,000 units has already shipped 400 units, load the order with the remaining 600 units rather than migrating the original quantity and trying to spoof a historical fulfillment record. Get this wrong and your warehouse ships duplicate product or your customer receives an invoice for goods they already received.

Direct deliveries deserve separate treatment. In Supply Chain Management, direct delivery creates an explicit link between the sales line and corresponding purchase line. If a direct-delivery sales line is partially delivered, you cannot simply delete and recreate it (learn.microsoft.com). Another quiet gotcha: imported PO lines via Purchase order lines V2 can ignore your normal system line increment unless you send line numbers explicitly. Those details matter when customers, vendors, and EDI acknowledgements all expect stable line references.

Danger

Freeze order entry 24–48 hours before cutover. New orders created during the migration window are the #1 source of data discrepancies. Communicate the freeze to your sales team and customers well in advance. Process urgent orders manually with a documented workaround.

Inventory Costing and Multi-Warehouse Data

Inventory is the balance sheet for a distributor. Getting cost data wrong means your financial statements are wrong from day one.

Migrating cost data

Microsoft recommends using the Data Management Framework with specific entities for cost migration (learn.microsoft.com):

Pending item prices V2 — for raw material and distributed goods costs
Pending route cost category unit costs — for resource costs by cost category
Costing sheet node calculation factors V2 — for indirect costs

The sequence matters critically: load costs into a costing version, validate the migrated data, then activate the costing version prices. If you reverse this order — loading on-hand inventory before costs are active — Dynamics 365 records the inventory at zero cost, creating massive variance issues in your general ledger when items are eventually sold.

For distributors using standard costing, every item variant must have an active cost price before cutover. Items with product dimensions (size, color, configuration) each need a separate cost record. For those on FIFO or weighted average, the complexity shifts to ensuring the opening inventory transactions carry the correct physical and financial values.

Multi-warehouse and bin-level detail

Distributors with multiple warehouses need on-hand inventory migrated at the warehouse + location (bin) level. D365's warehouse management module supports license plate tracking, zone-based put-away, and wave picking — but none of that works if your opening balances land at the wrong location.

Reservation and picking behavior depend on the storage dimension hierarchy. Microsoft documents site, warehouse, inventory status, location, and license plate as a typical warehouse reservation hierarchy (learn.microsoft.com). "We have 10 units" is not enough. You need to know where those 10 units live, whether they are reservable, and whether the scanner workflow can actually pick them.

Warehouse cutover is never just a data load. Scanner clients and handhelds must be repointed. The Warehouse Management mobile app can be configured manually, by file, or by QR code — and some devices need explicit intent-output configuration (learn.microsoft.com). If you are changing warehouses, zones, or license-plate behavior at the same time, rehearse the devices with real warehouse operators, not only with superusers.

3PL and Warehouse Integration Handover

If you use a third-party logistics provider, your 3PL communicates with your ERP via EDI or API. When the ERP changes, those feeds must be rebuilt and re-tested. This includes:

Inbound ASN (Advance Ship Notice) feeds for receiving
Outbound shipment confirmation feeds
Inventory adjustment sync
Returns processing workflows

You must extract the inventory snapshot from the legacy system, reconcile it against the physical 3PL count, load the initial balances into Dynamics 365, and immediately initiate the new connection.

Treat 3PL integration as a sub-project of your warehousing phase with its own testing timeline — not an afterthought. Scanner configuration, label format changes, and API endpoint updates are easy to overlook and hard to fix under cutover pressure.

If you are migrating off an on-premise architecture and fighting SSIS or connector bottlenecks for high-volume data loads, see Migrating Dynamics 365 On-Premise to Cloud: Escaping the SSIS Bottleneck with JSONata.

D365's demand planning and AI-driven forecasting capabilities need historical data to function. If you cut over with zero sales history, your demand sensing produces garbage output for months.

Migrate at least 24 months of sales history at the SKU-customer level — not as transactional detail inside the ERP, but as structured summary data that feeds the forecasting engine. Microsoft provides the Historical external demand entity specifically for this purpose, and Demand Planning can ingest data from Supply Chain Management, CSV/Excel, or Azure Data Lake (learn.microsoft.com). Forecast models can combine historical sales with up to five signal inputs such as weather or inflation.

Without this historical context, the ERP will not generate accurate planned purchase orders, leaving your procurement team flying blind for the first quarter post-go-live. Planners can still function, but the system's early forecast outputs will be weak and users will fall back to spreadsheets — which defeats the purpose of the migration.

The Phased Rollout Pattern for Distributors

A big-bang cutover — every module, every warehouse, every channel at once — is high risk for distributors with continuous order flow. If the order-to-cash cycle breaks, revenue stops entirely. The pattern that minimizes operational disruption:

Phase 1: Finance + Master Data + Procurement

Chart of accounts, GL balances, AP/AR open balances
Customer master, vendor master, item master
Purchase order processing and vendor management
Demand history for forecasting
Goal: Go live on finance first so month-end close works in D365

Phase 2: Inventory + Warehousing + EDI Cutover

On-hand inventory at warehouse/bin level
Cost data activation (before inventory loads)
Warehouse management configuration and scanner deployment
EDI trading partner switchover (after 90-day re-onboarding)
3PL integration handover
Goal: Tightest cutover window — plan for a long weekend

Phase 3: Order Management + Customer-Facing Portals

Open sales order migration
B2B portal integration (Shopify B2B, marketplace connectors)
Customer-facing order status and tracking
Multi-channel commerce layer rebuild
Goal: Can be staggered by channel

This sequence lets you validate financial reporting before adding operational complexity. Phase 2 carries the most risk and deserves the most rehearsal time. Phase 3 can be staggered — bring one sales channel online at a time rather than all at once. If a B2B portal integration fails in Phase 3, your EDI and warehouse teams can still process wholesale orders manually or via batch while the API is fixed.

Tip

Run at least one full cutover rehearsal with real open orders, real scanners, one direct-delivery scenario, and real partner timing. A clean data import in a test environment is not a cutover test.

For distributors managing Shopify B2B alongside D365, note that the native Business Central Shopify connector only supports one Shopify store per Business Central company. Multi-store or mixed B2B/B2C architectures require a custom integration layer — plan and budget for that separately.

Can you migrate one warehouse at a time? Sometimes. It works best when warehouses are operationally separable and channel routing can tolerate split visibility. It works badly when customers see pooled inventory across branches, when EDI partners expect one sender/receiver model, or when ATP is shared across sites. Treat "one warehouse at a time" as a design decision, not a simplification.

How ClonePartner Handles Distribution ERP Migrations

This is the point where many ERP projects stall: the implementation partner owns configuration, but nobody truly owns the data layer and integration cutover. Standard implementation partners are built to configure software, not to move highly relational, high-volume distribution data. When they hand off the data migration to your internal team with a spreadsheet template, they introduce the single largest risk factor to your go-live timeline.

ClonePartner is an engineer-led service that treats data migration as a distinct, high-precision engineering discipline. With over 1,200 successful migrations completed, we focus on the areas where standard implementation partners consistently fall short:

Pricing matrix extraction and mapping: We script the extraction of legacy pricing rules and map them directly into D365 Trade Agreement journals — no manual Excel manipulation for thousands of customer-item price lines.
Open order migration with referential integrity: We ensure open sales orders remain correctly linked to their corresponding purchase orders, inventory allocations, and partial shipment records through cutover.
High-volume automated cutover: Our migration scripts handle thousands of open orders in a single cutover window, validated against source system totals before go-live.
EDI continuity planning: We work alongside your EDI provider to ensure the integration layer is tested and live before the ERP cutover, not after.

Distributors do not go live on master data. They go live on exceptions: EDI acknowledgements, contract prices, partially shipped lines, scanner behavior, and inventory promises across channels. Design those workstreams early, rehearse them like production, and a distribution ERP migration to Dynamics 365 can be boring in the best possible way.