Migrate from Kinetic to Epicor Prophet 21

Chart of Accounts must exist in Epicor ERP before any transactional records load. Account structures differ significantly between source and destination; we handle natural account versus segment mapping, COA segment count alignment, and account type classification. We preserve account balances as open GL entries in the destination if the migration scope includes historical financials.

Site records and associated Warehouses transfer cleanly between Kinetic and Epicor ERP. Multi-site configurations map directly. We preserve site-specific parameters including default warehouse, shipping calendars, inter-site transfer rules, and cost layer defaults. Site is a prerequisite for Customer, Vendor, Part, and Order records.

Parts have the largest field surface in Epicor ERP — PartNum, TypeCode, UOMs, Class, COMCAT behavior, stocking attributes, and cost layers. Source systems frequently use different part-numbering schemas or omit the TypeCode entirely. We validate TypeCode, UOM class, and stocking dimensions against the Epicor ERP required-field matrix before loading and flag part records with invalid or missing TypeCode for remediation before the load begins.

BOMs are migration-critical because Epicor ERP enforces BOM revision and approval states. We preserve the BOM revision chain including revision dates, approval statuses, and alternate BOMs. Where the source Kinetic instance lacks revision tracking, we create a default revision. Multi-level BOMs are loaded bottom-up so that sub-assemblies exist before parent BOMs reference them. We validate PartNum references for all BOM lines before the load phase.

Routings reference Operations, Work Centers, and Sequences. Invalid Work Center IDs, missing step sequences, or out-of-order operation numbers cause Epicor ERP to reject the routing on load. We validate Work Center existence, operation sequence numbering, and labor/machine hour estimates before migration. Step-level routing data maps to Epicor ERP's operation master with Subcontract, Work Center, and labor code fields preserved.

Customer records map 1:1 via DMT or REST API. Standard fields (CustID, Name, Address, Terms, ShipTo) are stable across Epicor ERP versions. We migrate Customer records as a prerequisite step since Sales Orders depend on Customer existence. Multi-address customer setups and credit limit data transfer directly. Customer is loaded before Sales Order Header.

Vendor records transfer via DMT with VendorID as the primary key. Multi-address vendor setups, PO approval workflow assignments, and payment terms migrate directly. We handle vendor hold status and federal ID validation. Vendor is loaded before Purchase Order Header.

Employee records map to Epicor ERP's Employee table. User and Owner assignments on transactional records require the Employee to exist first. We handle effective-dated employee status changes, department and location assignments, and labor code mappings. Employee is loaded before any Work Order or Payroll records.

Sales Orders have phased loading: Order Header must complete before Order Detail, which must complete before Order Releases. Order type, terms, ship-from site, and customer must exist in Epicor ERP before order lines can be added. We validate the customer reference, site reference, and order type against the destination schema before the header load. Original order dates and promised dates migrate as-is.

Order lines depend on the Order Header record existing and on the Part record existing for the ordered item. We validate PartNum references against the destination Part table before loading lines. Quantity, unit price, discount, and tax code map directly. Line number assignment in Epicor ERP follows the destination's auto-sequence unless the customer requests original ID preservation.

PO headers require Vendor and Site records present first. We migrate current PO status and flag any records that need re-approval post-migration since approval workflow state is not preserved across systems. PO type, terms, and ship-to site migrate directly. PO number preservation is supported via manual numbering configuration in Epicor ERP.

PO lines depend on the PO Header and the Part or Description record. We validate VendorNum and PartNum references before loading. Line number assignment, quantity, unit cost, and due date map directly. GL control account assignments on PO lines are validated against the destination COA before load.

Work Orders depend on Part, BOM, and Routing records existing in the destination. JobNum generation rules vary by site configuration. We map source JobNum patterns to Epicor ERP's auto-numbering scheme or preserve original IDs where the customer requests it. Open Work Order status, WIP quantities, and job scheduling data migrate. We do not migrate closed work order cost history unless the customer specifically requests it as a historical GL entry.

Kinetic's user-defined field infrastructure allows each tenant to add custom columns to standard business objects. UD field names are not part of the standard schema and are not documented in public API references. During discovery we query the source Kinetic UD field metadata via the API and the destination Epicor ERP UD field metadata separately, then build a cross-system mapping layer so source custom fields land in the correct destination UD columns. UD field migration is object-specific and requires per-tenant schema discovery.

Organizations with Kinetic Enterprise multi-database configurations use inter-company databases with cross-referenced records. Naive export-and-load migrations lose these relationships because record IDs will not match in a new environment. We map and preserve cross-database foreign key relationships during the migration by building an ID resolution table that maps source record IDs to destination record IDs across every database in scope.