Migrate from inoERP to Infor CloudSuite Corporate

inoERP stores the full chart of accounts with account types, currency assignments, and current balances in the GL module. We export account codes, descriptions, types, and balances and map them to the Infor CloudSuite LN or M3 GL account structure. CloudSuite GL accounts require an Accounting Entity assignment that must exist before account import; we coordinate the account code format (segmented vs flat) with the destination Chart of Accounts configuration during scoping. Currency assignments migrate to the Multi-Currency setup if the organisation operates across multiple legal entities.

inoERP journal entries include header-level metadata (journal batch number, posting date, reference) and line-level debit/credit amounts with account assignments. We extract all posted entries and map them to CloudSuite journal entry format. Entries with non-standard currency or split-currency transactions are flagged as requiring manual review before posting because CloudSuite enforces stricter currency reconciliation rules than inoERP. Closed accounting periods in CloudSuite are locked and cannot receive entries; we verify period status before each journal import batch.

Open AR and AP subledgers in inoERP include customer and supplier party records, invoice headers, line items, and payment terms. We extract open invoices by status and map inoERP party structures to CloudSuite customer and vendor masters. inoERP's flat party model (where a supplier and customer may share a single party record) must be split into separate customer and vendor records in CloudSuite. Open invoice line items migrate with header-level tax and discount distributions preserved as separate distribution lines. Paid and voided transactions are flagged for selective migration based on the customer's reporting retention policy.

inoERP tracks items with UOM, cost layers, category hierarchies, and on-hand quantities across multiple inventory locations. We export item definitions, on-hand balances, and location assignments. Lot and serial number tracking migrates to CloudSuite's lot/serial control if the destination is configured with those features. Phantom BOM components and non-stock items map to item types that CloudSuite requires as pre-import setup. Item cost layers (FIFO, standard, average) must align with the destination cost method configuration before on-hand balances load.

Open sales orders in inoERP contain header fields (order date, terms, party reference) and line items (item, quantity, price, warehouse). We export order status so that open orders map to CloudSuite Sales Order with line scheduling. Closed orders migrate as historical records to the order history table rather than as active transactions. Pricing, discounts, and freight charges from inoERP line items map to CloudSuite price detail fields. Warehouse assignment in inoERP must exist in CloudSuite as a valid site before the order header imports.

Open purchase orders in inoERP map to CloudSuite PO with vendor assignment, line items, and receipt scheduling. inoERP's approval workflow status (draft, submitted, approved) migrates to CloudSuite's PO workflow states. Closed purchase orders are archived selectively based on the customer's retention policy. inoERP purchase agreements and contract prices map to CloudSuite Blanket PO or Vendor Contract records if those features are active in the destination configuration.

Work orders in inoERP include routing steps, material issues, resource transactions, and completion records. The WIP ledger aggregates costs per work order. We extract the full work order history but note that inoERP's dynamic pull system means WIP values reflect real-time demand conditions that may not be stable in CloudSuite. Active work orders with material and routing data migrate as Work Orders in CloudSuite LN with the BOM and routing references resolved from the BOM migration phase. WIP balances migrate as cost layer entries against the Work Order rather than as independent subledger records.

inoERP BOMs and routings define product structure and manufacturing steps with super BOMs and multi-level hierarchies. We export the full BOM hierarchy and routing sequence. Phantom BOMs and co-products map to CloudSuite BOM component types (phantom, regular, feature) that require pre-import configuration. Multi-level BOMs are flattened or kept hierarchical based on the destination CloudSuite variant (LN supports deep multi-level; M3 uses recipe-based structures). Routings with work centres and labour rates map to the Routing Master in LN with sequence, work centre, and setup/run time fields populated.

inoERP HR includes employee profiles, job definitions, positions, compensation records, leave balances, and approval hierarchies. We extract employee data and position assignments. Compensation records migrate to CloudSuite HR with base salary, pay grades, and compa-ratio data preserved. Leave balances and approval hierarchies flag for manual verification because CloudSuite HR uses a different approval routing model. inoERP job and position structures map to the CloudSuite position management setup, and org chart hierarchies require a separate org structure configuration that is scoped as a post-migration admin task.

inoERP payroll generates electronic bank files for direct deposit in customisable formats. We export payroll registers, leave balances, and compensation history. Bank file formats are customisable via JavaScript REST APIs and do not migrate directly because CloudSuite uses its own payroll bank file generation tied to the payroll configuration. Pay groups, deduction codes, and tax authority assignments require manual configuration in CloudSuite HR before payroll registers can be processed. We deliver the compensation history and leave balance data in a format the CloudSuite payroll team can import after configuration.

Asset registers in inoERP include acquisition details, depreciation schedules, and asset categories. We export the full asset record including book values and accumulated depreciation. Depreciation methods (straight-line, declining balance, units of production) migrate to CloudSuite Fixed Asset setup, and open depreciation runs in inoERP are flagged as requiring a final depreciation run before cutover. Asset assignments to cost centres and locations map to the CloudSuite asset location and assignment registers. Fully depreciated assets are migrated with a status flag to prevent post-migration depreciation calculation errors.

inoERP uses role-based access control with users, roles, and permissions in the Admin module. We export user accounts and role assignments. CloudSuite security is role-based with function security and data security layers that require a different permission model from inoERP's flat RBAC. We map inoERP role names to the closest CloudSuite role equivalents but flag that permission matrix rebuild is a separate post-migration admin task because CloudSuite's granular function security does not have a direct inoERP equivalent. Users must be provisioned in CloudSuite before any Owner references on migrated records can resolve.

inoERP stores document links as local file paths in its CMS module. We do not migrate binary attachments or file references because inoERP attachment paths point to self-hosted file systems that do not exist in CloudSuite. Customers should migrate file references separately using a document management strategy, either by configuring Infor IDM post-migration and uploading files manually, or by maintaining a shared file store and reattaching documents after CloudSuite configuration. We document every attachment path encountered for the customer's reference during manual file migration.