ERP migration
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
Source
Epicor Prophet 21
Destination
Compatibility
9 of 12
objects map 1:1 between metasfresh and Epicor Prophet 21.
Complexity
BStandard
Timeline
5-8 weeks
Overview
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.
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 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)
Epicor Prophet 21
Customer or Supplier
1:1metasfresh 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)
Epicor Prophet 21
Part
1:1metasfresh 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)
Epicor Prophet 21
OrderHed + OrderDtl
1:1metasfresh 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)
Epicor Prophet 21
POHeader + PODetail
1:1metasfresh 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)
Epicor Prophet 21
AR Invoice or AP Invoice
1:1metasfresh 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)
Epicor Prophet 21
Job and Estimate (with BOM structure)
1:1metasfresh 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)
Epicor Prophet 21
PriceLst + PriceLstRev
lossymetasfresh 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)
Epicor Prophet 21
Project
1:1metasfresh 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)
Epicor Prophet 21
BankAcct
1:1Bank 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)
Epicor Prophet 21
PaymentTerms
1:1metasfresh 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)
Epicor Prophet 21
TaxRpt and TaxZone Rates
lossymetasfresh 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)
Epicor Prophet 21
UD fields (Part_c, OrderHed_c, etc.)
lossymetasfresh 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.
| metasfresh | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Business Partner (C_BPartner) | Customer or Supplier1:1 | Fully supported | |
| Product (M_Product) | Part1:1 | Fully supported | |
| Sales Order (C_Order, C_OrderLine) | OrderHed + OrderDtl1:1 | Fully supported | |
| Purchase Order (C_Order with DocType=Purchase) | POHeader + PODetail1:1 | Fully supported | |
| Invoice (C_Invoice, C_InvoiceLine) | AR Invoice or AP Invoice1:1 | Fully supported | |
| BOM (pp_product_bom, pp_product_bomline) | Job and Estimate (with BOM structure)1:1 | Fully supported | |
| Pricing System (M_PricingSystem, M_PriceList, M_PriceList_Version) | PriceLst + PriceLstRevlossy | Fully supported | |
| Project (C_Project, C_ProjectLine) | Project1:1 | Fully supported | |
| Bank Account (C_BP_BankAccount) | BankAcct1:1 | Fully supported | |
| Payment Terms (C_PaymentTerm) | PaymentTerms1:1 | Fully supported | |
| Tax Category and Tax Rate (C_Tax, C_TaxCategory) | TaxRpt and TaxZone Rateslossy | Fully supported | |
| Custom Fields (AD_Column with custom flag) | UD fields (Part_c, OrderHed_c, etc.)lossy | 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.
metasfresh gotchas
No well-documented public REST API for data migration
Attachment and archived document extraction is unreliable
BOM and manufacturing data requires deep schema knowledge
Custom fields discovered at runtime, not import time
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 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.
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.
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.
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.
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.
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
metasfresh
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 metasfresh 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
metasfresh: Not publicly documented.
Data volume sensitivity
metasfresh 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 metasfresh to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
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 consultationAdjacent paths
Other ways to leave metasfresh
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.