ERP migration
Field-level mapping, validation, and rollback between Centerpoint ERP and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
Centerpoint ERP
Source
Epicor Prophet 21
Destination
Compatibility
9 of 12
objects map 1:1 between Centerpoint ERP and Epicor Prophet 21.
Complexity
BStandard
Timeline
8-12 weeks
Overview
Moving from Centerpoint ERP to Epicor ERP is a migration from a platform with no public API to one with a full REST API architecture. Centerpoint ERP uses flat-file exports via its built-in Data Importer and custom export programs from Red Wing Software for data extraction, while Epicor ERP exposes a documented REST API for ingestion, data load, and schema management. The primary technical challenge is the extraction phase: Centerpoint has no bulk export endpoint, so we work with each module's native export capability to produce delimited files, resolve parent-record dependencies before extraction, and preserve the relational links between CRM stages, asset hierarchies, and work-order schedules. Epicor ERP is built for discrete, make-to-order, and engineer-to-order manufacturing with 50 to 2,500 employee manufacturers and distributors as its primary buyer profile. We do not migrate Centerpoint Workflows, QHSE automation configurations, or compliance scoring logic as code; we deliver a written inventory of these for the customer's admin to rebuild in Epicor Kinetic.
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 Centerpoint 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.
Centerpoint ERP
Contact
Epicor Prophet 21
Customer
1:1Centerpoint CRM Contacts map directly to Epicor Customer records. The Customer table in Epicor Kinetic serves as the master party record with ShipTo and BillTo address roles. We preserve the Contact name fields (FirstName, LastName, Company), email, phone, owner assignment, and any CRM stage properties as Epicor UD (user-defined) fields. Address data migrates to the CustomerAddress table with address type roles resolved during extraction.
Centerpoint ERP
Lead
Epicor Prophet 21
Prospect
1:1Centerpoint CRM Leads map to Epicor Kinetic Prospect records. The staged workflow status from Centerpoint (Lead through Opportunity) migrates to the Prospect stage and is preserved as a custom UD field for audit. Lead source attribution and any scoring values stored in Centerpoint custom fields map to Epicor UD fields on Prospect.
Centerpoint ERP
Opportunity
Epicor Prophet 21
SalesOrder or Quote
1:manyCenterpoint Opportunities map to Epicor SalesOrder records in a pre-converted state or to Quote records depending on where the opportunity lifecycle sits in Centerpoint. Stage assignment maps to Epicor OrderHed.Status. We preserve deal value, close date, and weighted/unweighted forecast values as UD fields. Line items from Centerpoint Opportunity products map to OrderDtl with product code and quantity resolved against the Epicor Part table.
Centerpoint ERP
CRM Forecast (weighted/unweighted)
Epicor Prophet 21
Forecast UD fields on SalesOrder
lossyCenterpoint CRM supports both weighted and unweighted forecast views as distinct report outputs. Epicor Kinetic does not have native dual-forecast support. We present this as a scoping option: preserve both as separate UD numeric fields on the related SalesOrder (forecast_weighted__c, forecast_unweighted__c), or migrate only the unweighted value into the standard order amount field. The customer chooses during scoping.
Centerpoint ERP
Asset
Epicor Prophet 21
Asset (Equivnent)
1:1Centerpoint Asset Management module records map to Epicor Kinetic Equivnent (equipment master) records. Asset hierarchy, current value, depreciation details, location, and asset class all map to corresponding Equivnent fields. Parent-child asset relationships in Centerpoint map to Equivnent parent link fields. Depreciation schedules are preserved as UD fields since Epicor's native depreciation runs in the finance module.
Centerpoint ERP
Work Order
Epicor Prophet 21
Job
1:1Centerpoint Work Orders map to Epicor Kinetic Job records, which is the core production order entity in Epicor's manufacturing module. We preserve the asset link (Centerpoint asset to Epicor Job.EquipID), technician assignments, safety prerequisites, status history, and job scheduling dates. Part numbers on Work Orders resolve against Epicor Part master during import. If Centerpoint Work Orders include actual labor and material transactions, those map to Epicor JobOper and JobMtl records.
Centerpoint ERP
Employee
Epicor Prophet 21
Employee
1:1Centerpoint HR Employee records map to Epicor Kinetic Employee. Employee records contain PII requiring explicit customer authorization before migration. We extract via flat-file export, sanitize any fields the customer designates for exclusion, and load into Epicor Employee with department, role, and manager hierarchy preserved. Employee-User linking in Epicor requires matching the employee record to a provisioned Epicor user account by email.
Centerpoint ERP
Purchase Order
Epicor Prophet 21
POHeader
1:1Centerpoint Purchasing Purchase Orders map to Epicor Kinetic POHeader with line items mapped to PODetail. Vendor name and number from Centerpoint resolve to Epicor Vendor references. Line item part numbers resolve against Epicor Part or a services description if non-inventory. Unit cost, quantity ordered, and UOM all migrate directly. Open versus closed PO status maps to Epicor POHeader.OpenStatus.
Centerpoint ERP
QHSE Record
Epicor Prophet 21
UD tables (Quality, Incident)
lossyCenterpoint QHSE records (compliance records, safety incidents, audits, inspections) have no direct Epicor Kinetic equivalent because Epicor's QHSE schema is industry-vertical and configuration-specific. We review the customer's QHSE configuration during discovery, map records to Epicor's Quality Management (for audits and inspections) and Incident (for safety records) UD tables if available, and document the mapping in a written schema report for the customer's admin to finalize. Non-mapped QHSE record types are archived as a CSV with Epicor UD table structure delivered as a separate import package.
Centerpoint ERP
Logistics Record
Epicor Prophet 21
Shipment and Customer ShipTo
1:1Centerpoint Logistics records (shipments, routes, carrier assignments) map to Epicor Kinetic Shipment records and Customer ShipTo address configurations. Carrier name normalization is required since Centerpoint and Epicor often use different carrier master naming conventions. Route assignments migrate as UD fields on Shipment if the destination Epicor installation does not have a native routing module enabled.
Centerpoint ERP
Owner (CRM user)
Epicor Prophet 21
Epicor Kinetic User
1:1Centerpoint CRM owner assignments map to Epicor Kinetic User records. We resolve by email match against the destination Epicor User table. Any Centerpoint owner without a matching Epicor User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Owner historical assignment is preserved as a UD field on each record.
Centerpoint ERP
Financial Accounting data
Epicor Prophet 21
Not migrated (separate accounting system)
1:1Centerpoint ERP is operational-first and many customers run it alongside dedicated financial accounting software. We do not migrate financial transactions, journal entries, or general ledger balances as those are outside Centerpoint's core strength and are typically sourced from a separate accounting system already. We flag the customer accounting data gap during scoping and recommend their existing financial software as the source for Epicor's AP/AR/GL migration if needed.
| Centerpoint ERP | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Contact | Customer1:1 | Fully supported | |
| Lead | Prospect1:1 | Fully supported | |
| Opportunity | SalesOrder or Quote1:many | Fully supported | |
| CRM Forecast (weighted/unweighted) | Forecast UD fields on SalesOrderlossy | Fully supported | |
| Asset | Asset (Equivnent)1:1 | Fully supported | |
| Work Order | Job1:1 | Fully supported | |
| Employee | Employee1:1 | Fully supported | |
| Purchase Order | POHeader1:1 | Fully supported | |
| QHSE Record | UD tables (Quality, Incident)lossy | Fully supported | |
| Logistics Record | Shipment and Customer ShipTo1:1 | Fully supported | |
| Owner (CRM user) | Epicor Kinetic User1:1 | Fully supported | |
| Financial Accounting data | Not migrated (separate accounting system)1:1 | 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.
Centerpoint ERP gotchas
No public API forces manual export-based migration
Two distinct products share the CenterPoint name
CRM forecast data requires explicit mapping for weighted/unweighted values
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
Discovery and extraction audit
We conduct a scoping engagement that inventories every Centerpoint ERP module in use (CRM Contacts, Leads, Opportunities; Asset Management; Work Orders; HR Employees; Purchasing; QHSE; Logistics), estimates record volumes per entity, and identifies any Red Wing Software custom export programs the customer has licensed. We also confirm whether the customer runs Centerpoint cloud or on-premise CenterPoint Accounting, as the file formats and export capabilities differ. The discovery output is a written extraction plan with entity dependency order, estimated file sizes, and any Centerpoint custom export program requirements.
Epicor schema and UD table design
We design the destination Epicor Kinetic schema in a non-production environment. This includes creating UD columns on standard tables (Customer, SalesOrder, Equivnent, Job, POHeader, Employee) for Centerpoint custom properties, provisioning UD tables for QHSE records, configuring address roles, and setting up part number cross-references. We map the Centerpoint asset hierarchy to Epicor Equivnent parent links and the Work Order to Job relationship, resolving part numbers against the Epicor Part master. The schema is deployed to a Sandbox or non-production Epicor company for the customer's admin to validate before migration begins.
Flat-file extraction from Centerpoint
We guide the customer's Centerpoint administrator through the export sequence: CRM owner records first (so we can build the User email map), then Companies and Contacts, then Leads and Opportunities, then Assets, Work Orders, Employees, Purchase Orders, QHSE records, and Logistics data in dependency order. Each module export produces a delimited file. We transform each file to match the Epicor import schema, normalize carrier and vendor names against a master list, resolve parent-record IDs, and apply the forecast migration strategy agreed during scoping. The extraction phase is the critical path for timeline because Centerpoint has no API for automated data pulling.
Data validation and reconciliation
We run reconciliation checks on the extracted flat files before any Epicor ingestion. Duplicate detection identifies duplicate Customers (by name and address), duplicate Parts (by part number), and duplicate Vendors. We flag inactive Customers or incomplete Vendor records for the customer's admin to confirm whether they should migrate. Work Order job-oper records are sequenced so that parent Job records insert before dependent JobOper and JobMtl records. Any records that fail Epicor validation rules during test ingestion are returned with error codes and corrected in the transformation layer before re-testing.
Sandbox migration and Epicor admin sign-off
We run a full migration into the Epicor non-production company using production-like data volumes. The customer's Epicor administrator reconciles record counts across every entity, spot-checks twenty to fifty records against the Centerpoint source data, validates the UD field values, and confirms that asset hierarchy and work order parent-child relationships rendered correctly in Epicor. Any mapping corrections are made in the transformation scripts and re-run. The customer signs off on the sandbox migration before we proceed to production.
Production migration, cutover, and hypercare
We execute production migration in dependency order: Users (manual provisioning validated), Vendors, Customers, Parts (for Work Order and PO resolution), Equivnent (Assets), SalesOrders (Opportunities), Jobs (Work Orders), POHeader, Employees, Activities, Shipments, then QHSE UD tables. Each phase emits a row-count reconciliation report. We freeze Centerpoint writes during the cutover window, run a final delta migration of any records modified during the window, then hand over to the customer's Epicor administrator. We provide a one-week hypercare window for reconciliation issues. QHSE automation configurations and compliance scoring logic do not migrate as code; we deliver a written inventory of these for the admin to rebuild in Epicor Kinetic.
Platform deep dives
Centerpoint 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 Centerpoint 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
Centerpoint ERP: Not publicly documented.
Data volume sensitivity
Centerpoint 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 Centerpoint ERP to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your Centerpoint 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 Centerpoint 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.