Migrate from ERPnext Enterprise - Bespoke to Microsoft Dynamics 365 Business Central

ERPNext Customer DocType maps to D365 Account (Business Central or CRM) or CustCustomerV3Entity (D365 Finance and Operations). The ERPNext territory hierarchy maps to D365 geographical segments or dimensions depending on the D365 edition. We validate that the ERPNext territory structure has a corresponding D365 dimension configured before migrating, because territory linkage drives downstream reporting in ERPNext and must be preserved or explicitly redesigned. Tax ID and industry segment map to D365 Tax Identification Number and Industry Code fields respectively.

ERPNext Supplier DocType mirrors the Customer DocType structure and maps to D365 Vendor. Supplier type, payment terms, and address records carry forward. ERPNext supplier-specific tax categories require translation into D365 sales tax groups and vendor tax groups depending on the destination D365 app. We handle the address-flattening step the same way as customer addresses, resolving Dynamic Link relationships during export.

ERPNext Item carries item code, description, item group, stock UOM, valuation method, and barcodes. D365 requires a separate item tracking dimension setup if barcodes are used (which we configure before import), and the valuation method (ERPNext supports FIFO, Moving Average, and Standard; D365 F&SCM supports FIFO Periodic, FIFO Moving Average, Standard, and Weighted Average) must match exactly. We flag any mismatch before migration so that inventory valuation does not change unexpectedly post-migration. Custom item fields carry forward as D365 product custom attributes.

ERPNext BOMs are nested structures referencing Items with quantity ratios and routing operations. D365 BOMs require BOMVersion entities with valid-from and valid-to dates and separate route-operation definitions. We validate that all child Item codes referenced in BOMs exist in D365 before committing to the migration, because BOM lines with missing Item references break the production order in D365. ERPNext work orders and job cards map to D365 production orders and production routes respectively, requiring a separate configuration step for the Manufacturing execution module.

ERPNext Sales Orders contain line items, taxes, discounts, and shipping details across a flat header-row structure. D365 separates header and line entities, and taxes are assigned via tax groups rather than stored as line-level totals. We split the ERPNext Sales Order into two DMFPackage CSV files (header and line) and load them through the D365 Data Management Framework in sequence, resolving the SalesOrderNumber-to-internal-entity mapping between phases. Open Sales Orders (status not Cancelled and not Fully Delivered) are migrated as active orders; cancelled and fully-delivered historical orders migrate as records if scope includes historical data.

Purchase Orders mirror the Sales Order mapping pattern in structure. We migrate PO headers and line items separately through the D365 Data Management Framework, flagging any advance allocation records that require separate handling as D365 prepayment journals. D365 enforces a stricter approval workflow for purchase orders than ERPNext does; we document the existing approval state so the customer's D365 admin can configure equivalent approval workflows post-migration.

ERPNext uses a voucher-based double-entry system where journal entry rows reference account numbers directly. We map journal entry rows to D365 main accounts but validate that the target chart of accounts has matching account numbers before migration. D365 enforces one debit and one credit per row in its journal structure, while ERPNext allows multiple debit or credit accounts per line. We split mixed-per-line ERPNext vouchers into multiple D365 journal lines during transformation. GL opening balances require a separate opening-balance journal in D365 rather than a direct ledger entry, which we handle as a distinct phase after the account chart migration.

ERPNext Stock Ledger Entries link to warehouse, item, and valuation rate. We migrate open stock positions as InventSum records via D365 inventory closing journals. Historical movement logs require bulk CSV export from ERPNext's MariaDB directly, because the API does not expose a bulk movement endpoint, and transformation into D365 InventTrans format before import. The valuation rate from ERPNext carries forward as the cost price in D365, and we flag any items where the D365 valuation method does not match ERPNext before inserting.

ERPNext Asset records include purchase details, depreciation schedule, and current value. We map asset masters and depreciation schedules directly. Any fully depreciated-to-zero assets are skipped unless the customer specifically requests them migrated, because they carry no financial value in D365 but consume entity storage. Depreciation parameters (useful life, depreciation method, scrap value) migrate as-is and are validated against D365 depreciation book settings before insertion.

ERPNext Projects carry a nested task hierarchy with assignees, start and end dates, billable hours, and hourly rate settings. We map the full project-task tree including custom task fields. D365 Business Central uses Jobs and Job Tasks; D365 F&SCM uses ProjProject with WBS (Work Breakdown Structure) tasks. We confirm the destination D365 app during discovery and configure the appropriate project entity structure before migration. Hourly rate mappings carry forward as billing rates on the D365 project card.

ERPNext Employee DocTypes expose employment details, department, and reporting structure. We migrate active employees and current compensation records. Payroll history and historical salary data are excluded from standard scope unless specifically requested, because payroll records require country-specific tax and deduction configuration in D365 HR that is outside a general migration. Department and reporting hierarchy map to D365 HR positions and reporting lines.

ERPNext stores contacts and addresses as separate DocTypes linked by Dynamic Links. D365 stores address and contact information as part of the DirParty (Directory Party) entity associated with an Account or Vendor. We resolve the Dynamic Link relationships during export to produce flat contact records with embedded address data in the D365 DirParty format. The ERPNext address type (billing, shipping, primary) maps to D365 address purpose roles.

ERPNext Custom Fields attach to any DocType via the Custom Field DocType. We export all custom field definitions separately and apply them on the D365 destination before importing any data so that target fields exist at insert time. Custom fields on ERPNext DocTypes that have no D365 equivalent require either a D365 custom field or a transformation decision (drop and re-enter, or map to an existing D365 field). We document every transformation decision in the mapping specification for the customer's approval before production migration.

ERPNext's native Data Export DocType exports field data only. File attachments stored on Purchase Receipts, Item masters, or Employee records live in the ERPNext file system or S3 bucket and are not included in CSV or API exports. We handle attachments as a parallel workflow: using direct file system access to export files with folder hierarchy preserved, then re-associating them with the correct D365 records post-import via SharePoint libraries or Dataverse annotation records. File export must be scoped and priced as its own parallel workstream before migration begins.