Migrate from Sage Intacct to Infor CloudSuite Corporate

Sage Intacct GL accounts export via REST API with account number, name, type, active status, and parent hierarchy. Infor CloudSuite uses a multi-segment chart of accounts (company, division, department, account). We map the Sage Intacct account number to the account segment and use the entity and department structure in Infor to represent the Sage Intacct dimensional context. Active/inactive status carries forward. The account hierarchy (parent/sub) maps to Infor's rollup structure for financial consolidation reporting.

Historical journal entries are migratable, but dimensional resolution is the critical decision point. Sage Intacct tags each journal line with dimension values (department, class, location, customer, project). Infor CloudSuite does not have an equivalent dimensional tagging model; dimension values must be mapped to cost-centre segments, business-unit values, or project codes. If the source journal entries carry dimensional metadata, we apply a dimension-to-segment mapping table during the transform. If they do not (non-dimensionalized source data), we migrate the entry amounts only and advise the customer that analytical filtering by dimension will not be available post-migration. We scope this decision during discovery and include it in the migration readiness report.

Sage Intacct Dimensions (department, class, location, customer, project) are a core tagging concept without a direct Infor CloudSuite equivalent. We treat each Sage Intacct dimension as a named-value set and map it to the most appropriate Infor structure: department to Cost Centre segment, class to a user-defined segment or custom field, location to a site/location code in Infor OS, customer to the Customer entity cross-reference, and project to the Infor Project entity if the Project Accounting module is licensed. The mapping table is validated against a sample of live transactions before production import. Dimensions that cannot be mapped (because no Infor equivalent exists in the customer's licensed modules) are flagged in the scoping report for a customer decision before migration begins.

Open AP bills, payments, and vendor associations export cleanly via the Sage Intacct REST API. We flag any bills in a 'pending approval' or non-posted state because Infor CloudSuite AP requires workflow routing before payment processing. Vendor records (name, address, payment terms, default GL accounts) map to the Infor Vendor master. Vendor balances carry forward as open payables. Historical AP transactions (paid bills) migrate to the GL as historical detail if the customer requires audit history; otherwise they are excluded from the migration scope.

Open AR invoices, payments, and customer records migrate via the Sage Intacct REST API. We map customer balance-forward vs. open-item AR settings from the source to the corresponding Infor AR configuration. Customer records (name, address, payment terms, credit limits) map to the Infor Customer master. Open invoice amounts carry forward as receivables. Invoice PDFs and attachments cannot be retrieved via the Sage Intacct REST API and require a separate document extraction strategy (see Attachments note below).

Sage Intacct customer and vendor master records, including addresses, payment terms, default GL accounts, and contact information, export via REST API. Custom fields on customer and vendor objects use the !-prefix in the API and are discovered during schema mapping. We apply the !-prefix during extraction and map custom field values to corresponding Infor custom fields or entity attributes. Each master record receives a cross-reference ID to support referential integrity with any migrated AR/AP transactions.

Project headers and task hierarchies migrate cleanly. We preserve project status, billing type, customer association, and task-level billing rates. Billable vs. non-billable flags are verified against the source system. If the Infor CloudSuite edition does not include Project Accounting, projects map to Infor Cost Centre or a custom Project entity in Infor OS, and billing structure is delivered as a supplemental configuration guide for the customer's Infor partner to implement post-migration.

Fixed asset records migrate (acquisition cost, date, asset class, serial number) but depreciation schedules require recalculation in Infor CloudSuite because each jurisdiction uses different conventions. We transfer the acquisition cost, placed-in-service date, asset class, and depreciation method as metadata fields, then flag the destination depreciation schedule as requiring recalculation before any depreciation posting runs in production. This is a known step in every fixed-asset migration between ERP platforms and is handled as a post-migration configuration task with the customer's Infor partner.

Sage Intacct Planning module budget line data can be exported and mapped to Infor's budget scenarios. Each Sage Intacct fiscal year and scenario maps to a corresponding Infor budget structure with period amounts. If the customer does not license Infor Planning, budget data is migrated as reference data in a flat file with a mapping guide so the customer can enter it manually or build an import template in Infor.

Entity definitions, inter-company transaction rules, and consolidation mappings export from Sage Intacct and map to Infor CloudSuite's legal entity and intercompany structure. We preserve the entity hierarchy so that cross-entity GL entries route correctly post-migration. Entity-to-entity routing rules (which entity is the parent, which currencies are used, what consolidation method applies) are explicitly mapped. This is the most commonly missed step in scripted migrations; we handle it as a separate routing pass after the core record import.

Sage Intacct custom fields use the !-prefix in the REST API but not in the UI. We discover every custom field on every migratable object during schema mapping, apply the !-prefix during extraction, and map field values to corresponding Infor entity attributes or custom fields. Not all Sage Intacct objects allow the same number of custom fields (Customer, Vendor, and Items have limits); we validate field counts against the destination Infor edition's constraints before mapping and flag any overflow for customer decision.

Sage Intacct does not expose document attachments via the REST API for bulk export. We do not attempt to extract attachments as part of the standard migration scope. For organizations that require document continuity, we deliver a written recommendation for a parallel document migration strategy (SFTP file transfer, sharepoint extraction from Sage Intacct's document management, or Infor IDM upload). Invoice PDFs and signed documents should be extracted from Sage Intacct manually or via the vendor's export utility before the migration cutover date.