Migrate from Sage 100cloud to Microsoft Dynamics 365 Business Central

Sage 100cloud's GL accounts export from the GL_Account master via SQL or BIE view. In Business Central we load via RapidStart Configuration Package on the G/L Account table, preserving Account No., Name, Account Type, and Direct Posting flag. In F&O we use the DMF Main Account entity (LedgerChartOfAccountsEntity) and recreate the account structure in the Chart of Accounts. Sage segment values (Type, Division, Department) become Financial Dimensions in F&O or Dimension Codes in BC, configured before account import so dimension references resolve.

Sage AR_Customer maps to the Dynamics Customer entity. Customer number, name, billing address, shipping addresses, payment terms, credit limit, and salesperson assignment migrate. In BC we use the Customer table via RapidStart; in F&O we use the CustCustomerV3Entity through DMF. Multi-ship-to records are flattened in Sage and recreated as multiple Ship-to Addresses on the destination Customer record. We preserve the Sage Customer No. as a custom field for cross-reference.

Sage AP_Vendor records (address, payment terms, 1099 flag, W-9 status) map to Dynamics Vendor. In BC we load via Configuration Package on Vendor; in F&O we use VendVendorV2Entity. 1099 settings transfer to the 1099 fields on the destination vendor card to preserve year-end reporting. Bank account information for ACH/wire payments is loaded separately into the Vendor Bank Account entity, with routing and account numbers re-encrypted under Dynamics' protected fields.

Sage IC_Item migrates to BC Item or F&O Released Product. Item No., Description, Base Unit of Measure, Item Tracking (Lot or Serial), Costing Method (FIFO, LIFO, Average, Standard), and Inventory Posting Group transfer. In F&O the Released Product is created from a Product Master first; we generate the master records during transformation. Lot and serial-tracked items require Item Tracking Code assignment before the inventory balance load.

Sage BOM headers and components split into Dynamics Production BOM (BC) or BOM Version (F&O). Each BOM component becomes a Production BOM Line in BC or a BOM Line in F&O. Phantom BOMs from Sage are flagged for re-modeling because Dynamics treats phantoms differently (BC uses Production BOM Type, F&O uses Line Type = Phantom). Routing data, if maintained in Sage Production Management, becomes a Routing in BC or a Route in F&O loaded separately. Effective dates are preserved on BOM Versions.

Open accounts receivable from Sage AR_Invoice migrate as Customer Ledger Entries in BC (via the Sales Invoice journal posted at the cutover balance) or as open transactions through the CustCustomerOpenTransV2Entity in F&O. We preserve original invoice date, due date, amount remaining, document number, and currency. Partially-applied payments are loaded as separate Customer Ledger Entries with the application table reconstructed post-load. The total open AR balance must reconcile to the GL Accounts Receivable control account.

Sage AP_Invoice open balances migrate as Vendor Ledger Entries in BC (via a Purchase Invoice journal posted at cutover) or through the VendVendorOpenTransV2Entity in F&O. We preserve original invoice date, due date, amount remaining, document number, vendor reference, and 1099 amount. Held invoices and disputed invoices from Sage are flagged via a status custom field and either loaded with a hold flag in Dynamics or excluded with customer sign-off.

Sage FA_Asset records (acquisition cost, depreciation method, useful life, book value, accumulated depreciation) migrate to Dynamics Fixed Asset. BC uses the Fixed Asset table loaded via RapidStart with separate Depreciation Book records per book. F&O uses FixedAssetEntity with separate Book entries per Value Model. Sage depreciation methods (straight-line, declining balance, MACRS) map to Dynamics equivalents; non-standard methods are flagged and require customer sign-off on the mapping before posting.

Historical GL transactions from Sage are migrated only with explicit scoping. In BC we use the General Journal to post historical entries to a separate historical posting group with an opening balance reversal entry to net the impact. In F&O we use the General Journal Entity through DMF with a dedicated journal name. Locked Sage fiscal periods must be unlocked or excluded; the customer signs off on the historical migration window (typically two to seven years) before any historical GL is loaded.

Open Sales Orders from Sage migrate to Dynamics Sales Order. Header fields (customer, ship-to, payment terms, requested ship date) and line items (item, quantity, unit price, line discount) transfer. In BC we load via the Sales Header and Sales Line tables; in F&O we use SalesOrderHeaderV2Entity and SalesOrderLineV2Entity. Partially-shipped lines are split into shipped and remaining components, with the remaining quantity carried into Dynamics as the open balance. Closed historical sales orders are typically excluded unless explicitly scoped.

Open Purchase Orders from Sage migrate to Dynamics Purchase Order. Header (vendor, ship-to, requested receipt date, payment terms) and lines (item, quantity, unit cost, expected receipt date) transfer. In BC we load via Purchase Header and Purchase Line; in F&O we use PurchPurchaseOrderHeaderV2Entity and PurchPurchaseOrderLineV2Entity. Partially-received POs are split into received and remaining quantities, with the received portion documented but not re-posted. We flag POs with multiple receipts at scoping for customer decision on whether to migrate as open or closed.

Inventory on-hand balances per item per warehouse per lot per serial are loaded at cutover. In BC we use the Item Journal to post positive adjustments with the correct posting groups, then reconcile to the inventory GL control account. In F&O we use the InventOnHandV2Entity with the appropriate site, warehouse, and inventory dimension. Lot and serial numbers are preserved exactly to maintain traceability. Bin-level balances require Warehouse Management activation in the destination before load.

Sage Job Costing maps to BC Jobs or F&O Project Management and Accounting. Job structures (phases, cost codes, budget vs actual) require field-level reconfiguration. In BC we map Sage phases to Job Task Lines; in F&O we map to Project Categories under a project hierarchy. Historical job transactions migrate as Job Ledger Entries (BC) or Project Transactions (F&O). Open work-in-process balances are loaded as a single opening WIP entry per job, reconciled to the WIP GL control account.

Sage UDFs in module-specific extension tables have no standard export. We query the Sage SQL schema for non-standard columns per module, export to sidecar CSV, and create matching custom fields in Dynamics via AL extensions (BC) or table extensions through Visual Studio Application Object Tree (F&O). Field-level data type translation is manual (Sage varchar, decimal, date map to AL/F&O equivalents). Custom field count is unconstrained but each field adds to the extension's deployment footprint; we recommend consolidation before creation.

Sage users map to Dynamics users by email match against Microsoft Entra ID. Active users are provisioned in Microsoft Entra and assigned to the Dynamics environment via license assignment before record import. User Permission Sets (BC) or Security Roles (F&O) are recreated from Sage role definitions, with the customer's admin signing off on the role mapping. Inactive Sage users are not provisioned but their historical record ownership is preserved with the original username stored in a custom audit field on affected records.