Migration Checklist: Moving to Infor CloudSuite

Phase 0

Decide & Plan

Lock the decisions that scope every downstream phase — which CloudSuite, what moves, who owns it.

• Confirm which CloudSuite industry edition is under contract. Document the exact edition — CloudSuite Industrial (SyteLine lineage), CloudSuite Industrial Enterprise (LN lineage), CloudSuite Distribution, CloudSuite Financials, CloudSuite Food & Beverage, CloudSuite Aerospace & Defense, CloudSuite Healthcare, CloudSuite Public Sector, CloudSuite Service Management. Edition controls the underlying schema, the available forms, and which BODs are wired by default.

  Risk if skipped: Building a migration plan against the wrong CloudSuite edition surfaces missing tables and undefined BOD flows only after data is staged.

• Confirm the deployment model and AWS region. Capture whether the target is multi-tenant SaaS on AWS, single-tenant, or hybrid. Record the AWS region for residency, the Infor OS tier (Essentials, Professional, or Enterprise), and the tenant URL.
• Define migration scope by module and master object. Document every in-scope object: GL accounts, sites, warehouses, customers, vendors, employees, items, BOMs, routings, work centers, open AR invoices, open AP vouchers, open sales orders, open purchase orders, open jobs/projects, fixed assets, attachments. Mark each as full-history, open-only, or out-of-scope.

  Risk if skipped: Undocumented scope around historical AR, AP, and production transactions is the single biggest cause of cutover slippage in CloudSuite projects.

• Decide how many years of historical transactions migrate. Pick a cutoff — typically open documents plus one to three closed fiscal years. Document the date and the rationale. Anything older stays in the legacy system as read-only reference.

  Risk if skipped: Migrating decades of closed transactions inflates the migration database, slows the data transfer, and stretches reconciliation with no operational payoff.

• Anchor cutover to a fiscal period boundary. Schedule go-live for the first day of a new fiscal year or, at minimum, the first day of a clean period. CloudSuite opening-balance journals are simpler when the cutover lands on a period boundary.

  Risk if skipped: A mid-period cutover forces partial-period journals and double-counts revenue and expense across the legacy and new ledgers.

• Document legal-entity and site rollout sequencing. Decide whether all sites/legal entities go live together or in waves. CloudSuite supports multi-site, multi-legal-entity tenants; phased rollouts are common when entities span geographies.
• Identify residency and compliance constraints affecting the tenant. Capture GDPR data residency requirements, SOC2 evidence retention, HIPAA log requirements for CloudSuite Healthcare, FedRAMP requirements for CloudSuite Public Sector, and industry retention rules that bind tenant region and snapshot policy.
• Assign a single accountable owner for the migration. Name one DRI plus named leads for finance, supply chain, manufacturing, projects, IT/Infor OS, and end-user enablement. Cross-team decisions route through the DRI.
• Document explicit go-live success criteria. Write down what must be true to declare cutover complete: trial balance ties to source within a defined tolerance, AR/AP aging matches by customer/vendor, item on-hand reconciles by warehouse, open SOs and POs all loaded, BOD message flow active.
• List out-of-scope items in writing. Examples: legacy custom reports, terminated employees beyond retention, closed jobs older than cutoff, archived attachments beyond 250 MB per file. Circulate the list to every stakeholder.

  Risk if skipped: Items not explicitly out of scope reappear as last-minute demands during sandbox testing.

Phase 1

Pre-Migration Prep

Configure the destination tenant, cleanse the source, and prepare the people side before any byte moves.

Phase 2

Source Export

Pull every byte you will need out of the source — completely.

• Export the full chart of accounts as CSV. Include account number, description, account type, account category, active flag, and any financial dimensions that segment the account.
• Export site, warehouse, and stockroom master data. Capture the location hierarchy that downstream items, inventory, and transactional records will reference.
• Export the customer master with all standard and custom fields. Include customer number, legal name, tax ID, bill-to and ship-to addresses, credit limit, payment terms, currency, and any extension fields.
• Export the vendor master with all standard and custom fields. Include vendor number, legal name, tax ID, remit-to addresses, payment terms, 1099 status, default currency, and extension fields.
• Export the item master with all standard and custom fields. Include item number, description, item class, primary UoM, planning code, lot/serial flags, valuation method (Standard, Average, FIFO), and source standard/current cost values.
• Export BOMs and routings for every active manufactured item. Capture component item, quantity per, scrap factor, operation sequence, work center, setup time, run time, and any tool or resource references.
• Export work centers, resources, and shift calendars. Required by routings and capacity planning. Without these, routing imports fail referential integrity checks.
• Export open AR invoices with full line detail and aging. Include invoice number, customer, original date, due date, currency, original and open amount per line, applied credits, and any retainage.
• Export open AP vouchers with full line detail and aging. Include voucher number, vendor, GL distribution per line, terms, due date, currency, and any 1099 box assignments.
• Export open sales orders with line detail and shipment status. Include SO number, customer, requested and promised dates, line item, ordered qty, shipped qty, backorder qty, unit price, and any blanket or contract reference.
• Export open purchase orders with line detail and receipt status. Include PO number, vendor, requested date, line item, ordered qty, received qty, unit cost, and any blanket reference.
• Export inventory balances by item, site, warehouse, and lot/serial. Capture on-hand, allocated, and available quantities along with current cost per location.

  Risk if skipped: Missing lot or serial granularity on export forces a full physical recount at cutover.

• Export fixed-asset master and current depreciation balances. Include asset class, in-service date, cost basis, accumulated depreciation, depreciation method, life, and salvage value.

  Risk if skipped: Missing prior accumulated depreciation forces a full asset revaluation against the source after go-live.

• Export the historical GL trial balance through cutover. Capture period-by-period closing balances per account and dimension combination. This feeds the opening-balance journal in Phase 3.

  Risk if skipped: An incomplete trial balance export prevents the opening journal from tying to source and blocks Phase 6 reconciliation.

• Export attachments and the metadata that links each file to its parent record. Pull the binary plus a mapping CSV of file name, parent object, parent key, document type, and original upload date.
• Export the user list with roles, group memberships, and reporting structure. This feeds Ming.le user provisioning and the SecurityUserMaster BOD payloads in Phase 5.
• Capture configuration snapshots of source automations, reports, and dashboards. Screenshot or export legacy workflows, reports, and dashboards. These will be rebuilt as Birst dashboards, ION flows, and CloudSuite forms; they do not migrate.
• Record the exact timestamp of every export. Note the cutoff time for each file so the Phase 5 delta export is bounded precisely.

Phase 3

Transform & Map

The data-engineering core — produce CloudSuite-shaped files from raw source exports.

Phase 4

Sandbox Test Migration

Catch every problem in the sandbox before it costs you in production.

• Load a 1–5% representative sample of each object into the sandbox. Use the Migration Utility's Preliminary Data Transfer to move a slice of every in-scope table through the configured sequences.
• Run the Preliminary Data Transfer for the full sequence. The Migration Utility's Preliminary Data Transfer validates each Import Step against the target's business logic without committing to production tables.

  Risk if skipped: Skipping Preliminary in favor of Final Data Transfer deletes the TargetDL load table on rerun and discards every manual correction.

• Validate field-by-field on 10–20 random sandbox records per object. Open each record in the CloudSuite UI and compare against the source export. Watch for truncation, picklist mismatches, and silent NULL drops.
• Test boundary cases explicitly. Long strings, special characters, leading/trailing whitespace, NULL handling, datetime timezone boundaries, max-length descriptions, and unicode in customer/vendor names.
• Test the BOD flows that fire on data insert. Confirm that inserts of customers, items, and orders fan out the expected BODs through ION (SyncCustomerPartyMaster, ProcessSalesOrder, etc.) and that subscribers receive them.
• Validate parent-child references on a sample. Spot-check site/warehouse links on items, BOM components on parent items, SO/PO lines on headers, and AR invoices on customers.
• Test attachment uploads end to end against IDM. Confirm files up to but below 250 MB upload, link to the parent record, and round-trip through the IDM viewer and the Document Attachments form.

  Risk if skipped: Files at or above 250 MB fail silently and leave the parent record with a broken attachment link.

• Run a full-volume test or the largest sample the sandbox permits. Time the load and extrapolate to production. Use the result to validate that the cutover window is realistic.
• Have domain experts spot-check sandbox data against the source. Pull a Finance lead, an Inventory lead, a Sales lead, and a Production lead into a sandbox review. They will catch issues that look fine to a migration team but wrong to a daily user.
• Investigate every row that lands in TargetDL with ErrCode <> 0. Per the Migration Utility, invalid rows are written to the TargetDL load table with a non-zero ErrCode. Query SELECT * FROM TargetDL_[table]Load WHERE ErrCode <> 0 and correct the data or the rule before the Final Data Transfer.
• Document the sandbox throughput by table. Record rows per minute for each significant table. This feeds the cutover plan in Phase 5.
• Sign off the sandbox test results in writing before proceeding. Migration sponsor, finance lead, and operations lead all sign off. No sandbox sign-off, no production cutover.

  Risk if skipped: Skipping sandbox sign-off ships sandbox-only bugs straight into production.

Phase 5

Production Cutover

The migration itself — a tightly sequenced execution window with named owners per step.

• Confirm the source-system freeze. Verify no new writes have landed in the source for the last hour. Lock down user accounts on the source if necessary.
• Take a final full export of source data. Capture the delta from the Phase 2 baseline. Note the export timestamp.
• Disable non-essential BOD subscriptions and ION flows. Pause outbound BOD flows that would fan inserts out to email, notification, or third-party subscribers during the bulk load.

  Risk if skipped: Active outbound BODs during bulk insert spam every downstream system with cutover-day noise.

• Take a pre-load snapshot of the CloudSuite migration database. This is the rollback point if a critical step fails partway through cutover.
• Provision users in Ming.le and let SecurityUserMaster BODs propagate. Per the BOD flow, adding users in Ming.le sends SecurityUserMaster BODs to the CloudSuite application; user records, group authorizations, primary email, and Workstation Domain/ID are populated automatically.
• Load reference codes first. UoM codes, currencies, payment terms, tax codes, country and state codes. These have no dependencies and unblock every downstream load.
• Load UoM conversions after UoM codes. Per the documented sequence, UoM conversions require their base UoM codes to exist first.
• Load the chart of accounts and dimensional structure. GL accounts, sites, warehouses, subaccounts, branches per the licensed edition's model. Required before any transactional load.
• Load the customer and vendor masters. Master parties must exist before any AR, AP, SO, or PO can attach to them.
• Load the item master, then BOMs, then routings. Items first, then dependent BOMs and routings. Production orders, MRP, and inventory cannot resolve without all three present.
• Load opening inventory balances by item, site, and warehouse. Apply the chosen valuation method per item. Confirm on-hand totals equal the Phase 2 baseline before proceeding.
• Post the GL opening journal as of cutover date. Confirm debits equal credits before posting and that the journal posts to the correct period. The opening trial balance must tie to the source within tolerance.

  Risk if skipped: An unbalanced opening journal aborts the post and blocks every downstream subledger reconciliation.

• Load open AR invoices, then open AP vouchers. Use idempotent upserts keyed off document number so reruns do not duplicate.
• Load open sales orders and open purchase orders. Maintain shipped/received quantities so remaining quantities flow correctly into MRP and ATP from day one.
• Load attachments and link to parent records via IDM. Honor the 250 MB per-file cap. Capture upload IDs in the mapping CSV so a failed link can be re-pointed without re-uploading the binary.
• Cross-check destination row counts against source row counts at every step. Maintain a running reconciliation spreadsheet. Stop and diagnose any non-zero delta before moving to the next step.
• If a load step fails partway, run the Final Data Transfer corrected. Per the Migration Utility documentation, after correcting data in the TargetDL load table, clear the Source Data Imported field and rerun Final Data Transfer — never Preliminary, which would wipe the corrected load table.

  Risk if skipped: Rerunning Preliminary after manual correction deletes the corrections and forces a full redo.

• Copy the migration database tables to production after every step passes. Per Infor migration guidance, the final step copies target table data from the migration database to the production database. Do this only after Phase 6 sign-off on the migration database.
• Reactivate ION flows, BOD subscriptions, and integrations. Resume outbound BOD flows, Birst extracts, and third-party integrations only after the production database loads complete and Phase 6 starts.

Phase 6

Validate

Prove the migration was correct. Do not let users in until this phase passes.

• Reconcile the trial balance to the source within tolerance. Run the CloudSuite trial balance as of cutover date and compare line by line to the source. Investigate any variance beyond the agreed materiality threshold.

  Risk if skipped: A trial balance variance that goes unresolved compounds every subsequent close and is exponentially harder to fix later.

• Reconcile AR aging by customer to the source. Confirm total open AR, per-customer balance, and aging bucket distribution match the source within tolerance.
• Reconcile AP aging by vendor to the source. Confirm total open AP, per-vendor balance, and aging bucket distribution match the source within tolerance.
• Reconcile on-hand inventory by item, site, and warehouse. Quantity-on-hand must match source for every item-location pair. Variance triggers an inventory adjustment journal before users log in.
• Reconcile open sales orders and open purchase orders by header. Count and remaining-quantity match the source baseline. Investigate any missing or extra documents before allowing order entry.
• Reconcile total record count per object: source vs. destination. Customers, vendors, items, BOMs, routings, work centers, fixed assets. Any non-zero delta gets investigated and documented.
• Field-by-field check on 25–50 randomly selected records per object. Pull random records across customers, vendors, items, AR invoices, AP vouchers, SOs, POs. Compare every field including extension fields against the source.
• Verify extension-field values arrived on a representative sample. Confirm extension fields carry the expected values and respect Required, Read Only, and enumeration constraints.
• Validate parent-child relationships on a sample. BOM components on parent items, SO/PO lines on headers, AR invoices on customers, attachments on parent records.
• Validate BOD flows fire as expected on cutover-day test transactions. Create a test customer, item, and sales order in the destination. Confirm SyncCustomerPartyMaster, ItemMaster, and ProcessSalesOrder BODs route correctly through ION to every active subscriber.
• Verify the historical timestamp strategy held. Confirm that the extension field carrying legacy created/modified dates is populated where the Phase 3 decision called for it.
• Run a residency and compliance audit against the loaded data. Verify the production tenant is in the agreed AWS region, that GDPR/HIPAA/SOC2/FedRAMP controls relevant to the edition are active, and that any required audit logs are enabled.
• Enable Audit Logging on the production tenant. In Process Defaults, set Enable Audit Logging to 1 and configure Audit Log Types so post-cutover changes are tracked from day one.
• Have power users validate day-to-day workflows in the destination. Pull 3–5 power users per functional area through their actual workflows against the migrated data. Document every issue surfaced.

  Risk if skipped: Skipping UAT pushes workflow defects into general release where they multiply support tickets and erode end-user trust.

• Document every UAT-surfaced issue and decide go/no-go per item. Triage into block-go-live, fix-day-one, and tracked-backlog. Block-go-live items must close before sign-off.
• Get written go-live sign-off from the migration sponsor. Finance, operations, and IT leads attach their sign-off. Without sign-off, do not flip user access.

  Risk if skipped: Going live without sponsor sign-off transfers the migration risk to the unprepared end-user community.

Phase 7

Post-Migration Cleanup

Wrap up so the team moves on and the destination becomes the source of truth.

• Broadcast go-live to all users with Ming.le login instructions. Include the Infor OS Portal URL, login steps, the where-to-get-help contact, and links to recorded training.
• Run role-segmented refresher training in the first week. AP, AR, GL, inventory, planning, sales, and production users each get a focused walkthrough of their daily flows in the live system.
• Set the source system to read-only. Lock writes on the source. Communicate the read-only date and the retention horizon.

  Risk if skipped: Leaving the source writable invites parallel data entry that fragments the new system of record within days.

• Rebuild reports and dashboards in Birst. Legacy report definitions do not transfer. Rebuild the prioritized MoSCoW list — Must-have reports first, Should-have next, Could-have as backlog.
• Rebuild automations in ION Desk and Coleman. Legacy workflows do not migrate. Rebuild business event monitors, alerts, and document flows in ION Desk; build conversational flows in Coleman where applicable.
• Re-establish integrations to downstream systems. Reactivate BOD subscriptions to third-party systems (CRM, WMS, BI tools), calendar and email sync, and any data-fabric extracts the Data Lake feeds.
• Update IDM document policies and retention rules. Confirm document type policies, retention horizons, and any classification labels are in place on the production tenant.
• Schedule a 30-day post-migration retrospective. Capture what went well, what bit hardest, and the backlog of follow-ups. Feed lessons into the next site/legal-entity rollout if the migration is phased.
• Set the source-system decommission date. Typically 90 days after cutover, after the final retention window. Document the date and the archival storage location for source exports.
• Archive source-system data exports to long-term storage. Keep the raw Phase 2 and Phase 5 exports plus the mapping spreadsheets in WORM-style storage in case of audit or forensic need.

  Risk if skipped: Deleting source exports before the retention horizon eliminates the only forensic record if a post-cutover dispute surfaces.

• Close out the migration project formally. Final status report, lessons-learned document, sign-off on the project closure. Release the migration team back to BAU.