ERP migration
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
Source
Epicor Prophet 21
Destination
Compatibility
11 of 14
objects map 1:1 between ERP Mark 7 and Epicor Prophet 21.
Complexity
BStandard
Timeline
5-8 weeks
Overview
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.
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 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
Epicor Prophet 21
Customer
1:1ERP 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
Epicor Prophet 21
Vendor
1:1ERP 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
Epicor Prophet 21
Part
1:1ERP 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
Epicor Prophet 21
GL Account
1:1ERP 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
Epicor Prophet 21
Invoice + AR Adjustment
1:1Open 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
Epicor Prophet 21
Invoice + AP Adjustment
1:1Open 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
Epicor Prophet 21
Job
1:1ERP 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)
Epicor Prophet 21
PartBillOfMtl
lossyERP 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)
Epicor Prophet 21
PartOpr
lossyERP 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
Epicor Prophet 21
GLJrnLine + PartTran
1:1Historical 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
Epicor Prophet 21
Document
1:1ERP 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
Epicor Prophet 21
User-Defined Fields (UD)
lossyERP 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
Epicor Prophet 21
User
1:1ERP 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
Epicor Prophet 21
Department
1:1ERP 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.
| ERP Mark 7 | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Customer | Customer1:1 | Fully supported | |
| Vendor | Vendor1:1 | Fully supported | |
| Item | Part1:1 | Fully supported | |
| Chart of Accounts | GL Account1:1 | Mapping required | |
| Open AR | Invoice + AR Adjustment1:1 | Fully supported | |
| Open AP | Invoice + AP Adjustment1:1 | Fully supported | |
| Work Order | Job1:1 | Fully supported | |
| Item (BOM) | PartBillOfMtllossy | Fully supported | |
| Item (Routing) | PartOprlossy | Fully supported | |
| Historical Transactions | GLJrnLine + PartTran1:1 | Mapping required | |
| Document | Document1:1 | Fully supported | |
| Custom Properties | User-Defined Fields (UD)lossy | Mapping required | |
| User | User1:1 | Fully supported | |
| Department | Department1:1 | 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.
ERP Mark 7 gotchas
No publicly documented API endpoint reference
Custom fields are per-instance with no discovery mechanism
Historical transactions may span fiscal years with closes
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
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.
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.
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.
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.
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.
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
ERP Mark 7
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 ERP Mark 7 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
ERP Mark 7: Not publicly documented.
Data volume sensitivity
ERP Mark 7 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 ERP Mark 7 to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
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 consultationAdjacent paths
Other ways to leave ERP Mark 7
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.