ERP migration

Migrate from MERCI to Epicor Prophet 21

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 logo

MERCI

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

85%

11 of 13

objects map 1:1 between MERCI and Epicor Prophet 21.

Complexity

CModerate

Timeline

6-10 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

MERCI logo

MERCI

What's pushing teams away

  • Per-API-call pricing (₹0.48, revised to ₹0.56 as of May 1, 2025) creates ongoing operational cost for high-volume E-Invoice and E-Way Bill users.
  • Specific tiered pricing for the full ERP system is not clearly published — buyers must contact Merciglobal sales for non-API costs.
  • Vendor footprint primarily in India; international support and partner network are thin.
  • Reviewer footprint on G2/Capterra/TrustRadius is limited compared to global cloud ERPs — peer benchmarking harder.
  • Documentation at docs.merciglobal.com focuses on GST APIs; full ERP API surface (financials, inventory, sales) is less prominently documented.

Choosing

Epicor Prophet 21 logo

Epicor Prophet 21

What's pulling them in

  • Industry-specific design for wholesale distributors, not a general-purpose ERP repurposed for distribution — distributors choose P21 because it matches their replenishment, kitting, and counter-sale workflows out of the box.
  • Strong inventory control with automated replenishment, lot and serial tracking, and multi-warehouse management appeals to distributors with complex stock requirements and tight margin pressure.
  • Responsive customer support cited across G2 and Gartner reviews, with Epicor's 90% retention rate reflecting long-term customer satisfaction in a market where switching costs are high.
  • Cloud deployment on Microsoft Azure provides the flexibility to scale user counts and warehouse locations without on-premise infrastructure investment.
  • The Software Development Kit lets distributors personalize P21 to their specific business processes without modifying the application source code, preserving upgrade paths.

Object mapping

How MERCI objects map to Epicor Prophet 21

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

maps to

Epicor Prophet 21

Customer

1:1
Fully supported

MERCI 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

maps to

Epicor Prophet 21

Customer Address

1:many
Fully supported

MERCI 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

maps to

Epicor Prophet 21

Customer Contact

1:1
Fully supported

MERCI 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

maps to

Epicor Prophet 21

Sales Order

1:1
Fully supported

MERCI 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

maps to

Epicor Prophet 21

Sales Order Line

1:1
Fully supported

MERCI 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

maps to

Epicor Prophet 21

Invoice

1:1
Fully supported

MERCI 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

maps to

Epicor Prophet 21

Part

1:1
Fully supported

MERCI 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

maps to

Epicor Prophet 21

Price List / Price Break

lossy
Fully supported

MERCI 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

maps to

Epicor Prophet 21

GL Account

1:1
Mapping required

MERCI 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

maps to

Epicor Prophet 21

Vendor

1:1
Fully supported

MERCI 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

maps to

Epicor Prophet 21

Employee

1:1
Fully supported

MERCI 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

maps to

Epicor Prophet 21

Plant / Warehouse

1:1
Fully supported

MERCI 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

maps to

Epicor Prophet 21

Not Migrated

1:1
Not supported

MERCI 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.

Gotchas + challenges

What specifically takes care here

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 logo

MERCI gotchas

High

No public API documentation found

Medium

Single-tenant schema variation across deployments

Medium

Binary attachment export not supported via API

Epicor Prophet 21 logo

Epicor Prophet 21 gotchas

High

Third-party bolt-on integrations complicate migration scope

High

Dirty data without standardized processes compounds migration risk

Medium

SDK customizations and BPMs may not survive platform upgrades

Medium

Report-based export only for non-technical users

Low

Per-user pricing model requires accurate user count before migration planning

Pair-specific challenges

  • MERCI has no public API — extraction relies on CSV exports or database access

    MERCI Cloud ERP does not publish API documentation, rate limits, authentication schemes, or bulk export endpoints in any public source. Migration planning must assume manual CSV exports or a direct database read from the AWS-hosted instance. Both paths require coordination with MERCI's hosting team and may involve additional fees or revised SLAs. We build the extraction scripts against the actual MERCI deployment schema (discovered during profiling), not against a notional baseline, which extends the timeline by one to two weeks for schema reconciliation before data movement begins.

  • Single-tenant schema variation requires per-deployment custom field discovery

    Each MERCI deployment runs single-tenant and may carry custom fields, renamed standard objects, or modified picklists that diverge from any baseline schema. We conduct a formal data profiling phase on the specific MERCI instance before any mapping or extraction begins. This phase identifies custom columns, non-standard picklist codes, and relationship columns (foreign keys) that must be rehydrated. Migrations that skip this phase and assume a standard MERCI schema typically encounter 15-40% record rejection on first import into Epicor due to field length mismatches, type conflicts, or missing required fields that were present in the MERCI instance but absent from the baseline assumption.

  • Epicor UD field population may require BPM development

    Epicor Kinetic User-Defined (UD) fields are not populated directly by standard data import. Forum discussions on epiusers.help document that populating UD fields during import requires a Business Process Management (BPM) method (a server-side logic hook) to read the imported base field value and write it to the corresponding UD field. We include UD field population logic as part of the import design, either as a pre-import BPM or as a post-import data patch. Customers should confirm that their Epicor Kinetic tier supports custom BPM development or that Epicor consulting is available to assist.

  • On-prem to cloud Epicor migration affects BPM compatibility

    Epicor users migrating from on-premises to Kinetic cloud report that custom BPMs written for on-premises Epicor environments frequently require rewriting for cloud compatibility. If the destination Epicor ERP instance was previously on-premises and retains custom BPM logic, the migration may require a BPM audit and update alongside the data migration. Epicor's cloud upgrade path (referred to as conversion passes) allows for iterative testing of BPM compatibility before final cutover. We coordinate with the customer's Epicor admin to flag BPM dependencies during scoping.

  • Chart of Accounts type taxonomy differs between MERCI and Epicor

    MERCI uses a simplified five-type account classification (Asset, Liability, Equity, Revenue, Expense). Epicor ERP uses a more granular account type hierarchy with sub-types and natural account groupings. Direct account code migration without taxonomy verification can result in accounts posting to the wrong financial category in Epicor. We map MERCI account types to Epicor account types during schema discovery, flag any accounts where the type assignment is ambiguous (such as suspense accounts or intercompany accounts), and require customer finance team sign-off on the mapping table before GL account import begins.

Migration approach

Six steps for a successful MERCI to Epicor Prophet 21 data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

MERCI logo

MERCI

Source

Strengths

  • All-in-one platform consolidates sales, CRM, financials, and operations into a single database
  • Cloud-hosted on AWS with automated backups and automatic failover systems
  • SLA commitment of 99.9% uptime as stated on their public materials
  • Single-tenant deployment model keeps customer data isolated per installation
  • Affordable positioning targets SMBs seeking to replace fragmented point solutions

Weaknesses

  • No publicly documented API — migration relies on CSV exports or direct database access
  • Single-tenant model means each deployment has a unique schema, requiring per-instance mapping
  • Limited industry-specific functionality compared to vertical ERPs
  • Small vendor footprint makes support responsiveness and long-term viability less certain
  • No published pricing tiers or transparent cost structure in public sources
Epicor Prophet 21 logo

Epicor Prophet 21

Destination

Strengths

  • Purpose-built for wholesale distribution with industry-specific replenishment, kitting, and counter-sale workflows out of the box.
  • Multi-warehouse management with bin locations, cross-docking, and real-time inventory visibility across all warehouse locations.
  • Automated replenishment engine with demand-based and min-max planning reduces stockouts and overstock carrying costs.
  • AI-infused reporting via Epicor Prism provides Gen AI-driven insights into ERP data without requiring a BI team.
  • Strong customer retention at 90% and a 50-year track record in the distribution vertical provides long-term vendor stability.

Weaknesses

  • High total cost of ownership — per-user pricing of $150-200/month plus $10K-$500K implementation creates significant budget commitment for small and mid-market distributors.
  • Customization via SDK requires technical expertise and introduces upgrade risk when custom code conflicts with new P21 releases.
  • Report generation performance is a known pain point — multiple users report system freezes during large or complex report exports.
  • Third-party bolt-on reliance for functionality that competitors include natively increases integration complexity and total solution cost.
  • Limited public API documentation — developers building custom integrations report difficulty finding P21 API authentication methods and endpoint specifications.

Complexity grading

How hard is this migration?

Moderate ERP migration. 4 of 8 objects need a mapping; the rest are 1:1.

C

Overall complexity

Moderate migration

Derived from compatibility, mapping clarity, API constraints, and data volume across MERCI and Epicor Prophet 21.

  • Object compatibility

    C

    4 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    C

    MERCI: Per-call billed (₹0.56/call) rather than throttled — cost acts as a soft throttle.

  • Data volume sensitivity

    A

    MERCI exposes a bulk API — large-volume migrations stream efficiently.

Estimator

Estimate your MERCI to Epicor Prophet 21 migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about MERCI to Epicor Prophet 21 data migrations

Answers to the questions buyers ask most during MERCI to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most migrations land between six and ten weeks for accounts with up to 10,000 customers, 20,000 orders, and minimal per-deployment custom field variation. Migrations with significant schema variation (custom fields, renamed objects, modified picklists discovered during profiling), high-volume transactional history (over 100,000 invoices or line items), or multi-site Epicor Kinetic configurations move to fourteen to twenty-two weeks because of extended schema reconciliation, BOM and kit expansion work, and Bulk API chunking for large transactional tables.

Adjacent paths

Related migrations to explore

Ready when you are

Move from MERCI.
Land in Epicor Prophet 21, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day