Migrate from Orion ERP to Microsoft Dynamics 365 Business Central

Orion COA records map to D365's main account structure. Account Code, Name, Account Type (Asset, Liability, Equity, Revenue, Expense), and currency settings transfer directly. Multi-segment COA in Orion (such as Cost Centre plus Department plus Natural Account) maps to D365 Financial Dimensions, with each Orion segment mapped to a named dimension structure that the customer's D365 administrator configures before import. We use the D365 Data Management Framework to load the chart via the Entities list.

Orion Customer master records map to D365 Customers. We extract billing address, payment terms, credit limit, customer group, and currency settings via the customer listing report. The D365 Customer Group must be provisioned before migration so that CustomerGroupId is available as a foreign-key reference during import. Payment terms map to D365 PaymentTermId with the customer's terms record created or matched first.

Orion Vendor master records map to D365 Vendors. Tax ID, payment terms, bank details, and vendor group transfer. Vendor Group in D365 must be provisioned before import to satisfy the VendorGroupId lookup. Tax ID format validation is applied during transform: Orion and D365 use different Tax ID formats by country, so we apply country-specific regex validation and flag records with format mismatches for manual correction before load.

Orion GL entries (journal header with date, journal number, description, and line items: account, debit, credit, dimension) map to D365 General Journal lines. We preserve posting dates and journal descriptions. D365 requires a LedgerJournalTable header record before any LedgerJournalTrans lines, so we generate the header-first approach. Historical GL imports of more than 50,000 lines use D365's recurring journal template or Data Management batch import to stay within API batch limits.

Open AP in Orion is a live financial record, not an aging snapshot. We extract vendor reference, invoice number, amount due, and due date as a distinct migration scope item and inject them into D365 as opening-balance vendor ledger entries via the Data Management Framework. The posting date is set to the migration go-live date, and the invoice reference is preserved in the Description or ExternalReference field. This ensures open AP does not appear as a new transaction that could be re-processed or double-posted.

Open AR follows the same treatment as open AP: extracted as a distinct scope item from Orion's financial module and loaded into D365 as opening-balance customer ledger entries rather than new sales invoices. Customer invoice number, amount receivable, due date, and currency are preserved in the migration transform. D365's aging report is then used post-migration to confirm the opening balance reconciles to Orion's pre-migration AR aging report.

Orion Item master records map to D365 Released Products with ProductType = Item. SKU, description, unit of measure, cost price, and warehouse location transfer. If the source runs Orion Manufacturing Cloud, we additionally map BOM records to D365 Bills of Materials, where each Orion BOM header becomes a D365 BOM version and each Orion component line becomes a BOM line with quantity-per and issue method. BOM route operations map to D365 production route versions.

Orion PO headers and lines transfer to D365 Purchase Orders. PO status (Open, Closed, Cancelled) maps to D365 PurchaseOrderStatus. Open POs require preservation of vendor reference, line quantities, and pricing for operational continuity at go-live. Closed POs are migrated as historical records with a Cancelled or Completed status so the full procurement history is available in D365. We map PO lines to D365 PurchLine with item number, quantity, unit, and cost.

Orion Sales Order headers and lines map to D365 Sales Orders. Customer reference, order lines, pricing, and order status transfer. Open sales orders are the highest-priority operational continuity item: we preserve order number, customer account, line product references (resolved against the item number mapping), quantities, and pricing. Fulfilled lines are migrated with an Invoiced status to carry the historical record. Partially fulfilled orders are flagged with a partial shipment note in the order header for the customer's sales operations team to manage post-migration.

Orion Employee records map to D365 Workers via the Human Resources module or the built-in Worker table in Finance and Operations. Employee name, department, job title, employment dates, and effective-dated compensation history transfer. Compensation history requires sequencing by effective date because D365 HR stores compensation as a valid-from and valid-to structure rather than a flat record. Manager hierarchy maps to the D365 position hierarchy.

Orion custom fields on any master or transaction record are detected during the scoping export and mapped to D365 custom fields created via the Custom Fields workspace (for UI-facing custom fields) or table extensions (for API-accessible fields). Custom field data types from Orion are matched to D365 field types: text to String, number to Real, date to Date. All custom fields and their data types are documented in the field map delivered before migration.

Binary attachments and documents stored in Orion's document management layer are not accessible via the report export engine and are therefore out of scope for standard migration. We provide a manifest of all records that have associated attachments, listing the record ID, record type, and document filename as stored in Orion. The customer's IT team uses this manifest to perform a separate document extraction via Orion's document management UI or direct blob access, then uploads to D365's SharePoint or Dataverse attachment layer as a parallel workstream.