Migrate from Proteus E12ERP to Epicor Prophet 21

Proteus E12ERP Customer records (CRM module) map directly to Epicor ERP Customer table. The Proteus customer name, contact details, company associations, and lifecycle stage migrate as Customer fields. The dedupe key is the Proteus customer ID or company name. We resolve the CustomerType and CreditLimit fields at migration time where available; if credit terms are not exposed in the Proteus delimited export, we flag them for manual entry or a post-migration reconciliation pass.

Proteus E12ERP Vendor records (Purchase Order Management) map to Epicor ERP Vendor table. Name, contact information, payment terms, and vendor classification migrate. The VendorID in Epicor is derived from the Proteus vendor ID or generated sequentially. We resolve vendor-to-PO relationships so that open Purchase Orders reference the correct Vendor record at insert time.

Proteus E12ERP Inventory Items (SKU, description, unit cost, quantity on hand) map to Epicor ERP Part table. The Proteus quantity on hand migrates to PartWhse (site-level warehouse stock) once the Epicor Site has been provisioned. If the customer has multiple Proteus Revenue Centers representing physical locations, each migrates to a corresponding Epicor Site, and PartWhse records are created per Site-Part combination. Unit of Measure (UOM) conversion is handled where Proteus and Epicor use different UOM standards.

Proteus E12ERP Sales Order records map to Epicor ERP OrderHed (order header) and OrderDtl (order lines). OrderHed captures the customer reference, order date, and order status; OrderDtl captures the line items with PartNum, quantity, unit price, and warehouse assignment. We resolve CustomerNum and ShipToNum references at migration time so that OrderHed is linked to the correct Customer record before OrderDtl inserts. Order status mapping (open, partially received, closed) aligns with Epicor's OrderRel and OrderDtl status fields.

Proteus E12ERP Purchase Order records map to Epicor ERP POHeader and PODetail tables. The vendor reference resolves to VendorNum; line items resolve to PartNum and POLine. We align PO statuses (open, received, closed) with Epicor's PORel (release) status. If the Proteus export includes partially received PO lines, the received quantities migrate as PORel records against the corresponding PODetail.

Proteus E12ERP Revenue Centers represent branches or cost centres. This is a non-standard ERP concept with no direct Epicor equivalent. We map Revenue Centers to Epicor Sites (the primary location entity in Epicor Kinetic for plants and warehouses) or, where the customer uses cost-centre accounting, to Epicor Departments. The customer chooses the mapping strategy during scoping based on whether they need site-level inventory tracking, plant-level production scheduling, or purely cost-accounting visibility. Revenue Center hierarchies map to Epicor Company-Site-Warehouse nesting.

Proteus E12ERP Chart of Accounts (account codes and types) maps to Epicor ERP GLAccount table. We preserve account type (asset, liability, equity, revenue, expense), currency denomination, and account code structure. Epicor uses a segment-based account structure (natural account + optional business segment, division, department segments) that requires configuration during the discovery phase. We align the Proteus flat account codes to the nearest Epicor segment structure the customer intends to use, and flag any accounts that cannot be represented in the chosen structure for the customer's GL team to resolve.

If the Proteus delimited export includes historical financial transactions, we map them to Epicor ERP GLJrnTran (General Ledger Journal Transaction) records. Transaction migration requires a fully configured Chart of Accounts (GLAccount) as a prerequisite. Epicor's GLJrnTran requires fiscal period and company context; we resolve these at migration time and flag any transactions with unmapped account references for manual posting or reversal. Historical transactions beyond twelve to twenty-four months are migrated selectively based on the customer's reporting needs and the destination's fiscal period open status.

Open invoice state (unpaid purchase orders and outstanding customer invoices) is not explicitly documented as an exportable object in the Proteus E12ERP delimited export. We cannot guarantee completeness of open-AP and open-AR records from the source. We flag this as a high-severity gotcha in the discovery phase. The customer should manually export open invoices from Proteus E12ERP via the web interface before migration cutover and either enter them manually in Epicor ERP post-migration or engage a reconciliation specialist to map them to Epicor's APInvHed/ARInvcHead tables. This is a data gap that must be addressed outside the automated migration scope.

If the Proteus export includes pricing schedules or customer-specific price lists, we map them to Epicor ERP PartPlant (site-specific cost and pricing) and PriceLsp (price breaks and volume schedules). We resolve PartNum and Site references before inserting price records. If the Proteus pricing model uses percentage markups or discount schedules that have no direct Epicor equivalent, we document the pricing logic and recommend an Epicor Price Matrix or Customer Price Group configuration for the customer's admin to implement.

If the Proteus source includes Bill of Materials data (engineering or manufacturing BOMs for make-to-order or configure-to-order products), we map them to Epicor ERP EBOMRevision and EBOMDetail records. BOM migration requires a fully configured Part master as a prerequisite. Epicor's BOM supports revision control, approved vs proposed BOM states, and plant-specific BOM assignments, which require configuration decisions during the discovery phase.

Proteus E12ERP user accounts map to Epicor ERP UserFile records. We resolve by email match where available. Any Proteus user without a matching Epicor UserFile goes to a reconciliation queue for the customer's Epicor admin to provision before record import resumes. Epicor Kinetic enforces a minimum 10-user licensing floor, which affects the cost model for small teams migrating from Proteus.