Migrate from Proteus E12ERP to Infor CloudSuite Corporate

Proteus E12ERP Customer records map to Infor CloudSuite Business Partner records with the Customer role enabled. We preserve customer name, primary contact details, billing and shipping addresses, payment terms, and credit limit. Customer type (individual, company) maps to the Business Partner type field. The Business Partner must exist before any Sales Order or AR invoice import so that the BP lookup is satisfied at insert time. Multi-site deployments where the same customer has different addresses per branch require either separate BP records per ship-to or a configuration decision on the customer's Infor administrator on whether to use one BP with multiple addresses.

Proteus E12ERP Vendor records map to Infor CloudSuite Business Partner records with the Vendor role. We preserve vendor name, contact details, bank information, payment terms, and the vendor account code. In CloudSuite, vendors may share the same Business Partner record as a customer (BP with both roles) if the organization has both payables and receivables with the same entity. We flag this scenario during scoping so the customer decides whether to consolidate or maintain separate BP records.

Proteus E12ERP Inventory Items with SKU, description, unit cost, and quantity on hand map to CloudSuite Item records. The Proteus unit cost becomes the standard cost on the Item; quantity on hand transfers to on-hand inventory linked to the appropriate Warehouse. If Proteus exposes lot or serial numbers, we map them to CloudSuite's lot and serial tracking fields. Items with BOM structures in Proteus (if present) map to CloudSuite Item Bill of Materials, and we flag BOM resolution as a separate scoping item because BOM complexity drives significant mapping variance.

Proteus E12ERP Revenue Centers represent branches or cost centres in a multi-location deployment. This is a non-standard ERP concept. We map Revenue Centers to CloudSuite Locations (physical site) and optionally to Cost Centres (financial segmentation) depending on how the customer uses Revenue Centers in reporting. If Revenue Centers map to profit-centre accounting, we configure Cost Centre segments in the Chart of Accounts. If they map to physical warehouse or branch identification, we create Location records. The customer's Infor administrator confirms the intended use during scoping.

Proteus E12ERP account codes and types (asset, liability, equity, revenue, expense) map to CloudSuite Chart of Accounts with segment configuration. CloudSuite supports multi-segment account codes (for example, company-department-account or region-entity-account) that may exceed Proteus E12ERP's flat structure. We map account types directly and flag whether CloudSuite's segment configuration requires activation (a configuration step the customer's Infor admin performs before the account data is loaded). Currency denomination on accounts maps to CloudSuite's currency assignment per account or per company entity.

Proteus E12ERP Sales Orders linked to Customers and Inventory Items map to CloudSuite Sales Orders. We resolve the Customer BP reference and the Item reference at migration time, preserving order number, order date, requested delivery date, line-item quantity, unit price, and discount amounts. Order status (open, partial, closed) maps to CloudSuite's order status values. If Proteus exposes multi-line pricing or trade-scheme discounts (common in FMCG configurations), we preserve these as pricing comments or promotional line types in CloudSuite. Orders are imported after Customers and Items to satisfy foreign-key dependencies.

Proteus E12ERP Purchase Order records include vendor references, line items, and quantities. We resolve vendor IDs to the CloudSuite Business Partner (Vendor role), map line items to CloudSuite Items, and align PO statuses (open, received, closed) to CloudSuite's PO status values. Quantities received in Proteus that are partially received map to the corresponding receipt records in CloudSuite. If the vendor references a non-inventoried item (a service or expense), we create a non-stock Item in CloudSuite.

Open invoice state (unpaid purchase orders and outstanding customer invoices) is not reliably documented as exportable in Proteus E12ERP's CSV. We cannot guarantee completeness of open-AP and open-AR records from the source. We flag this gap in the pre-migration scope document and recommend that the customer's finance team manually reconcile and re-enter open invoices directly in CloudSuite post-migration, or confirm with Proteus support whether an export exists before we attempt to map it.

We do not migrate Workflows, Sequences, or Automations as code. Infor CloudSuite uses ION, extensions, and CloudSuite-specific automation tools that have no direct equivalent to Proteus E12ERP's workflow configuration (if any). We deliver a written inventory of any documented Proteus E12ERP automation rules describing the trigger, conditions, and actions, with a recommended CloudSuite equivalent and configuration approach. The customer's Infor administrator or a certified Infor partner rebuilds these post-migration.

Custom reports from Proteus E12ERP (if any exist beyond the standard export) cannot migrate to CloudSuite. Infor CloudSuite reports and dashboards are rebuilt in Birst analytics or CloudSuite's native reporting tools. We deliver a written inventory of any custom report identified in the source environment with the report name, data source, and filters, so the customer's Infor administrator or BI team can rebuild them. Organizations with hundreds of custom reports should budget separately for the Birst rebuild effort.