Microsoft DynamicsFree referencePDF, Excel, Word exportMicrosoft Dynamics 365 Finance and Supply Chain

D365 Finance and Supply Chain Data Migration Load Sequence

Most data migration failures in D365 Finance and Supply Chain are order problems, not mapping problems. A record fails because something it references has not been loaded yet. This reference gives the dependency order used on many implementations so you can build a realistic load plan.

Download:

Step	Phase	Data area	Needs first	Why this position
1	Foundation	Legal entities	Nothing	Almost every table is company specific, so companies must exist before any other load.
2	Foundation	Fiscal calendars and ledger	Legal entities	Posting needs open fiscal periods and a ledger with accounting currency.
3	Foundation	Currencies and exchange rates	Ledger	Foreign currency masters and transactions validate against exchange rate types and rates.
4	Foundation	Main accounts and chart of accounts	Ledger	Referenced by posting profiles, customer and vendor groups and opening balances.
5	Foundation	Financial dimensions and dimension sets	Main accounts	Default dimensions on masters need dimension values to exist.
6	Foundation	Units of measure and conversions	Nothing	Needed before products and trade agreements reference units.
7	Foundation	Terms of payment, delivery terms, modes of delivery	Legal entities	Referenced by customer, vendor and order defaults.
8	Foundation	Customer groups and vendor groups	Main accounts, terms	Required fields on customer and vendor records.
9	Product	Product categories and hierarchy	Nothing	Products are assigned to a category within the procurement or sales hierarchy.
10	Product	Inventory dimension groups and item groups	Legal entities	Assigned at product release time and hard to change after transactions.
11	Product	Products and product masters	Units, categories	Shared products are created before they are released to companies.
12	Product	Released products	Products, dimension groups	Company specific release links the product to item groups and costing settings.
13	Product	Sites, warehouses and locations	Legal entities	Required before any on-hand or order lines can carry inventory dimensions.
14	Parties	Customers V3	Customer groups, terms, dimensions	Customer accounts must exist before open invoices and sales orders.
15	Parties	Vendors V2	Vendor groups, terms, dimensions	Vendor accounts must exist before open invoices and purchase orders.
16	Parties	Customer and vendor bank accounts	Customers, vendors	Banking details attach to parties and are used in payment proposals.
17	Structures	Bills of materials and routes	Released products, resources	Components and operations must exist as released products and resources first.
18	Structures	Trade agreements and price lists	Released products, customers, vendors	Pricing records reference products and accounts.
19	Open items	Open purchase orders and sales orders	Parties, products, warehouses	Open lines reserve supply and demand and need valid dimensions.
20	Open items	On-hand inventory (opening inventory journal)	Products, warehouses, tracking dimensions	Load after orders are understood so reservations can be rebuilt deliberately.
21	Open items	Open customer and vendor balances	Customers, vendors, main accounts	Posted through journals with invoice detail so aging works.
22	Closing	Fixed assets and book values	Asset groups, main accounts	Opening values posted with acquisition and depreciation history as required.
23	Closing	General ledger opening balances	Main accounts, dimensions, open items	Loaded last and reconciled to subledgers so control accounts tie out.

This is a typical dependency order, not a mandatory Microsoft sequence. Your scope, industry and enabled features change it. Always run the Data management dependency view for each entity set in your own environment.

Profile your legacy data before mapping

We can review your source data structure and suggest where load order and mapping risks sit for your migration.

Optional. The tool and every export work without this. No spam.

How to use this load order

Copy the rows into your migration plan and replace the Needs first column with your own entity names. Add an owner, a source system, a row count and a target load date for each step. Run each step through at least three mock loads before cutover. Entities in the Data management workspace expose an execution order and dependencies, which you should use to validate the sequence for your enabled features.

Foundation data goes first and rarely changes.
Product and party masters follow.
Open items and balances go last and are reconciled.

Why the order looks like this

Legal entities and ledger setup come first because nearly all data is company specific and posting requires open periods. Dimensions precede masters because default dimensions are validated on customers, vendors and products. Dimension groups precede released products because they are assigned at release. Open transactions come late because they need valid dimensions and parties, and opening balances are loaded at the end so they can be reconciled against subledger totals.

Using data entities well

Choose entities deliberately. Customers V3 and Vendors V2 carry the party model fields, which means address and contact data rely on the global address book. Test with a small file first, check the staging error log, and fix the source data rather than loosening validations. For large volumes use the recurring import capability or the package API, and consider disabling change tracking on entities during bulk loads where your partner recommends it.

Common mistakes

The most frequent problems are loading products before dimension groups are agreed, loading orders before warehouses exist, and posting opening balances before subledgers, which leaves control accounts blocked or unreconciled.

No mock loads under realistic volume.
Not freezing master data changes during cutover.
Forgetting number sequences that must be continuous for imported records.
Loading balances without keeping a reconciliation to the legacy trial balance.

Frequently Asked Questions

Which D365 data should be loaded first?

Legal entities, fiscal calendars and ledger setup come first, followed by currencies, main accounts and financial dimensions. Everything else references these. Without them, customer, vendor, product and transaction loads fail on validation.

Should opening balances be loaded before or after open invoices?

Typically open items are loaded through subledger journals first, then the general ledger opening balance is posted and reconciled so control account amounts tie to the subledgers. Your finance team and partner should confirm the approach for your design.

How do I find the dependencies for a data entity?

In the Data management workspace, use the data entity list and the execution unit and sequence information shown when you build a data project. These show which entities should run before others. Use them to confirm the order for your own scope.

How many mock loads should we run?

At least three on a typical project: one to find mapping errors, one to fix and time the sequence, and a full dress rehearsal that mirrors the cutover plan including reconciliation. Large or complex migrations often need more.

If you are planning a migration from SyteLine, BAAN, LN or another ERP, Netray can help profile source data and prepare mappings before the first mock load.

Talk to an Expert Explore More Free Tools

Related Tools

Microsoft Dynamics

More Microsoft Dynamics tools

See all

Back to All Tools