Migrate from Sage 500 to Microsoft Dynamics 365 Business Central

Sage 500 stores GL Account codes, account types, and segment values in the CM_Account and CM_Segment tables with foreign-key relationships to journal entry detail lines. We extract the full account hierarchy including dimensions, account type, posting profile, and the cost center segment structure. Each Sage 500 segment maps to a Dynamics 365 dimension (such as Department, Project, or Division) that must be pre-configured in the destination. If the Sage 500 chart uses more than three segments, the customer must confirm that the Dynamics 365 product tier supports the required dimension count.

Sage 500 customer records from the IM_Customer table include billing addresses, shipping addresses, payment terms, 1099 configuration, credit limits, and salesperson assignments. We extract the full address hierarchy (billing, ship-to, REMIT-TO) and map to the Dynamics 365 Customer address roles. Payment terms code from Sage 500 (such as Net 30 or 2/10 Net 30) maps to a Payment Terms code configured in Dynamics 365 before customer import. The customer number from Sage 500 becomes the Dynamics 365 Customer Number and serves as the dedupe key.

Sage 500 vendor records from the AP_Vendor table include billing address, payment terms, 1099 configuration, 1099 box assignments, and W-9 status. We extract all vendor fields and map them to Dynamics 365 Vendor records, preserving the vendor number as the primary key. Tax registration numbers and 1099 box assignments from Sage 500 become the IRS 1099 Form Box and Tax ID fields in Dynamics 365.

Sage 500 tracks open AR in aging tables with invoice numbers, invoice dates, due dates, aging buckets, and outstanding amounts including finance charges. We extract the full AR aging detail and map to Dynamics 365 Customer Ledger Entries with the same document number, posting date, due date, and remaining amount. The destination must match the aging period configuration (such as 1-30, 31-60, 61-90, 90+ days) before import to avoid aging bucket misalignment. Historical closed invoices are migrated as posted entries for audit continuity.

Sage 500 open AP records from the aging tables include vendor invoice numbers, posting dates, due dates, and outstanding amounts. We extract the full AP aging detail and map to Dynamics 365 Vendor Ledger Entries. Prepayment invoices and credit memos are mapped to their respective entry types. Vendor-specific discount terms from Sage 500 are preserved in the Payment Terms mapping to ensure early payment discounts calculate correctly in the new system.

Sage 500 stores sales orders across the SO_SalesOrder header, SO_SalesOrderDetail line, and related tax and warehouse assignment tables. A single order in Sage 500 spans five to eight tables depending on line item count and freight configuration. We write multi-table JOINs to assemble complete order headers with all line items, pricing, warehouse assignments, and tax schedules before staging for Dynamics 365 import. Order status (open, partially shipped, shipped, invoiced, cancelled) maps directly to Microsoft Dynamics 365 Sales Order Status. Backorder quantities and promised dates are preserved as line-level fields.

Sage 500 purchase orders follow the same multi-table normalization as sales orders, with PO header, PO detail, tax, and warehouse tables. We assemble complete PO records including the vendor number, buyer assignment, delivery address, and line-level expected receipt dates. Open purchase orders (not yet received) are prioritized in the migration sequence because Dynamics 365 uses the PO as the basis for receiving and invoice matching workflows.

Sage 500 inventory items from the IM_Item table include item number, description, unit of measure, costing method (FIFO, LIFO, standard), default warehouse, reorder point, and vendor assignments. We extract the full item master and map to Dynamics 365 Item records, preserving the costing method configuration. If Sage 500 uses FIFO or LIFO layers with transactional cost tiers, we confirm the destination's costing engine before committing to cost carryover; standard cost environments extract and load cleanly. Multi-warehouse item locations from Sage 500's IM_ItemLocation table map to Dynamics 365 inventory posting groups and location codes.

Sage 500 fixed asset records include acquisition date, cost, asset class, depreciation method (straight-line, declining balance, units of production), book value, accumulated depreciation, and the full depreciation schedule. We extract all historical depreciation entries from the FA_Depreciation table and map them to Dynamics 365 Fixed Asset records with corresponding FA Ledger Entries. The destination must support the same depreciation method; mismatched methods require an explicit configuration decision during scoping before any asset records are generated.

Sage 500 stores all GL journal entries in the GL_Transaction and GL_TransactionDetail tables with source module (AP, AR, Inventory, Payroll), batch number, posting date, and full debit/credit detail. We extract the complete journal entry history including source module attribution, batch descriptions, and reversal entries. Each Sage 500 journal entry batch becomes a Dynamics 365 General Journal Batch with source document references preserved in the Description field. Entry numbers and posting dates are preserved for audit trail continuity.

Sage 500 tax codes and rates from the TX_TaxCode table are jurisdiction-specific and assigned to vendors and transactions. We extract the full tax code hierarchy including tax groups and rate overrides, but nexus-specific rules and customer-specific exemptions require manual configuration in Dynamics 365 Tax Setup because these are jurisdiction-governed and cannot be blindly transferred. We deliver a tax code mapping spreadsheet that lists each Sage 500 tax code and its intended Dynamics 365 Tax Group and Tax Code equivalent for the customer's tax accountant to finalize.

Sage 500 bank accounts from the BM_Bank table include bank account number, bank name, GL account linkage, and reconciliation records. We extract bank accounts and their GL account mappings and load them into Dynamics 365 Bank Account records, preserving the bank account number and routing information. If the customer performs bank reconciliation in Sage 500, we extract cleared transaction detail for re-entry or import into the Dynamics 365 Bank Reconciliation module.

Sage 500 stores departmental and cost center segment values in the CM_Segment table with descriptive names and effective dates. We extract all active segment values and map them to Dynamics 365 Dimensions, which must be pre-configured in the destination with the correct dimension type (such as Department, Project, or Business Unit) before migration begins. If the destination uses a different dimension naming or count structure than Sage 500, we align the segment values during the transform step before loading.

Sage 500 warehouses from the IM_Warehouse table include location code, address, default posting group, and the bin location configuration. We extract warehouse records and map them to Dynamics 365 Location codes, preserving the bin structure if bin management is active. If Sage 500 uses multiple bins per warehouse, we map the warehouse-bin hierarchy to the Dynamics 365 Location hierarchy with the warehouse as the parent location.