Migrate your Sage 300cloud data

Sage 300cloud uses a hierarchical account structure with segment codes (up to 10 segments) supporting multi-dimensional reporting. We preserve account codes, descriptions, account type, and active/inactive status. Segment definitions are mapped to the destination's equivalent dimension fields.

Customer master records include billing and shipping addresses, payment terms, credit limits, and multi-currency settings. Open AR invoices carry invoice number, date, due date, and line-item detail. We map these to the destination's customer and invoice objects while preserving outstanding balance history.

Vendor master records mirror the customer structure with 1099 reporting flags for US installations. Open AP invoices include discount terms and aging buckets. Historical 1099 and 1096 data is extracted and mapped to the destination's vendor payment history.

Sage 300cloud supports multiple inventory valuation methods (FIFO, Average, Standard) and allows for multiple warehouses with bin locations. Valuation method and warehouse assignments must be explicitly mapped because some destination systems collapse these into a single site record.

We extract current aging summaries and open invoice details to seed the destination with accurate beginning balances. Each open item carries a unique document number, apply-to reference, and discount eligibility date that must be written to the destination's transaction ledger.

GL journal entries, batch headers, and source module references are exported by fiscal period. Complex recurring entries and reversing journal templates require re-creation at the destination because their automation schedules do not export.

Fixed asset registers include acquisition date, cost, depreciation method, accumulated depreciation, and book value. Sage 300cloud supports multiple depreciation schedules per asset. We map the primary schedule and flag secondary depreciation methods as custom fields in the destination.

Tax groups and tax codes carry jurisdiction-specific rates, tax type (sales vs. use), and posting accounts. International tax configurations with multiple tax authorities per code require re-association at the destination because mapping structures differ.

User accounts, passwords, and security role assignments do not export. User access must be manually re-provisioned at the destination. We provide a role-permission matrix as a checklist to accelerate the re-onboarding of each user.

Bank codes, account numbers, bank reconciliation formats, and current cleared balances are migrated. EFT payment processing settings are documented but require manual configuration in the destination's banking module.

Documents linked to transactions (invoices, purchase orders, receipts) are stored in a configurable file path. We extract them from the file-system layer and import them into the destination's document management or attachment object. Binary integrity is validated post-import.

Payroll registers, employee earnings, deductions, and employer tax contributions export by pay period. Year-to-date accumulators are mapped to the destination's payroll setup. Custom deduction codes require manual re-entry in the destination's payroll configuration.

User-defined fields on any core object are extracted via the custom field export path. Field type mapping (date vs. string vs. dropdown) must be verified before import because destination field types may not match exactly.

Organizational segments used for allocation and reporting are mapped 1:1 to the destination's department or cost-center object. Segment labels and inter-segment elimination rules are documented during the discovery call.