Migrate from FACT ERP.NG to Infor CloudSuite Corporate

Customer records in FACT ERP.NG carry addresses, contact details, GST/Tax IDs, credit limits, and payment terms. All standard fields migrate 1:1 to Infor. We preserve Customer-to-Sales-Order and Customer-to-Journal-Entry lookups so that account history is intact on day one in Infor. Credit limits and payment terms require mapping to Infor's credit control configuration fields. Any inactive customer flag from FACT becomes a Status field in Infor. The customer is loaded before any related transactional records so that parent-record lookup integrity is satisfied at the moment of transactional insert.

Supplier master records include bank details, tax registration, and payment terms. We map them to Infor's Vendor or Supplier object, preserving Supplier-to-Purchase-Order and Supplier-to-AP-invoice linkages. Bank details require mapping to Infor's payment setup fields. Tax registration numbers migrate to Infor's tax registration table. Supplier-to-PO lookups are resolved at migration time so that open purchase orders reference valid suppliers on first insert into Infor.

Items carry pricing, BOM links, serial number flags, and barcode data. Multi-level BOM rows are chunked individually and loaded with parent-item resolution. Serial and batch tracking fields require value-level mapping since Infor stores serial numbers in a separate register table rather than on the item master. Pricing migrates to Infor's price list structure. Items are loaded before Sales Orders and Purchase Orders so that line-item references are satisfied at the moment of transactional insert.

Sales Orders carry customer references, line items, pricing, taxes, and fulfillment status. We map each order header and its lines as a single transactional unit so that partial fulfillments are preserved in Infor. Open versus closed status flags determine the Infor order lifecycle state. Pricing and tax amounts are reconciled against the source FACT totals before insert. The customer reference is resolved against the Infor Customer lookup before order insert to avoid orphaned records.

Purchase Orders carry supplier references, line items, expected delivery dates, and GRN linkages. We preserve the header-to-line structure and flag any open versus closed PO status for Infor's PO lifecycle management. Supplier references are resolved against the Infor Supplier lookup before insert. GRN linkages migrate as a separate document reference note rather than a direct linkage since Infor's GRN model is separate from PO header. Expected delivery dates and payment terms are mapped from FACT's supplier parameters.

FACT ERP.NG uses a standard COA structure with account codes, descriptions, and account types. We map account codes directly and flag any account that carries a balance so that opening balances are posted correctly in Infor. Account type mapping (Asset, Liability, Equity, Revenue, Expense) is required. The GL Chart of Accounts is loaded before any Journal Entry import so that account references are satisfied. Accounts with active balances receive opening balance entries as the first journal batch in the migration sequence.

FACT ERP.NG posts payroll, AR, and AP directly to the GL via journal entries. These are date-stamped, source-referenced records. We extract them in date-range batches and map them to Infor's financial journal structure. Journal source references (payroll, AR, AP) are preserved as audit metadata. Because payroll journals are tightly coupled to the Payroll module in FACT, we enforce a sequencing dependency: Payroll migrates first, GL journals migrate second. This prevents orphaned debit/credit pairs and duplicate postings.

Inventory balances are maintained per warehouse per item. We migrate current stock positions, reorder levels, and warehouse assignments. Serial and batch tracking fields require value-level mapping since Infor stores serial numbers in a separate register table rather than on the item master. Warehouse codes in FACT are mapped to Infor's site or warehouse codes. Inventory quantities are reconciled against the GL trial balance before and after migration to catch any valuation discrepancies.

Fixed Asset records include acquisition cost, depreciation method, accumulated depreciation, and asset location. Depreciation schedules are generated per accounting period. We map asset registers and depreciation schedules to Infor's fixed asset module. Acquisition dates and depreciation methods (straight-line, declining balance) are mapped to Infor's depreciation profile configuration. Accumulated depreciation at the migration date is entered as an opening balance in Infor's asset register.

Employee records include salary components, tax deductions, EPF/CPF contributions, and leave balances. Payroll in FACT ERP.NG posts directly to the GL, creating a dependency chain we must resolve before the GL module migrates. Employee master data migrates before payroll transactions so that payroll references are satisfied. Compensation history may require review for Infor HCM compatibility; we migrate the current salary structure and statutory deduction configuration as the primary record and flag any historical payroll runs that require separate handling.

The CRM module holds Leads, Contacts, Opportunities, and Activities. We migrate all four as linked objects preserving the contact-to-opportunity relationship. Opportunity stage and owner assignment are preserved. CRM data migrates after Customer and before Opportunity so that the contact-to-account lookup is resolved. Activity records (calls, tasks, notes) migrate via Infor's activity APIs or bulk import with parent-record resolution. The Infor CRM module must be provisioned and configured before CRM data loads.

FACT ERP.NG's Configuration Only model stores business rules, workflow states, inventory matrix settings, and tax configurations as parameters rather than user-defined fields. We extract every active parameter as a configuration record, map it to an equivalent Infor setup table or custom field, and generate a configuration-replay script as part of the migration package. If parameters are skipped, Infor runs with default values, causing incorrect tax rates, pricing tiers, and approval workflows in production. We document every active parameter during discovery and validate the replay against source totals before sign-off.