# D365 Finance and Supply Chain Data Migration Load Sequence > Source: https://netray.co/tools/d365-fno-data-migration-load-sequence-reference > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Dependency-ordered list of the master, setup and transactional data areas to load when migrating to D365 F&O. ## Category microsoft-dynamics ## Erp Microsoft Dynamics 365 Finance and Supply Chain ## Audience - D365 F&O consultant - Data migration lead - Project manager ## Tool **Kind:** worksheet **Mode:** reference **Columns:** #### Step **Key:** step **Type:** number #### Phase **Key:** phase **Type:** text #### Data area **Key:** area **Type:** text #### Needs first **Key:** depends **Type:** text #### Why this position **Key:** why **Type:** text **Rows:** #### Foundation **Step:** 1 **Area:** Legal entities **Depends:** Nothing **Why:** Almost every table is company specific, so companies must exist before any other load. #### Foundation **Step:** 2 **Area:** Fiscal calendars and ledger **Depends:** Legal entities **Why:** Posting needs open fiscal periods and a ledger with accounting currency. #### Foundation **Step:** 3 **Area:** Currencies and exchange rates **Depends:** Ledger **Why:** Foreign currency masters and transactions validate against exchange rate types and rates. #### Foundation **Step:** 4 **Area:** Main accounts and chart of accounts **Depends:** Ledger **Why:** Referenced by posting profiles, customer and vendor groups and opening balances. #### Foundation **Step:** 5 **Area:** Financial dimensions and dimension sets **Depends:** Main accounts **Why:** Default dimensions on masters need dimension values to exist. #### Foundation **Step:** 6 **Area:** Units of measure and conversions **Depends:** Nothing **Why:** Needed before products and trade agreements reference units. #### Foundation **Step:** 7 **Area:** Terms of payment, delivery terms, modes of delivery **Depends:** Legal entities **Why:** Referenced by customer, vendor and order defaults. #### Foundation **Step:** 8 **Area:** Customer groups and vendor groups **Depends:** Main accounts, terms **Why:** Required fields on customer and vendor records. #### Product **Step:** 9 **Area:** Product categories and hierarchy **Depends:** Nothing **Why:** Products are assigned to a category within the procurement or sales hierarchy. #### Product **Step:** 10 **Area:** Inventory dimension groups and item groups **Depends:** Legal entities **Why:** Assigned at product release time and hard to change after transactions. #### Product **Step:** 11 **Area:** Products and product masters **Depends:** Units, categories **Why:** Shared products are created before they are released to companies. #### Product **Step:** 12 **Area:** Released products **Depends:** Products, dimension groups **Why:** Company specific release links the product to item groups and costing settings. #### Product **Step:** 13 **Area:** Sites, warehouses and locations **Depends:** Legal entities **Why:** Required before any on-hand or order lines can carry inventory dimensions. #### Parties **Step:** 14 **Area:** Customers V3 **Depends:** Customer groups, terms, dimensions **Why:** Customer accounts must exist before open invoices and sales orders. #### Parties **Step:** 15 **Area:** Vendors V2 **Depends:** Vendor groups, terms, dimensions **Why:** Vendor accounts must exist before open invoices and purchase orders. #### Parties **Step:** 16 **Area:** Customer and vendor bank accounts **Depends:** Customers, vendors **Why:** Banking details attach to parties and are used in payment proposals. #### Structures **Step:** 17 **Area:** Bills of materials and routes **Depends:** Released products, resources **Why:** Components and operations must exist as released products and resources first. #### Structures **Step:** 18 **Area:** Trade agreements and price lists **Depends:** Released products, customers, vendors **Why:** Pricing records reference products and accounts. #### Open items **Step:** 19 **Area:** Open purchase orders and sales orders **Depends:** Parties, products, warehouses **Why:** Open lines reserve supply and demand and need valid dimensions. #### Open items **Step:** 20 **Area:** On-hand inventory (opening inventory journal) **Depends:** Products, warehouses, tracking dimensions **Why:** Load after orders are understood so reservations can be rebuilt deliberately. #### Open items **Step:** 21 **Area:** Open customer and vendor balances **Depends:** Customers, vendors, main accounts **Why:** Posted through journals with invoice detail so aging works. #### Closing **Step:** 22 **Area:** Fixed assets and book values **Depends:** Asset groups, main accounts **Why:** Opening values posted with acquisition and depreciation history as required. #### Closing **Step:** 23 **Area:** General ledger opening balances **Depends:** Main accounts, dimensions, open items **Why:** Loaded last and reconciled to subledgers so control accounts tie out. **Notes:** 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. ## Content **Intro:** 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. **Sections:** #### How to use this load order **Body:** 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. **Bullets:** - 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 **Body:** 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 **Body:** 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 **Body:** 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. **Bullets:** - 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. **Cta:** 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. **Faq:** #### Which D365 data should be loaded first? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms d365 data migration order, d365 f&o data load sequence, d365 cutover data load order, d365 data management load order, d365 f&o migration dependencies, dynamics 365 opening balances load, d365 customers v3 vendors v2 import, d365 migration plan template --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json