Migrate from Epicor iScala to Infor CloudSuite Corporate

GL module in iScala holds chart of accounts, journal entries, and financial periods under the GL prefix. We map GL accounts and opening balances to Infor CloudSuite general ledger with multi-company accounts scoped by company code. Account structures in Infor are validated against the target company's fiscal calendar and currency setup. Historical journal entries migrate with full line-item detail; reversal entries and adjustment batches are flagged for the customer's Infor admin to post in the correct period.

SL manages customer records, open invoices, and AR. We migrate customer masters and outstanding invoices preserving payment terms, credit limits, and multi-currency assignments. Address and contact fields vary by iScala version; we normalize them to Infor's address structure during field-level mapping and flag any version-specific fields for manual review. Customer-to-branch assignments from iScala map to Infor's customer-address hierarchy.

PL handles vendor records, open AP aging, and purchase invoices. We extract vendor masters with payment terms, bank details, and multi-currency assignments. Open AP aging records migrate as unpaid invoices with original invoice dates and due dates preserved for Infor's AP aging reporting. Multi-currency purchase transactions require exchange-rate preservation at the time of each invoice; we store the original rate and document currency on the migrated AP record.

OR module contains order headers and lines with pricing, discounts, and fulfillment status. We migrate open and recent closed orders preserving line-level detail, quantity ordered versus quantity shipped, and any held or flagged status. Orders that span multiple iScala companies require split mapping with each order line assigned to the correct Infor operating unit. Attachment references on order headers are documented for manual reattachment post-migration.

PC manages purchase order headers, lines, and receipts. Open PO records and GRNI (goods-received-not-invoiced) entries require careful sequencing because iScala tracks GRNI within the PC module while Infor separates receiving from AP matching. We migrate open POs and flag GRNI items for the customer's Infor admin to reconcile during the AP-matching configuration phase. PO approval workflows do not migrate; we document the approval matrix for rebuild in Infor's workflow engine.

SC covers inventory items, warehouse locations, lot numbers, and serial numbers. We map stock balances by site and warehouse, BOM structures, and warehouse assignments. Lot and serial tracking flags are preserved as metadata on the item master. iScala's two-letter module prefix for BOM structures (MP module references SC items) requires cross-module coordination: we migrate BOMs as part of the MP phase after item masters are in place. Lot and serial current balances include receipt transaction history so traceability links remain intact in Infor.

MP module handles work orders, routings, and production schedules. We migrate work order headers, operations, and material allocations preserving routing sequences and labor standards. Routing codes from iScala's two-letter-prefix schema require field-level mapping to Infor's operation sequence structure. Work order status (released, in-progress, completed, closed) transfers directly; work orders with partial completions are flagged with a status note for the Infor production admin to close or adjust.

HR and PA modules store employee records, compensation history, and payroll runs. We migrate employee masters with demographic data, department assignments, and benefit enrollments as of the migration date. Effective-dated compensation records transfer as-is. Payroll processing rules, tax configurations, and deduction schedules do not migrate because Infor HCM uses a different payroll engine; we deliver a configuration guide for the customer's payroll admin to rebuild tax rules and deduction schedules in Infor CloudSuite HCM.

AM tracks fixed assets, depreciation schedules, and asset locations. We map asset masters with original cost, accumulated depreciation, and depreciation method (straight-line, declining balance, units-of-production). Asset-to-department assignments and cost center assignments are preserved for Infor's depreciation allocation reporting. Fully depreciated assets migrate with a closed status flag. Assets under finance lease and their corresponding liability accounts require separate cross-module mapping.

PR module stores project masters, WBS elements, budgets, and time entries. We migrate project headers and current budget balances. Detailed WBS element structures from iScala map to Infor's WBS hierarchy; complex WBS trees with multi-level rollups may require pre-creation of the project structure before line-item budget migration. Time entries migrate as activity records linked to the corresponding WBS element. Billing records and revenue recognition data migrate where the project billing method is time-and-materials; fixed-price project billing rules are documented for rebuild in Infor's project billing module.

The UD module contains custom fields attached to standard objects across GL, SL, PL, OR, PC, SC, MP, HR, and AM. UD field definitions and stored values vary by iScala version (2.2 through 2022.1), and the schema for UD field storage differs significantly between versions. We inventory all UD field definitions and their values during discovery against the target iScala version's UD table structure. Each UD field is mapped to either an Infor custom field (via Infor Mongoose), an extension table, or a User Area field in the target BOD. Any fields with no matching destination property are flagged for manual mapping review before migration begins.

iScala stores company-dependent data under company codes within a single database alongside company-independent system data. This is a high-severity schema dependency: records from different legal entities can be inadvertently merged if scoping is not explicit. We query company codes upfront from iScala system configuration, create a corresponding operating unit or legal entity in Infor CloudSuite for each source company, and apply per-company extraction filters to every table pull. Inter-company transactions migrate as Infor inter-company journal entries. Multi-site deployments map to Infor sites under each operating unit.