ERP migration
Field-level mapping, validation, and rollback between MERCI and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
MERCI
Source
Epicor Prophet 21
Destination
Compatibility
11 of 13
objects map 1:1 between MERCI and Epicor Prophet 21.
Complexity
CModerate
Timeline
6-10 weeks
Overview
Migrating from MERCI Cloud ERP to Epicor ERP is a multi-phase data project that requires a non-API extraction strategy, per-deployment schema discovery, and a manufacturing-capable destination. MERCI does not publish a public API, so we typically extract via database-level exports or CSV pulls coordinated with MERCI's hosting team. Because MERCI runs single-tenant per customer, each deployment carries custom fields, renamed objects, or modified picklists that we must discover before mapping begins. We use Epicor Kinetic REST APIs (with Bulk API for high-volume transactional records) to write data, handling parent-record lookup resolution for Orders to Customers, Line Items to Orders, and Invoices to Orders. Epicor is actively transitioning its installed base from on-premises to cloud, and Epicor Kinetic targets discrete, make-to-order, and job-shop manufacturers with 50-2,500 employees. We do not migrate workflows, automations, or EDI integrations as code; we deliver a written inventory of these for the customer's admin team to rebuild post-migration.
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 MERCI 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.
MERCI
Customer
Epicor Prophet 21
Customer
1:1MERCI Customer records map to Epicor ERP Customer (CustCnt or Customer table depending on Epicor version). We flatten MERCI's address and contact columns into Epicor Customer address fields (Address1, Address2, City, State, Zip, Country). Where MERCI uses custom customer classification codes, we map them to Epicor Customer Type or a User-Defined field and document the translation table during schema discovery. Billing and shipping addresses require separate address records in Epicor; MERCI's combined address fields are split accordingly.
MERCI
Customer Address
Epicor Prophet 21
Customer Address
1:manyMERCI stores a single address per Customer record. Epicor separates bill-to and ship-to addresses into distinct address objects. We create a primary ShipTo address record from MERCI's address and flag it as the default ship-to. If MERCI carries separate billing and shipping addresses, we map them to separate ShipTo and BillTo records in Epicor. Any custom address fields in MERCI ( freight codes, route numbers, FOB terms) migrate to Epicor ShipTo UD fields.
MERCI
Customer Contact
Epicor Prophet 21
Customer Contact
1:1MERCI contact records (name, phone, email, role) map to Epicor Customer Contact. We use the contact's email address as the dedupe key. Primary contact designation migrates to the IsPrimaryContact flag. Secondary contacts are created as additional Customer Contact records linked to the same CustomerNum.
MERCI
Sales Order
Epicor Prophet 21
Sales Order
1:1MERCI Sales Orders map to Epicor ERP SalesOrder. Order header fields (order number, order date, customer PO, terms, warehouse) migrate directly. Order dates and expiration logic transfer to Epicor OrderHed fields. Status translation requires mapping MERCI order status codes (open, partial, complete, cancelled) to Epicor OrderRel.OpenLine and OrderHed.OpenOrder flags. MERCI order totals and discount amounts are verified against Epicor's calculated totals post-import.
MERCI
Sales Order Line Item
Epicor Prophet 21
Sales Order Line
1:1MERCI line items migrate to Epicor OrderDtl records linked to the parent SalesOrder. Line-level fields (part number, quantity ordered, quantity shipped, unit of measure, unit price, discount) map to OrderDtl columns. Back-order logic from MERCI migrates to Epicor OrderRel records representing each ship-from warehouse and promised date. We handle partial line failures by inserting individual OrderDtl rows rather than blocking the entire order on a single line error.
MERCI
Invoice
Epicor Prophet 21
Invoice
1:1MERCI Invoices map to Epicor InvoiceHed records with invoice line items as InvoiceDtl. The MERCI-to-order linkage is preserved in Epicor by embedding the source order number in a UD field on the InvoiceHed. Open versus closed invoice status maps to Epicor's InvoiceHed.OpenInvoice flag. Payment terms from MERCI migrate to Epicor's Terms master and are linked by TermsCode. Fiscal period assignment is verified against Epicor's accounting calendar during import.
MERCI
Item
Epicor Prophet 21
Part
1:1MERCI Items (products and service variants) map to Epicor Part records. Fields including part number, description, unit of measure, and cost structure migrate to Epicor Part (PartNum, PartDescription,IUM, UnitCost). Pricing tiers from MERCI's item master migrate to Epicor PartPlant and PriceLBrk records. Bundle and kit compositions in MERCI must be expanded: the kit's component lines map to Epicor PartMtl (for manufactured kits) or to separate QuoteQty records, and we document the expansion logic for the customer's admin to validate.
MERCI
Item Pricing
Epicor Prophet 21
Price List / Price Break
lossyMERCI pricing schedules attached to items map to Epicor PriceLBrk (price break) and PriceGrp records. We extract each pricing tier from MERCI's pricing schedule and create corresponding Epicor price break records. If MERCI uses customer-specific pricing overrides, these migrate to Epicor OrderDtl.UnitPrice overrides rather than as separate price list entries.
MERCI
Chart of Accounts
Epicor Prophet 21
GL Account
1:1MERCI Chart of Accounts codes and names migrate to Epicor GL Account records. Account type mapping requires verification: MERCI uses a simplified five-type classification, while Epicor uses a more granular account type taxonomy (Asset, Liability, Equity, Revenue, Expense, and sub-types). We map MERCI account types to the closest Epicor equivalent during schema discovery and flag any ambiguous mappings for the customer's finance admin to confirm before final import.
MERCI
Vendor
Epicor Prophet 21
Vendor
1:1MERCI Vendor records map to Epicor ERP Vendor. The vendor contact structure mirrors the customer contact structure: we flatten MERCI vendor address columns, create a primary VendorPP address record, and map bank account and payment terms to Epicor VendorPP (Vendor Payment) fields. Any MERCI vendor classification codes map to Epicor VendorType or a UD field.
MERCI
Employee
Epicor Prophet 21
Employee
1:1MERCI Employee records (department, job title, hire date) map to Epicor Employee. Compensation fields require effective-date handling in Epicor: MERCI's current compensation amount maps to the most recent Epicor EmpBasic row, and if historical compensation data is present in MERCI, we create additional effective-dated rows in Epicor's LaborHistory or EmpBasic history tables. Department and job title migrate to Epicor EmpBasic.DcdnfldID or UD fields.
MERCI
Warehouse / Site
Epicor Prophet 21
Plant / Warehouse
1:1MERCI warehouse records (if present as a standalone entity) map to Epicor Plant and Warehse. If MERCI uses a single-site model, we create one Plant and one Warehse record in Epicor. Multi-site MERCI deployments create multiple Plant records with corresponding Warehse records per site, and inventory quantities are allocated to the correct site during item import.
MERCI
Attachments
Epicor Prophet 21
Not Migrated
1:1MERCI binary attachments (order documents, PDFs, images) cannot be retrieved via any documented API endpoint or standard CSV export. We flag attachment objects as unsupported during scoping and direct customers to the MERCI UI for manual download or to request a full blob export from their account manager. If the blob export exceeds a practical browser-download threshold, we recommend a direct database dump of the attachment store coordinated with MERCI's hosting team as a separate workstream.
| MERCI | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Customer | Customer1:1 | Fully supported | |
| Customer Address | Customer Address1:many | Fully supported | |
| Customer Contact | Customer Contact1:1 | Fully supported | |
| Sales Order | Sales Order1:1 | Fully supported | |
| Sales Order Line Item | Sales Order Line1:1 | Fully supported | |
| Invoice | Invoice1:1 | Fully supported | |
| Item | Part1:1 | Fully supported | |
| Item Pricing | Price List / Price Breaklossy | Fully supported | |
| Chart of Accounts | GL Account1:1 | Mapping required | |
| Vendor | Vendor1:1 | Fully supported | |
| Employee | Employee1:1 | Fully supported | |
| Warehouse / Site | Plant / Warehouse1:1 | Fully supported | |
| Attachments | Not Migrated1:1 | Not 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.
MERCI gotchas
No public API documentation found
Single-tenant schema variation across deployments
Binary attachment export not supported via API
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
MERCI deployment profiling and extraction design
We connect to the MERCI instance via the coordination method agreed with MERCI's hosting team (database read or CSV export) and conduct a full schema discovery pass. This pass identifies standard objects, custom fields, non-standard picklist values, foreign-key columns, and any deprecated or renamed fields. The output is a written MERCI Schema Inventory unique to this deployment. We design extraction queries against the discovered schema and agree on an extraction schedule that minimizes production impact. If MERCI charges fees for database access or export support, we document those as a customer-managed cost.
Epicor Kinetic environment preparation
We assess the destination Epicor Kinetic environment: cloud tier (Essential, Advanced, or Premium), enabled modules (Financial Management, Order Management, Advanced Material Management, MES), and current UD field configuration. We create a destination schema plan covering Part records, Customer records, Vendor records, GL Account structure, Employee records, and the Order and Invoice parent-child hierarchies. If UD fields are required for MERCI custom fields, we design the UD field schema (UD01, UD08, or custom UD tables) and document any BPM requirements for UD field population. Schema is validated in the Epicor Kinetic sandbox or development environment before production migration begins.
Data cleansing and transformation
We extract MERCI data using the agreed method and run a data profiling pass against the raw extract. Common issues identified at this stage include duplicate customer records (same company under slightly different names), inconsistent date formats across exports, missing required fields in MERCI (such as unpopulated customer terms), and non-standard picklist codes that require value translation. We build a transformation script for each object that addresses these issues, generates a cleansing report, and applies customer-approved business rules (such as which duplicate to keep or how to handle records with missing critical fields). Cleansed data is staged in a migration work area for reconciliation before Epicor import.
Parent-record dependency ordering and Epicor import
We sequence Epicor imports in strict dependency order to satisfy foreign-key requirements. The sequence is: GL Accounts first (required for financial transactions), then Customers and Customer Contacts, then Vendors, then Parts (with BOM and kit expansion handled separately), then Employees, then Sales Orders (with CustomerNum and ShipToNum resolved), then Order Lines, then Invoices (with OrderNum and InvoiceNum resolved). Each phase emits a row-count reconciliation report and a field-level validation summary before the next phase begins. We use Epicor Kinetic REST APIs for standard inserts and the Bulk API for high-volume transactional records (order lines, invoice lines) with chunking and exponential backoff on rate-limit responses.
UD field population and BPM deployment
If the migration scope includes UD field population (for MERCI custom fields mapped to Epicor UD fields), we deploy a post-import data patch or a BPM method to populate those fields. This step runs after the base field imports are reconciled and before final validation. We test the UD population against a sample of records (minimum 5% of the import volume) before running it across the full dataset. Any UD field that requires logic beyond a direct field-to-field copy is documented as a BPM requirement for the customer's Epicor admin to implement or for a separate Epicor consulting engagement.
Final reconciliation, cutover handoff, and automation inventory
We run a final reconciliation comparing MERCI source record counts and totals against Epicor destination records. The customer reviews and signs off the reconciliation report. We freeze MERCI writes during cutover, extract a final delta of any records modified during the migration window, and load the delta into Epicor. We deliver a written inventory of MERCI workflows, automations, and any EDI integrations that were identified during scoping but are outside migration scope, with recommended Epicor equivalents (Epicor Data Fabric, Kinetic Workflow, or third-party EDI platforms). We do not rebuild these as part of the standard migration. Post-cutover, we support a one-week hypercare window for reconciliation issues raised by the customer's team.
Platform deep dives
MERCI
Source
Strengths
Weaknesses
Epicor Prophet 21
Destination
Strengths
Weaknesses
Complexity grading
Moderate ERP migration. 4 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across MERCI and Epicor Prophet 21.
Object compatibility
4 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
MERCI: Per-call billed (₹0.56/call) rather than throttled — cost acts as a soft throttle.
Data volume sensitivity
MERCI exposes a bulk API — large-volume migrations stream efficiently.
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 MERCI to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your MERCI 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 MERCI
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.