ERP migration
Field-level mapping, validation, and rollback between WP ERP and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
WP ERP
Source
Epicor Prophet 21
Destination
Compatibility
12 of 14
objects map 1:1 between WP ERP and Epicor Prophet 21.
Complexity
BStandard
Timeline
5-8 weeks
Overview
Moving from WP ERP to Epicor ERP is a platform-class migration that exits the WordPress ecosystem entirely. WP ERP stores its data in custom WordPress tables (erp_hr_*, erp_crm_*, erp_ac_*) that require direct MySQL extraction rather than XML export or WP-CLI dumps. We extract employee records with compensation and department assignments, CRM contacts with lifecycle stages and company associations, and the full Chart of Accounts with journal entries and open invoices. Epicor ERP uses a manufacturing-centric data model: Part records for inventory, Customer and Supplier tables for CRM data, General Ledger for accounting, and PartTracker or Kinetic Employee Management for HR. We resolve the structural differences (WordPress user IDs versus Epicor Party/Contact hierarchy, WooCommerce duplicate contact candidates, and payroll historical archive scope) during scoping and carry them through the migration in dependency order. Workflow automation rules from the WP ERP Workflow extension are serialized PHP in wp_options and cannot import into Epicor; we document every rule for manual rebuild in Epicor Kinetic Business Process Automation or MES workflow tools.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a WP ERP object lands in Epicor Prophet 21, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
WP ERP
Employees (erp_hr_employees)
Epicor Prophet 21
PartTracker Employee or Kinetic Human Capital Management
1:1WP ERP employee records (personal details, employment status, department, job title, hire date, compensation) extract from erp_hr_employees with wp_user_id cross-reference from wp_users. We map to Epicor Kinetic Employee records or PartTracker labor entries depending on the destination Epicor product (Kinetic HCM versus PartTracker). Compensation data (salary, pay type, bank details) is flagged as sensitive and handled under the payroll archive decision: migrate as record data, archive as PDF, or exclude entirely based on customer compliance requirements.
WP ERP
Departments (erp_hr_departments)
Epicor Prophet 21
Kinetic Organizational Unit or PartTracker Department
1:1Department records in erp_hr_departments are top-down hierarchical key-value structures. We extract the full tree (parent-child relationships, department name, head of department) and rebuild it as an Epicor organizational structure. Employee-to-department assignments resolve by cross-referencing the erp_hr_employees.department_id foreign key to the migrated department ID on Epicor.
WP ERP
CRM Contacts (erp_crm_contacts)
Epicor Prophet 21
Epicor Customer Contact (CustCnt) and Employee Contact
1:manyWP ERP contacts (name, email, phone, address, lifecycle stage, source attribution) extract from erp_crm_contacts with wp_user_id links. Epicor Kinetic uses a Party-based model: the contact person attaches to a Customer or Supplier Party record. We split contacts into Customer Contact (sales-related) and Employee Contact (HR-related) based on the WP ERP contact type and lifecycle stage. WooCommerce duplicate candidates (same email appearing in manually created contacts and WooCommerce order records) are flagged for merge before export.
WP ERP
CRM Companies (erp_crm_companies)
Epicor Prophet 21
Epicor Customer or Supplier Party (CustPrt, VendPrt)
1:1WP ERP company records in erp_crm_companies link to CRM contacts via erp_crm_contact_relations. We map companies to Epicor Customer Party (for B2B accounts) or Supplier Party (for vendor-of-record companies) based on whether the WP ERP company record has associated sales deals or purchase transactions. Company ID remapping preserves the contact-company relationship during migration by resolving erp_crm_contact_relations.contact_id to the new Epicor CustCnt ID.
WP ERP
Deals (erp_crm_deals, paid CRM extension)
Epicor Prophet 21
Epicor Opportunity or Sales Order
1:1WP ERP Deals (title, value, currency, stage, owner, pipeline association) extract from the Deals extension ($9.49/mo). Epicor Kinetic does not have a standalone Deal object; deals with an active sales process map to Epicor Opportunity (if pre-quote) or to Sales Order (if in progress). Pipeline stages from WP ERP map to Epicor Opportunity Stage or Sales Order status based on deal state at migration time. Deals with a status of Closed-Won map to a closed Epicor Sales Order; Closed-Lost deals are flagged for reporting exclusion.
WP ERP
CRM Activities (erp_crm_activities)
Epicor Prophet 21
Epicor Tracker Activities or CRM Communication Log
1:1Activities (calls, meetings, emails, tasks) stored in erp_crm_activities with polymorphic type fields flatten into a standard activity log structure. We map WP ERP activity type to Epicor Tracker activity category (Phone Call, Meeting, Email, To-Do). Activity timestamps, owner assignment, and associated contact or company links migrate directly. Note attachments associated with activities migrate as Epicor attachments linked to the parent activity record.
WP ERP
Chart of Accounts (erp_ac_chart_of_accounts)
Epicor Prophet 21
Epicor General Ledger Account (GLAccount)
1:1WP ERP chart of accounts records (account code, name, type, subtype, parent-child hierarchy for grouped accounts) extract from erp_ac_chart_of_accounts. We map WP ERP account types to Epicor GL Account categories: Asset, Liability, Equity, Revenue, Expense. Account code prefixes and hierarchical groupings (parent_account_id) preserve the COA structure in Epicor. GL account codes that conflict with Epicor Kinetic chart of accounts conventions are remapped during the transform phase with a reconciliation report delivered to the customer.
WP ERP
Accounting Customers (erp_ac_customers)
Epicor Prophet 21
Epicor Customer Party (CustPrt)
1:1Accounting customers in erp_ac_customers link to CRM contacts via erp_crm_contacts.id. We resolve the cross-reference at migration time so that the Epicor Customer Party record points to the correct CRM contact person (CustCnt). Billing address, payment terms, and credit limit from erp_ac_customers migrate to Epicor Customer maintenance screens. Open invoice balances and aged receivable data attach to the Customer record for AR initialization.
WP ERP
Accounting Vendors (erp_ac_vendors)
Epicor Prophet 21
Epicor Supplier Party (VendPrt)
1:1Vendor records in erp_ac_vendors migrate with billing address, company name, and contact email. Vendor-ledger entries (purchase transactions) link via vendor_id foreign key to the migrated VendPrt record. Epicor uses a Vendor maintenance record with Supplier contacts and payment terms. We preserve any 1099 reporting flags from WP ERP in the Epicor Vendor record for US tax compliance.
WP ERP
Invoices (erp_ac_invoices)
Epicor Prophet 21
Epicor AR Invoice and AP Invoice
1:1WP ERP invoices include line items, tax codes, payment status, and due dates. We flag open invoices (unpaid, partially paid) versus paid or voided invoices and map status to Epicor AR Invoice status (Open, Closed, Disputed). Open invoices migrate as Epicor AR Invoice records with aging; paid invoices migrate as historical records for financial audit trails. Invoices that reference non-existent customers or vendors are held in a reconciliation queue.
WP ERP
Journal Entries (erp_ac_journal_entries)
Epicor Prophet 21
Epicor GL Journal Entry
1:1Manual journal entries stored in erp_ac_journal_entries with debit/credit line items migrate to Epicor GL Journal Entry. Each line maps the WP ERP account code (resolved via the COA migration) to the Epicor GL Account, with debit/credit amounts and descriptions preserved. Automated journal entries generated by the WP ERP Payroll module migrate as manual entries with a Payroll source reference, since Epicor handles payroll journal creation natively.
WP ERP
Inventory Items (erp_ac_inventory, paid extension)
Epicor Prophet 21
Epicor Part (PartMsc, PartWhse)
1:1WP ERP inventory items (name, SKU, unit cost, current stock quantity, reorder level) extract from the Inventory extension if active. Epicor Kinetic uses a Part master (Part table) with PartMsc for miscellaneous costs and PartWhse for warehouse-specific stock levels. We map WP ERP stock quantity to Epicor PartWhse.OnHandQty, unit cost to PartMsc.MtlCost, and reorder level to PartWhse.MinimumQty. Stock movement history migrates as a separate transaction log for audit rather than as Epicor PartTran records.
WP ERP
Documents (Document Manager extension)
Epicor Prophet 21
Epicor Attachments
1:1The Document Manager extension ($2.49/mo) stores files in the WordPress media library or custom uploads directory. We export file metadata (filename, upload date, associated WP ERP entity) and re-upload the binary files to Epicor as attachments linked to the corresponding Part, Customer, Supplier, or Order record. File permissions and access controls do not migrate; Epicor's attachment security model applies post-migration.
WP ERP
Workflow Automation (wp_options serialized PHP)
Epicor Prophet 21
Not migrated; documented for rebuild
lossyThe WP ERP Workflow extension stores automation rules as serialized PHP arrays in wp_options. These cannot be imported into Epicor Kinetic. We extract the trigger-action pairs (trigger module, condition logic, action steps) and deliver a written automation inventory with Epicor Kinetic equivalent recommendations: Business Process Automation for order-triggered workflows, MES workflow routing for shop floor automation, or Kinetic Dashboard alerts for conditional notifications. The customer's Epicor admin or implementation partner rebuilds them post-migration.
| WP ERP | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Employees (erp_hr_employees) | PartTracker Employee or Kinetic Human Capital Management1:1 | Fully supported | |
| Departments (erp_hr_departments) | Kinetic Organizational Unit or PartTracker Department1:1 | Fully supported | |
| CRM Contacts (erp_crm_contacts) | Epicor Customer Contact (CustCnt) and Employee Contact1:many | Fully supported | |
| CRM Companies (erp_crm_companies) | Epicor Customer or Supplier Party (CustPrt, VendPrt)1:1 | Fully supported | |
| Deals (erp_crm_deals, paid CRM extension) | Epicor Opportunity or Sales Order1:1 | Fully supported | |
| CRM Activities (erp_crm_activities) | Epicor Tracker Activities or CRM Communication Log1:1 | Fully supported | |
| Chart of Accounts (erp_ac_chart_of_accounts) | Epicor General Ledger Account (GLAccount)1:1 | Fully supported | |
| Accounting Customers (erp_ac_customers) | Epicor Customer Party (CustPrt)1:1 | Fully supported | |
| Accounting Vendors (erp_ac_vendors) | Epicor Supplier Party (VendPrt)1:1 | Fully supported | |
| Invoices (erp_ac_invoices) | Epicor AR Invoice and AP Invoice1:1 | Fully supported | |
| Journal Entries (erp_ac_journal_entries) | Epicor GL Journal Entry1:1 | Fully supported | |
| Inventory Items (erp_ac_inventory, paid extension) | Epicor Part (PartMsc, PartWhse)1:1 | Fully supported | |
| Documents (Document Manager extension) | Epicor Attachments1:1 | Fully supported | |
| Workflow Automation (wp_options serialized PHP) | Not migrated; documented for rebuildlossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
WP ERP gotchas
Custom database tables require direct SQL extraction
PHP version and WordPress version mismatches block migration tooling
WooCommerce CRM integration creates duplicate contact records
Payroll historical data is module-gated and extension-specific
Workflow automation rules are serialized PHP in wp_options
Epicor Prophet 21 gotchas
Third-party bolt-on integrations complicate migration scope
Dirty data without standardized processes compounds migration risk
SDK customizations and BPMs may not survive platform upgrades
Report-based export only for non-technical users
Per-user pricing model requires accurate user count before migration planning
Pair-specific challenges
Migration approach
Scope and extraction design
We audit the source WP ERP instance: PHP version, WordPress version, active extensions (HRM, CRM, Accounting, Payroll, Deals, Document Manager, Inventory, Workflow), custom table record counts, WooCommerce integration status, and any Custom Field Builder data. We verify access to the WordPress MySQL database and test direct table reads on erp_hr_*, erp_crm_*, and erp_ac_* tables. We document the WP ERP version and extension versions because table schemas vary between releases. The scope output is a written extraction specification and a data volume estimate for each object.
Destination Epicor schema review
We review the destination Epicor Kinetic or Prophet 21 environment: installed modules (HCM, MES, CRM, GL, AP, AR, Inventory, Order Management), current chart of accounts structure, existing customer and supplier records, and any UD field usage. If Epicor already has customer or supplier records, we perform a dedupe check against the WP ERP data and flag matches for the customer's review. We also review Epicor account code format requirements and document any GL account remapping needed for WP ERP account codes.
GL account and party resolution mapping
We build the GL account mapping table: WP ERP account code to Epicor GL Account number with the Epicor account type assignment (Asset, Liability, Equity, Revenue, Expense). We resolve WP ERP company records to Epicor Customer Party or Supplier Party based on transaction history (sales deals map to Customer, purchase transactions map to Supplier). For WooCommerce duplicate contact candidates, we produce a merge decision report with email, source, and record count. The mapping document is reviewed and signed off before extraction begins.
Direct MySQL extraction and data quality validation
We run direct MySQL SELECT statements against each WP ERP custom table (erp_hr_employees, erp_hr_departments, erp_crm_contacts, erp_crm_companies, erp_crm_deals, erp_crm_activities, erp_ac_chart_of_accounts, erp_ac_customers, erp_ac_vendors, erp_ac_invoices, erp_ac_journal_entries, and extension-specific tables). We validate record counts against WP ERP admin UI figures, check for null foreign keys and orphaned records, and flag any serialized data fields that require PHP deserialization. Data quality issues (duplicate emails, missing required fields, invalid GL account codes) are reported to the customer for remediation before transform.
Transform and load into Epicor
We run the migration in dependency order: GL Accounts first (all other accounting data depends on the COA), then Customers and Suppliers (CRM and accounting customers depend on contacts), then Contacts (activity and deal records depend on contact ID), then Employees, then Deals and Activities, then Invoices and Journal Entries, then Inventory (if extension active), then Documents. Each phase runs with Epicor REST or SOAP API calls (depending on Kinetic deployment model) using batch chunking for large record sets. Parent record lookups (contact to customer, account to GL account) resolve in-memory before insert to avoid foreign key violations.
Cutover, validation, and workflow handoff
We freeze WP ERP writes during cutover, run a final delta migration for any records modified during the migration window, and verify record counts in Epicor against the extraction totals. We spot-check 30-50 records per object against the WP ERP source data and deliver a reconciliation report. We deliver the Workflow automation inventory document to the customer's Epicor admin for rebuild in Epicor Business Process Automation. We support a one-week hypercare window where we resolve any post-migration data issues. We do not rebuild WP ERP workflows in Epicor; that is a separate engagement or an internal admin task.
Platform deep dives
WP ERP
Source
Strengths
Weaknesses
Epicor Prophet 21
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across WP ERP and Epicor Prophet 21.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
WP ERP: WordPress REST API with no publicly documented rate limit; XML-RPC is capped at 10 requests per 30 seconds per IP on VIP environments.
Data volume sensitivity
WP ERP doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during WP ERP to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your WP ERP to Epicor Prophet 21 migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave WP ERP
Other ways to arrive at Epicor Prophet 21
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.