Migrate from Sage 300cloud to Microsoft Dynamics 365 Business Central

Sage 300cloud uses hierarchical accounts with up to 10 segment codes per account for multi-dimensional reporting. Each Sage 300 company code carries its own chart of accounts, which we treat as an independent migration unit. We map Sage segment codes to Dynamics 365 financial dimension sets (such as Department, Cost Center, Division, Location), preserving account code, description, account type, and active/inactive status. The destination dimension set is defined before account import so that each account record can be assigned the correct dimension reference at insertion time.

Sage 300cloud customer master records include billing and shipping addresses, payment terms, credit limits, multi-currency settings, and tax registration numbers. We map customer records to Dynamics 365 Customer with Customer Posting Group and Payment Terms assigned per Sage 300 payment term code. Multi-currency customers receive the appropriate Currency Code assignment. Address structure requires transformation: Sage 300 stores separate billing and shipping address records that map to the Dynamics 365 Address and alternative Address records on the Customer. Note that Dynamics 365 allows only one address to be marked as the primary address; we preserve all address roles in auxiliary address records for audit completeness.

Sage 300cloud vendor master records mirror the customer structure with 1099 reporting flags for US installations, tax ID fields, and payment terms. We map vendors to Dynamics 365 Vendor with Vendor Posting Group and Payment Terms resolved from the Sage vendor record. 1099 reporting flags map to the Tax 1099 Boolean fields in Dynamics 365, and historical 1099 data exports from Sage for reconciliation against year-end 1096 submissions at the destination. EFT payment processing settings are documented during extraction and reconfigured manually in the destination because payment format configurations are destination-specific.

We extract current AR aging summaries and open invoice details from Sage 300cloud to seed the destination with accurate beginning balances. Each open item carries a unique document number, invoice date, due date, discount terms, and remaining amount. Rather than importing full historical posted invoices into Dynamics 365's open ledger (which would bloat the cloud environment), we create opening balance journal entries that reflect the net AR position per customer as of the migration cutoff date. Post-go-live aging reports in Dynamics 365 are compared against Sage 300 aging reports to validate balance accuracy before the cutover window closes.

Open AP invoices from Sage 300cloud migrate as vendor ledger entry seeding records in Dynamics 365, following the same beginning-balance approach as AR. We extract current AP aging summaries with document number, invoice date, due date, discount terms, and remaining amount. Opening balance journal entries are posted in AP before the cutover date to reflect the accurate vendor liability position. Historical 1099 and 1096 data is extracted separately and preserved in a reference archive for year-end reporting continuity.

Sage 300cloud inventory supports multiple valuation methods (FIFO, Average, Standard) and multiple warehouses with bin locations. We map inventory items to Dynamics 365 Item with the valuation method explicitly assigned and the unit of measure carried from Sage. Warehouse and bin location assignments require transformation: Sage warehouses map to Locations in Dynamics 365, and bin locations map to bin codes under each Location. If the destination is Business Central Premium with Warehouse Management, we configure warehouse employees and bin structures before item import. Valuation method and warehouse assignments must be explicit during scoping because Dynamics 365 does not allow retroactive valuation method changes after transactions are posted.

Sage 300cloud fixed asset registers include acquisition date, cost basis, depreciation method, accumulated depreciation, and current book value. Multiple depreciation schedules per asset are supported. We map the primary depreciation schedule to Dynamics 365 Fixed Asset with Depreciation Book assigned. Depreciation method mapping requires translation from Sage's method codes (Straight-Line, Declining Balance, Units of Production) to Dynamics 365 Fixed Asset Depreciation Book entries. Accumulated depreciation and net book value are imported as an opening acquisition and accumulated depreciation posting to preserve the asset's current carrying value at cutover.

Sage 300cloud tax codes carry jurisdiction-specific rates, tax type (sales vs. use), and posting accounts. International configurations with multiple tax authorities per code require re-association in Dynamics 365 because the destination stores tax jurisdiction codes, tax groups, and posting profiles as separate configuration objects. We extract every active tax code, rate, effective date, and posting account mapping from Sage and produce a written tax configuration guide for the customer's Dynamics 365 admin to re-enter in the destination's Tax Settings page, which is a manual step required to ensure jurisdiction accuracy for sales tax, VAT, and GST filings.

Sage 300cloud bank codes, account numbers, bank reconciliation formats, and current cleared balances migrate to Dynamics 365 Bank Accounts. We preserve bank account numbers, currency codes, and GL account assignments from Sage. EFT payment processing settings (payment formats, bank instruction codes, remittance advice configuration) are documented during extraction and reconfigured manually in the destination's Bank Account Payment Journal setup because payment format specifications are destination-specific and often require banking partner confirmation.

Sage 300cloud GL journal entries, batch headers, and source module references export by fiscal period. We sequence historical entries by fiscal period and import them into Dynamics 365 using the General Journal batch import framework. Complex recurring entries and reversing journal templates require re-creation at the destination because they are system-defined automation logic rather than data. Entry-level source references (module origin codes like AR, AP, IC, FA) map to the Dynamics 365 General Journal Entry Source Code field to preserve the audit trail of which module generated each entry.

Sage 300cloud payroll registers, employee earnings, deductions, employer tax contributions, and year-to-date accumulators export by pay period. We map YTD accumulators to the destination's payroll setup, creating Pay Employees and corresponding Pay Journal entries for each historical pay period within the retention window (typically current and prior fiscal year). Custom deduction codes and third-party benefit deductions require manual re-entry in Dynamics 365 Payroll because deduction rules and employer contribution percentages are configuration rather than data. US customers with 941 and W-2 history export the tax forms as PDF archives rather than transactional records.

Documents linked to Sage 300cloud transactions (invoices, purchase orders, receipts) are stored in a configurable file-system directory path, not in the database. We document the attachment path, extract files matching transaction document references, and import them into the destination's document management layer (SharePoint Online attached to Dynamics 365, or the standard Attached Files mechanism). This step requires read access to the Sage host file system or a backup of the attachment directory and cannot be completed via the Sage REST API alone. We cross-validate attachment filenames against GL and AP/AR document references to confirm match rates before the import phase.

User-defined custom fields on any Sage 300cloud core object are extracted via direct table query because the native UI export function does not reliably include all user-defined fields. We cross-validate exported values against the Sage 300 UI before building the import mapping. Custom fields on customers, vendors, items, and GL accounts map to Dynamics 365 extension fields on the corresponding entity (table extension objects in Business Central). Field type mapping must be verified because Sage field types (date vs. string vs. dropdown) do not always translate directly to Dynamics 365 field types, and Dynamics 365 does not allow field type changes after data is loaded.

Sage 300cloud organizational segments used for allocation and reporting map 1:1 to Dynamics 365 Global Dimensions or shortcut dimensions. We map each Sage segment label (Department, Division, Location, etc.) to the corresponding Dynamics 365 Dimension value, preserving segment codes and descriptions. Segment labels and inter-segment elimination rules are documented during discovery and re-entered in the destination's Dimension configuration page, which is a manual setup step required before dimension-assigned account imports can proceed.