Migrate from Iptor ERP to Epicor Prophet 21

Iptor's unified Business Partner entity holds both customer and vendor relationships in a single record. We split by BP type during migration, creating separate Customer and Vendor records in Epicor. The BP code becomes the Epicor Customer ID or Vendor ID; address, contact, and payment-term fields map directly. Custom fields on the BP record migrate as UD fields on the respective Epicor entity.

Iptor Items map to Epicor Part records. Iptor's Item Classification hierarchy (multi-level parent-child tree) is preserved as a classification path string and resolved to Epicor's Category field or to Part UDFs depending on what attribute structure the destination uses. Multiple unit-of-measure settings migrate as Part UOM records with conversion factors. Lot/serial number tracking migrates as PartLot records with traceability dates.

Iptor Sales Order headers map to Epicor OrderHed with order number, customer reference, and order date preserved. Order lines map to OrderDtl with line number, part number (resolved to Part ID), quantity, unit price, and discount. Open versus fulfilled status migrates with the OrderHed OpenOrder flag so Epicor correctly represents in-flight orders at go-live. Order lines are migrated in the same pass as headers to satisfy the parent-child constraint.

Iptor Purchase Orders map to Epicor POHeader and PODetail. Vendor assignment resolves via the BP-to-Vendor split done in step one. Expected delivery dates and partial-receipt quantities migrate as PODetail with our_received and remaining quantities flagged so the destination correctly represents in-flight procurement. Closed POs migrate as historical records for reporting continuity.

Iptor AR invoices map to Epicor InvcHead and InvcDtl with invoice number, customer, invoice date, amounts, and tax jurisdiction preserved. Iptor AP invoices map to Epicor's AP invoice entity with vendor, invoice date, and amount. Tax codes from Iptor map to Epicor TaxConnect jurisdictions or to manual tax code assignments depending on the destination configuration. Payment terms migrate as value descriptions rather than system references.

Iptor Delivery Notes map to Epicor ShipHead and ShipDtl. Header fields (delivery note number, date, customer, warehouse) map directly. Line fields (part number, shipped quantity, ordered quantity) migrate with a linkage back to the originating OrderHed via the OrderNum reference. This preserves the audit trail between the sales order and fulfillment record.

We extract open payables and receivables as explicit line items at migration time so Epicor begins with an accurate aged trial balance. Open AR records include customer, invoice reference, due date, and outstanding amount. Open AP records include vendor, invoice reference, due date, and outstanding amount. Closed items migrate as historical records for reporting but are not flagged as open.

Iptor's configurable segment layout maps to Epicor's GL Account structure. We identify each Iptor account segment (typically account code, cost center, department) and map it to the corresponding Epicor GL Account segment or to a flat account code format. Accounts with non-standard segment assignments are flagged for manual review before we commit the data. The customer approves the chart of accounts mapping before import.

Iptor stock levels, warehouse locations, and lot/serial numbers migrate as PartBin records. Iptor's multi-warehouse setup requires us to map warehouse codes to Epicor Warehse location codes during discovery. The migration captures a current-state snapshot of inventory at go-live. PartBin OnHandQty, AllocQty, and ReservedQty transfer as values at the cutover timestamp.

Historical journal entries migrate for reporting continuity. Iptor supports complex journal types including recurring entries. We preserve journal date, description, journal number, and all debit/credit lines. Each journal batch becomes an Epicor GLJrnGrp with individual lines as GLJrnLine records. Recurring journal templates are documented as notes for the customer's admin to recreate in Epicor.

Iptor's Item Classification system supports multi-level hierarchical categorization that does not map 1:1 to Epicor's flat category field. We extract the full classification tree, preserve the full parent-child relationship path as a string on the Part record (e.g., Category1 > Subcategory2 > Class3), and optionally populate Epicor's Category field with the leaf node. The customer chooses the strategy during scoping based on how they intend to report on item hierarchies in Epicor.

Iptor custom fields and custom tables are customer-specific with no stable schema. We document every custom field definition during discovery (field name, data type, associated object, values list if picklist). We propose a target mapping to Epicor UD fields on the equivalent object or to a custom UD table. The customer reviews and approves the mapping before we commit any custom data. Custom object structures that have no Epicor equivalent are delivered as structured flat files with documentation.