Migrate from Open-Prod to Infor CloudSuite Corporate

Open-Prod customer records map to Infor CloudSuite Customer in M3 or Account in CloudSuite Industrial. The customer name, address, tax ID, and payment terms migrate directly. Customer balance and credit limit require reconciliation because Open-Prod may carry aged balances that CloudSuite distributes across AR sub-ledger records. We stage the customer master in the CloudSuite migration database first because all downstream records (orders, projects, service tickets) have a Customer foreign key.

Open-Prod item records (product details, pricing, unit of measure, SKU) map to Infor CloudSuite Item or Product. Unit of Measure Codes must be migrated before Item records because Items reference UOM in their product structure. We flag any Open-Prod variant structures (size/color matrices, BOM-linked items) for explicit mapping because CloudSuite stores variants differently depending on whether the customer uses M3 or CloudSuite Industrial.

Open-Prod stock levels across warehouse locations map to CloudSuite Inventory. We extract current inventory positions with warehouse assignment and on-hand quantity. Open-Prod purchase orders and pending shipments require sequencing after inventory to avoid double-counting stock during the migration window. We recommend freezing Open-Prod inventory transactions for the final migration period and posting all pending receipts before extraction.

Open-Prod sales orders and invoices map to CloudSuite Sales Order. Invoice lineage and line-item details migrate with order headers linked to the Customer mapping. We flag any post-migration invoice numbering conflicts because CloudSuite assigns document numbers from a configured number series; if Open-Prod used overlapping ranges, the customer's admin must reconcile number series before migration or accept CloudSuite-assigned numbers with a cross-reference table.

Open-Prod project records with tasks and milestones map to CloudSuite Project or Work Order depending on the operational nature (service project vs manufacturing work order). Task dependencies and custom fields require manual review because Open-Prod's custom field schema is not publicly documented. We extract all project records with their hierarchy intact and flag any custom task fields for the customer's Infor partner to configure post-migration.

Open-Prod after-sales service tickets map to CloudSuite Service Order or Service Agreement. Status and priority fields translate to CloudSuite service request status values. If Open-Prod stores service history linked to the original Product (serial number, warranty terms), we map that to the CloudSuite Item serial number and warranty tracking features. Customer asset records migrate as Equipment or Asset records in CloudSuite.

Open-Prod custom fields cannot be automatically mapped because their schema is not publicly documented. We require direct SQL access to the customer's Open-Prod database during scoping to enumerate custom column names, data types, and table associations. These map to CloudSuite Mongoose extended fields or custom BOD elements. Mongoose custom objects use the Form Sync Copy utility to transfer between configurations, but source schema must be known before design begins.

Open-Prod attachment storage lacks a confirmed public export mechanism. We flag attachment migration as out of scope for standard migration until we can validate export capability through direct database access. If Open-Prod stores file paths or BLOBs in SQL tables, we can extract them and load into Infor Document Management (IDM) post-migration, but this requires a custom extraction script validated against the customer's specific Open-Prod version and configuration.

Open-Prod unit of measure definitions (UOM codes, conversion factors) must migrate before any Item, Bill of Materials, or routing data because CloudSuite enforces referential integrity on UOM references. We extract the UOM master first, then UOM conversion tables, before loading any product or production data. This is the first data load in every CloudSuite migration sequence.

Open-Prod accounting module entries (journal lines, account balances, AP/AR) require mapping to the CloudSuite Chart of Accounts. We extract open AP and AR records with aging buckets and map to CloudSuite Vendor/Customer with corresponding GL account assignments. Closed periods migrate as historical data; open periods require coordination with the customer's finance team to determine cutover date and any required period adjustments in CloudSuite.