ERP migration

Migrate from ERP Mark 7 to Epicor Prophet 21

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

ERP Mark 7 logo

ERP Mark 7

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

79%

11 of 14

objects map 1:1 between ERP Mark 7 and Epicor Prophet 21.

Complexity

BStandard

Timeline

5-8 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from ERP Mark 7 to Epicor ERP is a manufacturing-scale migration that reconstructs a richer production data model. ERP Mark 7 targets small manufacturers with modular cloud capabilities and per-instance custom fields but provides no public API documentation and has limited third-party ecosystem support. Epicor ERP (including Epicor Kinetic for cloud deployments) targets mid-market and larger manufacturers with deep BOM, routing, MES, and supply chain planning modules that ERP Mark 7 does not offer. We begin with a schema-discovery pass against the live ERP Mark 7 instance to enumerate available objects and custom fields, then design the Epicor target schema with Part, PartTran, JobMtl, JobOper, and related manufacturing tables in mind. Historical transactions migrate in fiscal-year batches with closed-period records locked in Epicor, and open AR/AP migrates as unresolved balances for reconciliation in the current period. We do not migrate workflows, production schedules, or custom BPM logic; we deliver a written inventory of these for the customer to rebuild post-migration with their Epicor implementation partner.

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

ERP Mark 7 logo

ERP Mark 7

What's pushing teams away

  • Limited public documentation and thin API visibility make integrations and customizations difficult to maintain long-term.
  • Smaller vendor footprint means fewer third-party consultants and add-ons compared to established ERP players, creating vendor-lock-in risk.
  • Support is available but reviewers note response times lag behind larger ERP vendors, particularly for complex configuration issues.
  • Pricing at scale ($90/user/month reported on SourceForge) becomes less competitive as headcount grows past 20–30 users.

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

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

ERP Mark 7

Customer

maps to

Epicor Prophet 21

Customer

1:1
Fully supported

ERP Mark 7 Customer records map to Epicor Customer (CustCnt parent records attached per Customer). We map address, contact details, payment terms, and 1099/W-9 status directly. The customer number from ERP Mark 7 becomes CustNum in Epicor with the original code preserved in the user-defined fields if it differs from the Epicor-assigned sequence. Multi-ship-to configurations in ERP Mark 7 map to Epicor ShipTo records linked to the Customer parent.

ERP Mark 7

Vendor

maps to

Epicor Prophet 21

Vendor

1:1
Fully supported

ERP Mark 7 Vendor records map to Epicor Vendor (VendCnt child records attached per Vendor). We preserve 1099 settings, W-9 status, payment terms, and bank information. The ERP Mark 7 vendor number becomes VendorNum in Epicor with the original code retained in a user-defined field. Multi-address vendors map to Epicor Vendors with VendCnt contact and address records.

ERP Mark 7

Item

maps to

Epicor Prophet 21

Part

1:1
Fully supported

ERP Mark 7 Items (products, raw materials, services) map to Epicor Part records. Item type (inventory vs. non-inventory vs. service) maps to Part.TypeCode. ERP Mark 7 custom fields on Items migrate to Epicor user-defined fields on Part. We flag any non-standard unit-of-measure configurations in ERP Mark 7 for manual review in Epicor Unit of Measure setup before Part import.

ERP Mark 7

Chart of Accounts

maps to

Epicor Prophet 21

GL Account

1:1
Mapping required

ERP Mark 7 COA entries map to Epicor GL Account records. We map account number, name, description, and account type directly. Any non-standard segment configurations (2-segment vs. Epicor's natural account + separate department segments) require a mapping table we build during schema design. The customer confirms the Epicor COA structure before we begin account import.

ERP Mark 7

Open AR

maps to

Epicor Prophet 21

Invoice + AR Adjustment

1:1
Fully supported

Open receivables in ERP Mark 7 migrate to Epicor Invoice records with invoice type AR Invoice. We carry through invoice number, customer reference, invoice date, due date, aging bucket, payment method, and outstanding balance. Each invoice creates an open AR record in Epicor with a remaining balance for reconciliation in the current fiscal period. Prepayments and credit memos migrate as separate invoice types.

ERP Mark 7

Open AP

maps to

Epicor Prophet 21

Invoice + AP Adjustment

1:1
Fully supported

Open payables in ERP Mark 7 migrate to Epicor AP Invoice records. We carry through vendor reference, invoice date, due date, aging bucket, payment terms, and outstanding balance. The AP Invoice is created in Epicor with the remaining balance open for reconciliation. Prepayments and debit memos migrate as separate AP Invoice types.

ERP Mark 7

Work Order

maps to

Epicor Prophet 21

Job

1:1
Fully supported

ERP Mark 7 Work Orders map to Epicor Job records. ERP Mark 7 links Work Orders to Items (as the part number) and BOMs; we reconstruct the Epicor JobMtl (material requirements) and JobOper (operation steps) records from the ERP Mark 7 work order structure. Custom fields on ERP Mark 7 work orders (machine center, priority flags) map to Epicor Job head user-defined fields and to JobOper user-defined fields. We flag active vs. completed Work Orders separately: active orders migrate as open Jobs; completed orders migrate as closed Job records.

ERP Mark 7

Item (BOM)

maps to

Epicor Prophet 21

PartBillOfMtl

lossy
Fully supported

ERP Mark 7 Items with Bill of Materials structures map to Epicor PartBillOfMtl records. Multi-level BOMs (parent, sub-assembly, component) require recursive mapping: we build the parent-to-component relationship and set the MtlBurden for each material line. If ERP Mark 7 uses phantom BOMs or co-products, we map these to Epicor PartBillOfMtl with the appropriate Revision and MtlPartNum references. BOM revision control in Epicor requires a target revision to be active before BOM import.

ERP Mark 7

Item (Routing)

maps to

Epicor Prophet 21

PartOpr

lossy
Fully supported

ERP Mark 7 Item routing steps (if exposed via schema discovery) map to Epicor PartOpr records linked to the Part. Each operation step includes Work Center, labor hours, machine hours, setup time, and operation sequence. If ERP Mark 7 routing data is not accessible via API or database export, we flag this during scoping and the customer works with their Epicor partner to rebuild routing data from source documents.

ERP Mark 7

Historical Transactions

maps to

Epicor Prophet 21

GLJrnLine + PartTran

1:1
Mapping required

Historical journal entries from ERP Mark 7 migrate to Epicor GLJrnLine records with fiscal period and fiscal year preserved. We segment historical data into pre-close and post-close batches: closed fiscal periods migrate as locked historical records; the current fiscal year migrates as open with a reconciliation step at cutover. Manufacturing transactions (PartTran records) migrate from ERP Mark 7 transaction history if accessible; PartTran carries part, quantity, warehouse, and plant data and requires a Part to exist in Epicor before PartTran insert.

ERP Mark 7

Document

maps to

Epicor Prophet 21

Document

1:1
Fully supported

ERP Mark 7 document attachments (stored as binary files linked to transactions, Items, or Customers) export in their native format and re-attach to the corresponding Epicor records via Epicor's Document Management (EDMS) module. We map the source record type and ID to the Epicor Key1, Key2, Key3 fields for traceability. Large binary attachments are chunked and validated post-upload.

ERP Mark 7

Custom Properties

maps to

Epicor Prophet 21

User-Defined Fields (UD)

lossy
Mapping required

ERP Mark 7 user-defined fields on standard objects (Customer, Vendor, Item, Work Order) map to Epicor user-defined fields on the equivalent table. We discover the full custom property set during the schema audit phase, diff against the standard object definition, and create corresponding Epicor UD columns before record import. Any UD fields that cannot map directly are flagged in the mapping document for manual entry or custom BPM population logic.

ERP Mark 7

User

maps to

Epicor Prophet 21

User

1:1
Fully supported

ERP Mark 7 User records (name, email, role, department) map to Epicor User records. Role names do not map 1:1 because Epicor uses its own security model with Company, Plant, Warehouse, and Department-based permissions. We match by email and flag roles requiring manual reassignment in Epicor User Security setup. Inactive users migrate with IsActive=false.

ERP Mark 7

Department

maps to

Epicor Prophet 21

Department

1:1
Fully supported

ERP Mark 7 Departments map to Epicor Department records. ERP Mark 7 allows nested hierarchies; Epicor uses a flat department structure per Company. We flatten nested ERP Mark 7 departments into Epicor Department records and flag any cost-center reporting dependencies that require reconfiguration post-migration.

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.

ERP Mark 7 logo

ERP Mark 7 gotchas

High

No publicly documented API endpoint reference

Medium

Custom fields are per-instance with no discovery mechanism

Medium

Historical transactions may span fiscal years with closes

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

  • ERP Mark 7 has no publicly documented API endpoint reference

    ERP Mark 7 does not publish a developer API reference or OpenAPI spec in the public domain. During migration scoping, we must probe actual API endpoints via live connection to enumerate available objects and field names. Without a reference schema, we run a schema-discovery pass against the live instance before committing to an object list. If the API is not accessible, we fall back to direct database export, which requires credentials the customer may not have retained. This adds a step to the discovery phase and can extend timelines by one to two weeks.

  • ERP Mark 7 custom fields are per-instance with no external catalog

    ERP Mark 7 allows user-defined fields on standard objects (Customer, Vendor, Item, Work Order), but these are not catalogued in any external metadata API. We cannot enumerate custom fields until we have a live authenticated session. We schedule a dedicated schema-audit call where we export a sample record set and diff the fields against the standard object definition to identify custom properties. Any missed custom fields appear as blank columns in Epicor and may require a supplemental import pass after the initial migration.

  • Epicor requires BOM revision to be active before PartBillOfMtl import

    Epicor enforces that a Part Revision exists and is marked active before BOM records can be imported against it. ERP Mark 7 does not have an equivalent revision control model for Items with BOMs. We build the Epicor Part and PartRev records first, set the revision to active, and then import PartBillOfMtl records referencing that revision. If ERP Mark 7 Items have multiple BOM versions, we map the most-recent active BOM to a single Epicor revision and flag additional revisions for manual creation or BOM comparison review.

  • Fiscal year closes in historical transactions require pre-migration boundary confirmation

    Manufacturing businesses running ERP Mark 7 often have multi-year transaction history with year-end closes applied. Migrating historical journal entries without preserving the close status causes Epicor to reopen closed periods. We segment the transaction migration into pre-close and post-close batches, migrate closed periods as locked historical GLJrnLine records, and leave the current fiscal year open for live reconciliation. The customer must confirm fiscal year boundaries before we begin transaction migration.

  • Epicor validation rules and field-level security can reject imported records silently

    Epicor orgs commonly enforce validation rules (required formats, conditional required fields, picklist whitelists) and field-level security that block import records if not explicitly bypassed. We coordinate with the customer's Epicor admin to grant the migration user sufficient permissions and either temporarily disable blocking validation rules during load or extend them with a migration-context check. Without this step, Epicor silently rejects 5-25 percent of records on first import, particularly on Part and Invoice inserts where part number format or GL account segment rules apply.

Migration approach

Six steps for a successful ERP Mark 7 to Epicor Prophet 21 data migration

  1. Schema discovery and scoping session

    We connect to the live ERP Mark 7 instance with an authenticated session and run a schema-probing pass to enumerate all standard and custom objects, field names, and relationships. We export sample records (5-10 per object) and diff them against the standard ERP Mark 7 object definitions to identify the full custom field inventory. We pair this with a scoping call where the customer describes their Epicor target: which modules they are licensing (Financials, Distribution, Manufacturing, MES), their company and plant structure, and their fiscal calendar. The discovery output is a written migration scope document listing every object to migrate, the estimated record counts, and any schema elements that require custom mapping.

  2. Epicor schema design and BOM/routing reconstruction

    We design the Epicor target schema before any data extraction begins. This includes creating user-defined fields on Part, Customer, Vendor, Job, and GL Account to receive ERP Mark 7 custom properties; defining the COA segment structure and GL Account number format; setting up the Part Revision and PartBillOfMtl revision hierarchy; and confirming the fiscal calendar with period boundaries and close status. If ERP Mark 7 BOM and routing data is accessible, we reconstruct the PartBillOfMtl and PartOpr records in Epicor during this phase. If not accessible, we flag routing reconstruction as a manual step for the customer's Epicor partner.

  3. Data extraction, profiling, and cleansing

    We extract all master data (Customers, Vendors, Items, GL Accounts, Users, Departments, Tax Codes) and transactional data (Open AR, Open AP, Work Orders, Historical Transactions) from ERP Mark 7 via API or database export. We run data profiling to identify duplicates, incomplete records, and format inconsistencies. Common findings include inactive Customers or Vendors still referenced in open AR/AP, Items with no unit-of-measure assignment, and GL Accounts used in transactions that do not exist in the ERP Mark 7 chart of accounts. We produce a cleansing report and run a deduplication pass in coordination with the customer's finance and operations leads before record-level migration begins.

  4. Sandbox migration and reconciliation

    We run a full migration into the Epicor test or sandbox environment using production-like data volume. The customer's operations lead reconciles record counts (Customers in, Vendors in, Parts in, GL Accounts in, open AR in, open AP in), spot-checks 25-50 random records against the ERP Mark 7 source, and verifies that BOM and routing relationships appear correctly in Epicor Part Maintenance and Job Entry. Any mapping corrections happen in the sandbox phase, not in production. The customer signs off on the sandbox migration before production cutover is scheduled.

  5. Production migration in dependency order

    We run production migration in record-dependency order: GL Accounts (Chart of Maps), Departments and Tax Codes, Customers and Vendors, Parts and PartBillOfMtl, open AP (Vendors invoiced), open AR (Customer invoiced), Work Orders and Jobs with JobMtl and JobOper, and historical transactions in fiscal-year batches with closed periods first and current fiscal year last. Each phase emits a row-count reconciliation report. We freeze ERP Mark 7 writes during the cutover window and run a final delta migration of any records modified during the window.

  6. Cutover, validation, and handoff

    We enable Epicor as the system of record after the final delta migration completes and the customer's finance team confirms open AR/AP balances match. We deliver a written inventory of any ERP Mark 7 workflows, production schedules, or custom BPM logic requiring rebuild in Epicor. We support a one-week hypercare window where we resolve reconciliation issues raised by the customer's team. We do not rebuild ERP Mark 7 custom logic as Epicor BPMs or Data Directives; that work is handled by the customer's Epicor implementation partner as a separate engagement.

Platform deep dives

Context on both ends of the pair

ERP Mark 7 logo

ERP Mark 7

Source

Strengths

  • Modular SaaS model with tiered pricing from $13–$43/month per plan, allowing incremental adoption.
  • Customization flexibility on standard objects accommodates industry-specific workflows for manufacturing.
  • All-in-one financial, inventory, and supply chain modules reduce the need for multiple disconnected tools.
  • Cloud-native with API access for integrations and data export.
  • Free trial available for evaluation before commitment.

Weaknesses

  • Very limited public API documentation and no widely-adopted developer ecosystem.
  • Small vendor presence means fewer third-party integrations, training resources, and consultant options.
  • Custom fields and module-level changes create schema variation that complicates migrations.
  • No clear bulk data export tooling documented, making self-service migration difficult.
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 ERP Mark 7 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

    ERP Mark 7: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

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

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

Can't find your answer?

Walk through your ERP Mark 7 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 under 5,000 Customers, 3,000 Vendors, and 10,000 Items with straightforward chart of accounts mapping and no multi-level BOM reconstruction. Migrations with multi-level Bill of Materials, active Work Orders requiring Job and Material resolution, historical transactions spanning multiple fiscal years, or significant per-instance custom fields move to ten to eighteen weeks because of BOM reconstruction, routing mapping, fiscal close sequencing, and Epicor validation rule handling. Epicor implementations themselves (configuration, training, go-live) are separate from the data migration timeline and typically add three to twelve months.

Adjacent paths

Related migrations to explore

Ready when you are

Move from ERP Mark 7.
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