Migrate from Focus ERP to Infor CloudSuite Corporate

Focus ERP's Chart of Accounts with parent-child hierarchies, account types, and segment columns migrates directly to Infor CloudSuite's GL Account table. We preserve account codes, descriptions, and any segment-column values as separate Infor CloudSuite dimension fields. Multi-segment account structures (e.g., Cost Center-Account-SubAccount) must be validated against the destination CloudSuite edition's dimension configuration, and we flag any that exceed the target's maximum segment count.

Focus ERP Customer master records with billing addresses, payment terms, and tax registration numbers map to Infor CloudSuite Customer and Bill-To entities. We deduplicate on customer name and primary billing address keys where multi-company Focus ERP instances may have created duplicate customer records. Tax registration numbers migrate as compliance fields; the destination tax code mapping must be confirmed against the CloudSuite edition's country-specific configuration before import.

Vendor master records from Focus ERP map to Infor CloudSuite Supplier records with associated address entities. Payment terms, bank details, and W-9 or equivalent tax forms are preserved as attachment records or compliance fields. We flag any vendor names containing non-standard ASCII characters before staging, as these will cause import failures in CloudSuite's SQL Server-based migration utility.

Outstanding payable and receivable records carry invoice numbers, due dates, and outstanding amounts. Partial payments, credit memos, and misaligned invoice dates require explicit resolution before import because Infor CloudSuite's invoice objects expect fully reconciled line items. We extract open items with full payment history, compute outstanding balances, and flag records requiring split-line treatment for the customer's confirmation before committing the load. Historical closed AP/AR migrates as GL journal entries rather than open invoice objects.

Focus ERP Item masters with SKUs, descriptions, cost prices, selling prices, and on-hand stock levels migrate to Infor CloudSuite Item records. Min/max replenishment rules and reorder point configurations are preserved as custom numeric fields in the destination because CloudSuite stores replenishment logic differently. We validate item UOM (unit of measure) against the destination's UOM class configuration and flag any that require conversion or new UOM class creation before the item import.

Open purchase orders migrate as Infor CloudSuite Purchase Orders with vendor, line items, quantities, and pricing. Historical (closed) POs migrate as reference records attached to the corresponding GL journal entries rather than as live order objects. Line-item tax codes and discount percentages vary by country configuration and require explicit value-mapping against the destination's tax regime before load, which we perform during the staging phase.

Open sales orders map to Infor CloudSuite Sales Order with customer, line items, pricing, and delivery dates. The order's status field maps to the destination order status workflow, and we preserve any ship-from warehouse assignment. Closed sales orders are migrated as historical reference records; we do not recreate closed order workflows in CloudSuite because the status transitions have already completed.

Focus ERP field-service and job-tracking records carry custom status workflows, technician assignments, and job-percentage progress fields. These map to Infor CloudSuite Work Order or Job entities depending on the CloudSuite edition. We preserve status values as custom fields and document the original workflow sequence for the customer's admin to re-implement in CloudSuite's process designer. Job-percentage progress migrates as a numeric field rather than a workflow state.

Asset registers include acquisition dates, depreciation methods, and book values. We extract the full depreciation schedule as-is, but depreciation recalculation must be performed in Infor CloudSuite based on its fiscal year settings and the depreciation convention selected during implementation. We preserve the original depreciation method and accumulated depreciation balance in custom fields to support the customer's accountant in verifying the CloudSuite-computed schedule.

Focus ERP's ability to allocate transaction data to different sub-divisions at specific ratios is a key customer customization. Infor CloudSuite does not have a native allocation-ratio field at the GL level. We capture ratio values at the record level and attach them as custom numeric fields in the destination division or department entity, then work with the customer to determine whether automated allocation rules should be rebuilt in CloudSuite's allocation engine post-migration.

Focus ERP user accounts, role permissions, and owner assignments export from the user table. Role naming conventions differ between Focus ERP versions and Infor CloudSuite's permission model, so we map role names to equivalent CloudSuite permission sets. We do not migrate role templates as code; the customer's Infor admin rebuilds permissions based on our role inventory document. Inactive users from Focus ERP can be imported as inactive users in CloudSuite for historical record ownership.

Custom fields added via Focus ERP's form builder are stored in extended tables. We extract these as key-value pairs and attach them as custom properties in the corresponding Infor CloudSuite object. Fields that reference lookups or conditional logic cannot be reconstructed automatically; we flag these and document the original logic for the customer's admin to re-implement post-migration.