ERP migration

Migrate from metasfresh to Epicor Prophet 21

Field-level mapping, validation, and rollback between metasfresh and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.

metasfresh logo

metasfresh

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

75%

9 of 12

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

Complexity

BStandard

Timeline

5-8 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from metasfresh to Epicor ERP is a structural migration from an open-source PostgreSQL-backed ERP with no public REST API to a commercial cloud ERP with the Kinetic Data Management Tool (DMT) as its primary bulk import interface. metasfresh stores its entire business model across PostgreSQL tables including C_BPartner, M_Product, C_Order, C_Invoice, and pp_product_bom; Epicor ERP maps these to Customer/Supplier, Part, OrderHed/OrderDtl, AR/AP Invoice, and Job record structures. We connect to the metasfresh PostgreSQL instance directly, build normalized export sets that respect table dependencies and BOM lineage, then stage them for Epicor DMT loading in the correct object sequence. Epicor BPMs (Business Process Management), customizations, and SSRS reports do not migrate; we deliver a written inventory for the customer's Epicor admin 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

metasfresh logo

metasfresh

What's pushing teams away

  • Steep learning curve when configuring the system for industries outside its default food and beverage workflows, requiring significant consultant time.
  • Installation and build times can be slow, with users reporting the application sometimes hanging during Docker image builds.
  • Not a turnkey solution — companies without technical staff or ERP experience may struggle to configure and maintain metasfresh without external help.
  • Self-hosting responsibility means no vendor-managed updates, backups, or SLA, which some companies prefer to outsource to a SaaS provider.

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 metasfresh objects map to Epicor Prophet 21

Each row shows how a metasfresh 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.

metasfresh

Business Partner (C_BPartner)

maps to

Epicor Prophet 21

Customer or Supplier

1:1
Fully supported

metasfresh Business Partners with BPartner_Composite.C_BPartner_ID resolve to Epicor Customer (if isCustomer=true) or Supplier (if isVendor=true). Many metasfresh records are both customer and vendor simultaneously; we create both a Customer and a Supplier record in Epicor linked to the same Party record. Address data (C_BP_Location) maps to Epicor CustomerShpTo records with the default ship-to flagged per the metasfresh IsActiveToDefault flag. Contact data (C_BP_Contact) maps to Epicor Contact records linked to the Party.

metasfresh

Product (M_Product)

maps to

Epicor Prophet 21

Part

1:1
Fully supported

metasfresh Products map to Epicor Part records. The M_Product.Value field becomes Part Number; the name becomes Part Description. Product type (Item vs Service vs Resource) maps to Part Type (Stocked, Non-Stock, Service, Charge). The metasfresh Product Category (M_Product_Category) maps to Epicor Product Group. We query the AD_Column table during discovery to capture all custom fields on M_Product and map them to UD fields on Part before migration.

metasfresh

Sales Order (C_Order, C_OrderLine)

maps to

Epicor Prophet 21

OrderHed + OrderDtl

1:1
Fully supported

metasfresh Sales Orders map to Epicor OrderHed (order header) and OrderDtl (order lines). The C_Order.C_DocType_ID mapping to Epicor OrderRel quoting the correct Doc Types. Document status (C_DocType targets for SO, PO, RMAS) maps to Epicor's Open status fields. Order date, promised date, and discount percentages transfer directly. Header-level charges (C_Order_Header_Acct) map to OrderMsc records in Epicor.

metasfresh

Purchase Order (C_Order with DocType=Purchase)

maps to

Epicor Prophet 21

POHeader + PODetail

1:1
Fully supported

metasfresh Purchase Orders follow the same C_Order structure with a different DocType. We filter by DocTypeTarget during extraction and map to Epicor POHeader and PODetail. Vendor part numbers from C_BPartner_Product map to PartPlant VendorPartNum for reference.

metasfresh

Invoice (C_Invoice, C_InvoiceLine)

maps to

Epicor Prophet 21

AR Invoice or AP Invoice

1:1
Fully supported

metasfresh AR Invoices (C_Invoice with DocBaseType=ARI) map to Epicor AR Invoice records; AP Invoices map to Epicor AP Invoice records. The C_InvoiceLine lines map to InvoiceDtl with tax codes resolved from metasfresh C_Tax. We handle InvoiceGSTR to the extent metasfresh tax configuration uses standard tax categories, but VAT and GST jurisdictions outside the DACH default require manual tax code mapping review before final load.

metasfresh

BOM (pp_product_bom, pp_product_bomline)

maps to

Epicor Prophet 21

Job and Estimate (with BOM structure)

1:1
Fully supported

metasfresh BOMs stored in pp_product_bom and pp_product_bomline require careful mapping to Epicor's multi-level BOM and Job structure. We inspect the PP_Product_BOM table during discovery and include BOM lines only when the MRP module is enabled and pp_product_bomline records are populated. Each metasfresh BOM becomes an Epicor Part BOM revision linked to the finished Part, and an Epicor Job or Estimate is created for any in-process manufacturing orders referenced in pp_order_bomrecord. Orphaned BOM component references that cannot resolve to a Part in the destination are flagged in the reconciliation report.

metasfresh

Pricing System (M_PricingSystem, M_PriceList, M_PriceList_Version)

maps to

Epicor Prophet 21

PriceLst + PriceLstRev

lossy
Fully supported

metasfresh organizes pricing into M_PricingSystem containing M_PriceList records with M_PriceList_Version versions and M_ProductPrice entries. We export the full pricing hierarchy and map to Epicor's PriceLst (price list header), PriceLstRev (price list revision with effective dates), and PriceLstParts entries. Versioned pricing with effective date ranges becomes separate PriceLstRev records in Epicor. Quantity breaks stored in M_ProductPrice (if present) map to Epicor PriceBreaks.

metasfresh

Project (C_Project, C_ProjectLine)

maps to

Epicor Prophet 21

Project

1:1
Fully supported

metasfresh Projects map to Epicor Project records. Project phases and milestones in C_ProjectLine map to Epicor WBS Phases. Project type (standard vs phase-based) maps to Epicor Project Type. We flag that Epicor Project DMT imports require specific table ordering: Project must load before WBS Phases, and CS Project must link back to Sales Order before WBS Phase creation, per Epicor DMT community guidance.

metasfresh

Bank Account (C_BP_BankAccount)

maps to

Epicor Prophet 21

BankAcct

1:1
Fully supported

Bank accounts stored per Business Partner and per organization map to Epicor BankAcct records. Bank account numbers, routing codes, and IBAN data transfer to BankAcct fields. We map per-organization bank accounts by reading C_BP_BankAccount with its AD_Org_ID and linking to the corresponding Epicor Company-level bank account.

metasfresh

Payment Terms (C_PaymentTerm)

maps to

Epicor Prophet 21

PaymentTerms

1:1
Fully supported

metasfresh payment terms (net 30, 2/10 net 30, etc.) stored in C_PaymentTerm map directly to Epicor PaymentTerms. Discount percentages and net due days transfer to the DiscountPercent, DueDays, and MaxDate fields in Epicor.

metasfresh

Tax Category and Tax Rate (C_Tax, C_TaxCategory)

maps to

Epicor Prophet 21

TaxRpt and TaxZone Rates

lossy
Fully supported

metasfresh tax categories and rates map to Epicor TaxRpt codes linked to TaxZone-based rate tables. We preserve the full tax configuration including effective date ranges where metasfresh stores them. Multi-jurisdiction setups (DACH vs other regions) may require the customer's Epicor admin to map the metasfresh tax category IDs to the correct Epicor TaxRpt codes during final validation.

metasfresh

Custom Fields (AD_Column with custom flag)

maps to

Epicor Prophet 21

UD fields (Part_c, OrderHed_c, etc.)

lossy
Fully supported

metasfresh custom fields added via the Table and Column system are stored as rows in AD_Column with a custom flag. They are not surfaced in the standard metasfresh export format. We query AD_Column during the discovery phase to identify all custom fields per table, determine their data types, and create corresponding UD (User-Defined) fields in Epicor before migration. Custom field values are then included as additional columns in the export and loaded via DMT or REST API into the corresponding UD field.

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.

metasfresh logo

metasfresh gotchas

High

No well-documented public REST API for data migration

High

Attachment and archived document extraction is unreliable

Medium

BOM and manufacturing data requires deep schema knowledge

Medium

Custom fields discovered at runtime, not import time

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

  • metasfresh has no REST API — extraction relies on PostgreSQL

    metasfresh does not publish a consumer-facing REST API with documented endpoints for programmatic data extraction. All data migrations require a direct connection to the metasfresh PostgreSQL instance using read-only credentials. We construct SQL queries against the underlying tables to build normalized export sets. This approach is stable but requires upfront schema discovery for each metasfresh installation because the database structure may vary based on installed modules and custom AD_Column additions. We flag any table access that the read-only user cannot reach and escalate before extraction begins.

  • Epicor Project DMT requires strict table ordering for WBS Phases

    Epicor's Data Management Tool imposes a specific load sequence for project-based data. Community forum threads on epiusers.help document that loading Projects before WBS Phases, then linking CS Projects back to Sales Orders, causes WBS Phase creation to fail if Phase ID is not populated correctly. We follow the Epicor-recommended order: Projects first (optionally using ProjectsCombined DMT), then WBS Phases, then Project Job or CS Project linking. We also note that Job numbers generated by Epicor during the DMT import may not match original metasfresh Job numbers, and we flag this for the customer's project finance team before finalizing WIP cost mapping.

  • BOM and MRP module must be verified active before BOM migration

    metasfresh stores bill of materials data across pp_product_bom, pp_product_bomline, and pp_order_bomrecord tables. These tables have dependencies on the MRP module that may not be active in all metasfresh installations. We inspect the PP_Product_BOM and PP tables during discovery and include BOM lines only when they are populated and the MRP module is confirmed enabled. BOMs with components that cannot resolve to a migrated Part number are excluded from the BOM migration deliverable and listed separately in the reconciliation report for manual resolution.

  • Epicor BPM customizations and UD field population logic do not migrate

    Epicor UD (User-Defined) fields require Business Process Management (BPM) logic to populate automatically in many Epicor deployments. Custom field population rules, cross-field dependencies, and conditional defaulting built in Epicor BPM do not migrate. We map metasfresh AD_Column custom field values to Epicor UD fields during the initial DMT load, but any post-load BPM-driven population logic must be rebuilt by the customer's Epicor admin. This is a manual rebuild scope we document in the handoff inventory.

  • Attachment and archived document extraction is unreliable in metasfresh

    metasfresh stores archived invoice PDFs and file attachments as byte arrays in the database or as file system references whose paths are not consistently tracked in metadata tables. There is no supported export path for these objects. We flag this explicitly during scoping and exclude attachments from the migration deliverable unless the customer confirms they have direct database access to retrieve them manually. We recommend Epicor Content Server as the post-migration document repository and advise the customer to re-scan or re-import key documents after go-live.

Migration approach

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

  1. Discovery and metasfresh PostgreSQL schema audit

    We connect to the metasfresh PostgreSQL instance using read-only credentials and audit the installed tables across all schemas (ad, c, m, pp, gl, r). We enumerate all C_BPartner records with their composite flag state, all M_Product records with product type and category, all C_Order and C_Invoice records with document status and line counts, and all pp_product_bom records with BOM line counts and MRP module status. We query AD_Column to identify custom fields on each table and record their data types. The discovery output is a written schema map, record counts per object, and a BOM/MRP activation confirmation checklist.

  2. Epicor environment sizing and DMT template preparation

    We work with the customer to confirm the target Epicor environment (Kinetic Cloud, Prophet 21, or on-premise) and sizing. We identify the DMT templates required for each object class (Customer, Supplier, Part, OrderHed, OrderDtl, POHeader, PODetail, ARInvoice, APInvoice, Job, Project, WBS Phase, PriceLst, PriceLstRev). For each template, we map metasfresh source columns to Epicor destination columns, handling type conversions (date formats, numeric precision, boolean flags) and documenting any required UD field creation before DMT load begins.

  3. Pricing hierarchy and BOM lineage construction

    We export the metasfresh pricing hierarchy: M_PricingSystem nodes, M_PriceList versions, and M_ProductPrice entries with effective dates. We resolve quantity break pricing where present. For BOMs, we traverse the pp_product_bom and pp_product_bomline table relationships to construct a full component lineage for each finished product. We cross-reference component Part numbers against the exported M_Product set and flag any component that has no corresponding Part record in the destination. This resolves to a BOM readiness report before Epicor Job creation begins.

  4. Sandbox migration and reconciliation

    We run a full migration into the Epicor Sandbox environment using production-like data volume. The customer's Epicor administrator reconciles record counts per object (Customers in, Suppliers in, Parts in, Orders in, Order lines in, Invoices in, BOMs in), spot-checks 25-50 random records against the metasfresh source, and validates that BOM structure in Epicor Part maintenance matches the source metasfresh BOM. Any mapping corrections, missing UD field creations, or BOM component resolution happen in the Sandbox before production migration begins.

  5. Production migration in dependency order

    We run production migration in the Epicor-recommended DMT object order: Customers and Suppliers (with Party linkage), Parts (with Product Group and Part Type), Price Lists and Price Breaks, Sales Orders and Purchase Orders (with header and line resolution), AR/AP Invoices, BOM revisions on Parts, Jobs and Estimates (for in-process manufacturing orders), Projects (using ProjectsCombined if project-job creation is required), WBS Phases (after Project linkback to Sales Order is confirmed), and Bank Accounts and Payment Terms. Each phase emits a row-count reconciliation report before the next phase begins.

  6. Cutover, validation, and customization handoff

    We freeze metasfresh writes during the cutover window, run a final delta migration of any records created or modified during the migration window, then enable Epicor ERP as the system of record. We deliver a written inventory of every Epicor BPM customization required, every UD field that needs post-load population logic, and every SSRS report that requires rebuild against the migrated schema. We support a one-week hypercare window where we resolve reconciliation issues raised by the customer's team. We do not rebuild BPMs, customizations, or reports as part of the migration scope; those are documented for the customer's Epicor admin or implementation partner.

Platform deep dives

Context on both ends of the pair

metasfresh logo

metasfresh

Source

Strengths

  • Completely free and open-source under GPLv2/GPLv3 with no per-user or per-company license fees.
  • Docker and Kubernetes deployment flexibility gives full infrastructure control and data sovereignty.
  • DATEV accounting export built in serves the DACH region's tax advisor workflow natively.
  • 60,000+ commits and active development since 2004 indicate long-term project stability.
  • Source code access enables deep customization that commercial ERPs charge premium tiers for.

Weaknesses

  • No vendor-managed cloud hosting option with SLA — self-hosting and maintenance are entirely the customer's responsibility.
  • Public REST API is not well-documented; migrations rely on flat-file exports, SQL access, or metasfresh's internal migration tooling.
  • Installation and build processes can be slow and unreliable, especially in Docker environments without pre-configured resources.
  • Default workflows favor food and beverage industry, requiring significant reconfiguration for other verticals.
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?

Standard ERP migration. 2 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

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

  • Object compatibility

    B

    2 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

    B

    metasfresh: Not publicly documented.

  • Data volume sensitivity

    B

    metasfresh doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your metasfresh 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 metasfresh to Epicor Prophet 21 data migrations

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

Can't find your answer?

Walk through your metasfresh 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 five and eight weeks for accounts with fewer than 10,000 Business Partners, 5,000 Products, and no active MRP/BOM module. Migrations with populated pp_product_bom tables, multi-level BOM structures, versioned pricing hierarchies, or more than 20,000 total records move to twelve to eighteen weeks because of BOM lineage resolution, pricing break mapping, and Epicor DMT template construction. Epicor ERP implementations themselves typically run five to ten months according to vendor documentation, but the data migration phase alone (which is our scope) follows the timelines above.

Adjacent paths

Related migrations to explore

Ready when you are

Move from metasfresh.
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