The Definitive Guide to Migrating to Infor CloudSuite

Infor was spun out of Systems & Computer Technology Corp in June 2002 as Agilisys, renamed Infor Global Solutions in 2004, and acquired by Koch Industries in 2020 ¹. Headquartered in Atlanta, it reports roughly 17,000 employees and 65,000-plus customers across industry-specific editions ¹.

CloudSuite is Infor's umbrella for industry-vertical ERP — Industrial (SyteLine lineage), LN (Baan lineage on AWS), Distribution, Financials, Food & Beverage, Aerospace & Defense, Healthcare and Public Sector. Unlike Oracle or SAP, Infor delivers pre-configured industry editions rather than one ERP configured for many industries.

The typical CloudSuite customer is a mid-market to upper-mid-market organisation — 200 to 5,000 employees — running discrete manufacturing, process manufacturing, distribution, equipment-heavy services, or public-sector financials. Compared with NetSuite, CloudSuite positions on industry depth and Infor OS as integration backbone; compared with SAP S/4HANA, on faster industry templates via Infor Deployment Accelerator (IDA).

The shapes of migration that actually land on CloudSuite tend to fall into four patterns. First, same-product cloud migrations — on-premise SyteLine, LN, M3 or Lawson customers moving to the matching CloudSuite edition on AWS. Second, legacy ERP exits from JD Edwards, Dynamics GP, Sage 100/300, IBM mainframe (VSAM) and homegrown systems, often with 10–20 years of financial history to reconcile.

Third, multi-entity consolidations, where an acquirer standardises subsidiaries onto a single CloudSuite tenant and harmonises chart-of-accounts segmentation across the group. Fourth, vertical realignments, where a generic ERP is replaced with an industry-specific CloudSuite edition to capture process traceability, batch genealogy or equipment management functionality the source platform lacked.

What makes migrating *to* CloudSuite easier than the category average is the Migration Utility — a SQL-Server staging pattern with predefined source-to-target sequences, Import Rule Definitions for type and value transformation, and a Preliminary/Final Data Transfer workflow that catches business-logic errors before they reach production ²³. Infor OS, ION and the Birst analytics layer mean downstream BI does not need a separate stand-up.

What makes it harder than the average is that every industry CloudSuite has a different schema — Industrial does not share table structures with Distribution or Financials, even though both run on Infor OS. Customisations from on-premise LN or SyteLine often have no SaaS equivalent, and Mongoose-framework extensions need to be re-pointed at the Infor Extensibility model before they survive the move.

Reports, ION workflows, Birst dashboards and Coleman AI assistants do not import — they are rebuilt against the new tenant. Teams that scope for the rebuild finish on time; teams that assume parity do not.

Industry CloudSuites share Infor OS but not their schemas — migrating to Industrial is not the same project as migrating to Distribution.

CloudSuite is not a single schema. Each industry edition — Industrial, LN, Distribution, Financials, Food & Beverage, Healthcare, Public Sector — exposes its own object catalogue inherited from its lineage (SyteLine, Baan/LN, M3, Lawson). The unifying layer is Infor OS — identity, ION, IDM, Birst analytics and Coleman AI across all editions.

Before mapping a field, you need to know which CloudSuite edition the row belongs in, which form (and underlying table) it lands on, and what serves as its unique key. The table below summarises master objects in a typical Industrial or Distribution migration; LN, M3 and Financials customers see the same conceptual objects under different table names.

Each industry CloudSuite ships with a defined catalogue of Business Object Documents (BODs) — Infor's canonical OAGIS-derived XML message contracts that ION uses to move data between applications ³⁷. Common BODs include Customer, Supplier, ItemMaster, BillOfMaterial, ProductionOrder, SalesOrder, Invoice and SecurityUserMaster. If you can produce a valid BOD, ION will route it; if your file does not map to a BOD field, ION cannot help.

Unique identifiers vary by table. Item ID, Customer ID, Vendor ID, Account ID and Order Number are user-assigned business keys whose mask (length, allowed characters, alphanumeric vs numeric) is configured per CloudSuite under General Parameters before the first import row is staged. Internal RowPointer GUID columns exist on every table but are platform-managed and not used as upsert keys ³.

Custom fields in CloudSuite are called extension fields or user-defined fields (UDFs). CloudSuite Industrial allows extension fields on most forms with these types: text, number, date, drop-list with enumeration, and lookup-validated references ⁶⁴. M3 exposes 20 UDFs per customer-order line — 10 alphanumeric up to 20 chars, 6 numeric, 3 date, 1 text — generated on form CMS082 before they can be populated ⁶⁶.

Relationships in CloudSuite are foreign-key driven and enforced at the form's business-logic layer rather than at the database constraint level — the Migration Utility uses sequence numbers to load tables in dependency order so referenced rows exist before the referring row is inserted ³. For example, Unit of Measure Codes must be defined before U/M Conversions; Account Classes must exist before Accounts; Customer Classes must exist before Customers ³.

Sites and Branches give CloudSuite Industrial its multi-entity model — each Site has its own currency, fiscal calendar and inventory ledger. Cross-site transactions reconcile through Inter-Site Distribution Orders; multi-currency Sites use either system exchange rates or fixed rates at the order level.

The single best predictor of a clean CloudSuite migration is how much work you do on the source side before the first Preliminary Data Transfer is fired. Infor's own field guidance is explicit: complete and post all open transactions in the source system, then cleanse and map every master record into the Migration Database — not after the import ⁷⁹.

Map and cleanse master data upfront — small inconsistencies in customer codes or UoMs cause big downstream issues in reporting and compliance.

Treat the source export as raw material that needs to be shaped to CloudSuite's expected formats — Customer and Item IDs conforming to the configured mask, dates in ISO format, currencies normalised to ISO-4217 codes, enumeration columns translated to the CloudSuite drop-list values, and UoM codes resolved to the codes defined in your tenant.

Source-side prep

• Complete and post all transactions in the source ERP — open invoices that have not been posted, unposted journal entries, in-transit transfers — so the Migration Database starts from a clean trial balance and a stable subledger ⁷⁹.
• Audit and dedup master data — customers, vendors, items, GL accounts. Watch for whitespace, case-only and currency-symbol duplicates that the Migration Utility will treat as distinct keys; cleansing is universally cheaper before the load than after.
• Lock the chart-of-accounts segment structure — segment count, segment lengths, allowed values — before any Account row is exported. Restructuring after CloudSuite has posted live transactions requires re-implementation work.
• Normalise UoMs, currencies and item codes — UoM codes must match the codes pre-defined in CloudSuite; mismatches block dependent loads of U/M Conversion, Item Cost and BOM rows ³. Currency codes resolve to the tenant's currency list; item codes must obey the configured Item Code mask.
• Decide what is in scope for historical transactions. Migrate only open AR/AP, last 12–24 months of GL detail, and the last 24 months of inventory transactions; archive older history through a side-by-side viewer or reporting warehouse rather than pushing it through the CloudSuite GL.

Destination-side prep

• Stand up the Migration Database on SQL Server — Infor's documented pattern is to migrate from the external application database into a CloudSuite Migration Database, validate against business logic, then copy target tables to the CloudSuite production database ³. The Migration Database can run on the same SQL Server as the source or on its own server.
• Provision users via Infor OS first, ideally with automated provisioning through Okta or Microsoft Entra ID — when a user is added in Ming.le, a SecurityUserMaster BOD is dispatched through ION and a matching user record is created in CloudSuite with group authorisations populated automatically ⁷¹. Owner-stamped record imports fail if the referenced user has not yet been provisioned.
• Pre-create financial settings — Companies, Sites, Currencies, Currency Rate Types, Fiscal Year and Periods, Account Classes, Posting Classes, Payment Methods and Cash Accounts — before the first Account import. The Account import depends on Account Classes existing first ³.
• Pre-create UoMs, Item Classes, Customer Classes and Vendor Classes — these drive default GL accounts, tax categories and posting rules on items, customers and vendors. Class-less master records inherit nothing and become a clean-up project on day two.
• Define ION BOD subscriptions — decide which BODs ION will publish, route or consume during cutover. ION Desk configurations have to exist before BOD-based loads can fire across applications ³⁷.

People prep

Cutover only works if finance and operations cooperate. Lock down a source-system freeze window — typically a weekend with the close already through the last open fiscal period — and communicate it to every department that touches AP, AR, inventory, production or shipping. Train AP clerks, AR clerks, planners, warehouse leads and the controller on CloudSuite's forms, the Outlook add-in, Ming.le navigation and Birst dashboards before go-live, not after.

A same-product cloud lift-and-shift from on-premise SyteLine to CloudSuite Industrial can run four to nine months; a re-implementation for a 100–300-user mid-market organisation runs six to fifteen months. Build the human runway accordingly.

CloudSuite exposes several load paths and the right one depends on dataset size, source system shape, and whether the data needs to ride across applications via ION. The Migration Utility covers the canonical industry-CloudSuite migration. Form-level CSV/Excel import covers smaller, table-targeted loads. ION-routed Business Object Documents handle programmatic, repeatable and very large loads. Third-party iPaaS sit on top of all of them.

Migration Utility (CloudSuite Industrial / Business)

The native migration tool for CloudSuite Industrial is the Migration Utility, configured through three forms: Import Source Tables (defines source-side tables and columns), Import Target Tables (defines destination tables and columns) and Import Steps (maps source-to-target with sequence numbers that drive dependency order) ²³. Predefined sequences ship for hundreds of common source-to-target mappings; you add additional sequences for source-specific tables.

The utility runs in two passes: Preliminary Data Transfer, which loads source rows into a staging table and validates against the target's business logic; and Final Data Transfer, which commits validated rows to production ³. If preliminary errors surface, the utility auto-suggests an Import Rule via the Import Rule Definition and Import Table Column Rule Definition forms ³.

Form-level CSV/Excel import (Excel Import, Import Journal Entries Bulk, dbimport)

Most CloudSuite forms expose a per-form Import action that accepts Excel and CSV. WMS Excel Import covers Item, Location, Customer, Supplier and Ship screens, validating against the same required-field rules as manual entry ¹¹³. Import Journal Entries accepts XML and CSV; Import Journal Entries Bulk accepts CSV only ²⁴. Lawson-lineage Financials uses dbimport; errors land in dbimportErr*.zip archives ³¹.

The right call: form-level import for one-shot loads of a few thousand rows on a single object, finance-led journal-entry loads (especially opening balances), and any table where the controller wants to see and approve the data in Excel before posting.

ION Document Flows and Mongoose Data Loader

Programmatic loads land through two paths. ION routes Business Object Documents (BODs) — for example ProcessSalesOrder, SyncItemMaster, SyncSupplier — via Document Flows configured in ION Desk ³⁷. Every CloudSuite application registers its services with ION so BODs are delivered to the right destination.

The Mongoose Data Loader is the second programmatic path, best suited to configuration data and smaller datasets — import templates run against the Mongoose framework that underpins CloudSuite Industrial forms. For very large extractions, practitioners report Compass queries, Pentaho-based ETL and Data Fabric data lake each have throughput and latency limits, so teams often stream through a SQL Server intermediate.

Third-party iPaaS and migration accelerators

Tools like Boomi, Microsoft SSIS, TIBCO Cloud Integration, Workato and Stacksync sit between the source system and CloudSuite. They are used in two ways: (a) ETL where the source database is extracted into a staging warehouse, transformed in SQL, then pushed into the CloudSuite Migration Database; (b) real-time iPaaS for ongoing sync post-migration. Infor Leap is Infor's own fixed-fee migration package for on-premise and single-tenant customers ¹²⁴.

Mapping is where every ERP migration earns its scars. The schema and sequencing decisions you make in your Migration Utility Import Steps determine whether the trial balance ties on day two, whether AR aging looks right on day five, and whether the warehouse believes the on-hand counts on day thirty.

Work top-to-bottom of the implementation order the Migration Utility's predefined sequences enforce: Companies and Sites → Currencies and Rate Types → Unit-of-Measure Codes → Chart of Accounts → Customer and Vendor Classes → Customers and Vendors → Item Classes and Items → BOMs and Routings → opening GL trial balance → open AR/AP → inventory quantity-on-hand → historical transactions if in scope ³⁷⁹.

Chart of Accounts and segmented dimensions

CloudSuite's Chart of Accounts varies by edition. Industrial uses Account + Unit Code with up to four unit-code segments. Financials (Lawson) uses Accounting Unit + Account Number with company, accounting unit and sub-account components. LN uses Group Company + Financial Company with dimensions 1–12 appended at posting. Pick the model that matches your edition and lock segment widths before the first Account import.

Export your demo Chart of Accounts to Excel, replace the demo rows with your own Account IDs, Account Types, Account Classes, Currency and Active flags, and import via the Chart of Accounts form. Get the segment count and lengths right before the first GL post — restructuring afterwards is destructive and effectively requires a re-implementation.

GL opening balances and fiscal cutover

Opening balances are loaded against the final adjustment period of the prior fiscal year — for example period 13 (adjustment) of FY2025 — carrying every balance sheet account's closing balance, with Income Statement accounts excluded so the period roll auto-closes them to Retained Earnings ¹⁴¹. Debits must match credits before the batch can be posted; if they do not, the journal will not release.

Multi-site organisations post the opening journal to a Migration Site or holding company rather than the operational sites, so the trial-balance reconciliation can be evidenced separately from live transactions. Sub-ledger opening balances (AR open invoices, AP open vouchers) are loaded next and reconciled to their control accounts; only then is the live fiscal period opened. CloudSuite Financials runs the same pattern through Lawson's General Ledger Interface.

Multi-currency and exchange-rate import

CloudSuite supports either the system exchange rate table (one rate set per period) or fixed rates at the order level, or a mix. Pre-load daily, monthly or per-period rates into the Currency Rates form before the GL opening balance is posted — multi-currency revaluation depends on rates being present at the right effective date.

Customers and vendors are maintained in foreign currency and translated to domestic currency at the configured rate type. Map source transaction_currency to Currency Code and source transaction_rate to either the system rate table (preferred) or a per-document fixed rate — mixing both on the same Site without documentation makes period-end revaluation unauditable.

Item Master, UoM, and inventory valuation

Item Master loads have the strictest dependency chain: UoM Codes → U/M Conversions → Item Masters → Inventory Receipts or BOM rows ³. The Migration Utility's predefined sequence enforces this; custom sequences that skip a step fail with cascading Data is invalid errors that point at the dependent row, not the missing parent.

Map source item code to Item ID, description to Description, UoM to U/M (resolved against the pre-loaded UoM table), and source cost method to Cost Method — Industrial supports Standard, Average, FIFO and LIFO valuation; LN and M3 add Actual costing variants. Item Class drives the default GL accounts (Inventory, COGS, Variance) and must exist before item rows arrive.

Opening quantity-on-hand is loaded after items are created, via Inventory Receipts or the equivalent opening-balance form. Post receipts against a non-COGS clearing account so the GL entry is neutral — the opening trial balance has already captured inventory value through the GL journal, and receipts only re-establish unit quantities. Mixing these without a clearing account double-posts inventory into the GL.

BOMs, Routings and manufacturing master data

BOM rows load against the BOM form on Manufacturing CloudSuites (Industrial, LN, Food & Beverage, Aerospace) and reference Item IDs that must already exist as Stock Items with a Base UoM matching the BOM operation UoM. Typical mapping: bom_id → BOM ID, bom_revision → Revision, parent_item → Item ID, component_item → Component ID, component_qty → Quantity Per, effective_date → Effective Date.

Routings, Work Centres and Operations follow the same pattern: Work Centres before Operations before Routings before Standard Costs. Production order history is typically *not* migrated to CloudSuite — only open work orders at the cutover date, plus 12–24 months of closed-order history if the operational lookback is contractual. Older production history stays in a side-by-side viewer.

Open AR / AP documents

Open AR invoices, credit memos, debit memos and deposits are loaded against AR Invoice with Apply-To chains preserved — a credit memo's Apply-To Document points at the invoice it offsets, and that invoice must already exist in the load. Open AP vouchers follow the same pattern through AP Voucher, with bank-account, payment-method and discount-terms fields resolved against pre-loaded reference data ¹⁴¹.

Cash payments and direct debits in CloudSuite Industrial come into AP through a BankStatement BOD received from Infor Local.ly GEMS — historical payments are not migrated; only open un-applied cash is loaded against AR/AP so post-go-live application can complete normally ¹⁴¹.

Historical activities, notes, documents and email/call history

CloudSuite does not have a generic activity-timeline object the way a CRM does; engagement history lives across CRM Cases (CloudSuite CRM), Outlook integration entries (Microsoft Outlook Add-in), and IDM document attachments. The Outlook add-in propagates emails and calendar entries forward, but it does *not* backfill history — sales calls and customer emails older than the cutover are typically left in the source system as a read-only archive ³³.

Notes and freeform text on master records are loaded via the Rich Text editor field on the relevant form, which supports bold, italic and colour formatting ⁹². Bulk-loading notes through the Migration Utility works for short, plain-text values; HTML-rich content needs to be pre-processed because CloudSuite's rich-text editor sanitises styles that fall outside its allowed list.

Files and attachments — IDM and on-premise migration

Attachments do not bulk-load through the Migration Utility. The supported path is Infor Document Management (IDM), where each Document Type is defined first under Document Types, then files are uploaded inline through the Document Attachments form or programmatically via the IDM Utilities Tool ¹⁰²¹¹⁰. Document size cap is 250 MB per file ¹⁰⁴; very large estates keep originals in S3 or SharePoint with a deep link stored in an extension URL field.

On-premise customers migrating files to multi-tenant CloudSuite use the Site File Migration process: files are packed via the System Information form, written to the CORE_FILEMANAGEMENT.SITEFILEMIGRATION table, restored in the multi-tenant environment and unpacked back through System Information ¹⁰¹. Attachments held in O&R providers migrate by copying from the O&R provider to an IDM provider.

Audit trail, ownership and original timestamps

Standard Created, Modified, RowPointer and RecordDate columns on CloudSuite tables are platform-managed and stamped to the import date — they cannot be overwritten through the Migration Utility's normal sequences ³. If the original audit trail matters for compliance, add extension fields *Legacy Created Date*, *Legacy Modified Date* and *Legacy Created By* on the relevant forms and populate from source. The City of New Orleans BRASS migration used this pattern to preserve 20 years of grant data.

Audit Log itself is enabled per form on the Process Defaults form (set Enable Audit Logging = 1) and tuned through Audit Log Types to record only the messages your compliance team needs. Enable audit logging *after* the Final Data Transfer completes — otherwise the migration's own inserts flood the audit log and obscure live change history.

Owner references on master records resolve against the user table populated by the Infor OS SecurityUserMaster BOD ⁷¹. If a user identifier on a source row does not exist in CloudSuite at import, the field is set blank rather than the row being rejected — pre-provision every owner, or build a dummy migration user and re-stamp ownership once real users go live.

Validation is the bridge between the Final Data Transfer finishing and users being allowed in. Infor's documented pattern is three-stage: Preliminary Data Transfer with business-logic validation in the Migration Database, Final Data Transfer with target-table reconciliation, and a 30-day post-go-live audit with finance, planning and shipping leads each verifying their own master records ³.

Build a reconciliation queries spreadsheet that compares source and destination on each of these counts. Anything outside a 0.5% variance gets investigated before users get login access.

• Trial balance per company per period — sum of debits and sum of credits per account per period must match the source's closing balance.
• AR aging by customer and bucket — total open AR, count of open invoices, oldest open invoice age — must reconcile to the source AR sub-ledger.
• AP aging by vendor and bucket — total open AP, count of open vouchers, voucher-to-PO match status.
• Inventory valuation per site per item class — sum of (on-hand × unit cost) per item class must match the GL Inventory control balance.
• On-hand quantities per Site per Item — full-list comparison; flag any item where source QoH ≠ destination QoH.
• BOM coverage and component completeness — count of active BOMs, count of components per BOM, items referenced as components that do not exist as Item Masters.
• Open sales orders, purchase orders and work orders — count, total value, association to Customer/Vendor/Item.
• User and role completeness — every CloudSuite user has at least one role assigned, every role has at least one form authorisation.

Run a manual spot-check on top of reconciliation: pick 30 random master records across Customers, Vendors, Items, Accounts and BOMs and verify each field against the source UI. Trace the full transaction graph on five high-value open orders. If a non-trivial discrepancy shows up in three or more, halt the load, fix the cause via Import Rule Definition, and re-run the Final Data Transfer against the affected sequence only ³.

Rollback in CloudSuite is not a single bulk-undo button. The standard fallback is to keep the source ERP fully operational through cutover, export the destination's pre-go-live state to a tenant snapshot, and stamp every migrated row with a *Migration Batch ID* extension field. If catastrophe strikes within the hyper-care window, delete by Migration Batch ID and re-import from the cleaned source.

Cutover sequencing: (1) source goes read-only after final period close; (2) final delta export captures every change since the dress rehearsal; (3) delta runs through the Migration Utility; (4) reconciliation runs end-to-end and finance signs off on the trial balance; (5) ION Document Flows are activated; (6) users get login access with a 48-hour hyper-care window; (7) source decommission is scheduled 30 to 90 days out, never the same day.

The Infor Partner Network (IPN) is the official partner channel for CloudSuite implementations ¹²³. Partners are tiered by certification and industry expertise; Infor publishes the directory through the Partner Finder. Infor Leap is Infor's own fixed-fee, fixed-timeline migration package, currently aimed at on-premise and single-tenant customers moving to CloudSuite ¹²⁴.

On the iPaaS and ETL side, Boomi, Microsoft SSIS, TIBCO Cloud Integration, Workato and Stacksync all have CloudSuite connectors. Their role in a migration is rarely the migration itself — it is the staging layer between source ERP and the CloudSuite Migration Database, the transformation layer that resolves Y/N flags and translates currency and UoM codes, and the ongoing-sync layer post go-live.

Managed-migration cost ranges vary widely. A same-product lift-and-shift from on-premise SyteLine to CloudSuite Industrial for a 20–100-user organisation typically runs $100K–$300K; a mid-market re-implementation $400K–$1.2M; an enterprise re-implementation $800K–$3M+; a global multi-site phased rollout $1.5M–$6M+. The upper end is driven by site count, integration complexity and the number of legacy reports being rebuilt.

For teams that want to outsource the migration end-to-end, FlitStack specialises in Infor CloudSuite migrations and handles the Migration Utility sequencing, source-to-target mapping, ION BOD configuration, GL opening-balance reconciliation, and validation work described in Sections 5 and 7 of this guide. Pricing is fixed-fee, based on record count and source platform, with separate line items for CloudSuite edition complexity (Industrial / LN / Distribution / Financials) and historical-data depth so the scope is transparent before signature.

This is one of several legitimate paths — the right choice for any given team depends on whether they want an Infor Partner Network firm, Infor Leap's fixed-fee programme, an iPaaS-first approach, or a specialist migration vendor. Explore FlitStack →