ERP migration
Field-level mapping, validation, and rollback between Reflex ERP and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
Reflex ERP
Source
Epicor Prophet 21
Destination
Compatibility
7 of 12
objects map 1:1 between Reflex ERP and Epicor Prophet 21.
Complexity
BStandard
Timeline
8-12 weeks
Overview
Reflex ERP and Epicor ERP are architecturally different platforms with different core strengths. Reflex organizes data around a unified database with 50 cross-module concepts; Epicor Kinetic organizes data around manufacturing-centric objects (Part, Job, Quote, Sales Order) with deep MES and shop-floor scheduling. We extract data via direct database queries or the CCC login portal when API access is unavailable, map relational records to Epicor's schema, and validate post-migration balances against Reflex's real-time reporting outputs. BOM structures require transformation because Reflex encodes them as nested item relationships while Epicor encodes them as Part and PartMtl records. Work orders require sequencing decisions because Reflex's cost-tracking model differs from Epicor's job cost and WIP structure. Open AP and Open AR migrate at cut-off with aging buckets preserved, but Reflex's credit memos and prepayments require explicit disposition decisions before import. Permission sets, document links, and custom Reflex fields do not migrate automatically and are inventoried for manual rebuild in Epicor Kinetic.
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 Reflex ERP 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.
Reflex ERP
Chart of Accounts
Epicor Prophet 21
GL Account (GLAccount)
1:1Reflex Chart of Accounts maps to Epicor GLAccount with account code, description, and account type preserved. We extract all active and inactive accounts, map Reflex account classifications (Asset, Liability, Equity, Revenue, Expense) to Epicor Natural Account types, and set the account segment values based on Epicor's GL Account structure configuration. Inactive flags transfer as Inactive records that can be reactivated post-migration. This is the first object migrated because all financial transactions (AP, AR, Work Orders, Projects) reference GL accounts.
Reflex ERP
Customers
Epicor Prophet 21
Customer
1:1Reflex Customer master records map to Epicor Customer with billing address, shipping address, payment terms, credit limits, and contact details preserved. We extract the full customer record including all ship-to locations and map Reflex payment terms to Epicor Terms records. Outstanding AR records are linked by CustomerID at migration time. Any Reflex-specific credit-hold flags map to Epicor Customer using a custom Customer UD field since the standard Epicor fields do not capture all Reflex status conditions.
Reflex ERP
Vendors
Epicor Prophet 21
Vendor
1:1Reflex Vendor master records mirror Customer structure with address, payment terms, and 1099 settings. We extract all vendor records in full, map vendor IDs to Epicor's VendorNum after deduplication, and preserve the 1099 flag in the Vendor's 1099Code field. Open AP aging and PO history link via VendorNum at migration time. Any Reflex vendor-specific approval workflow flags are inventoried for rebuild as Epicor Approval workflows post-migration.
Reflex ERP
Items
Epicor Prophet 21
Part + PartMtl + PartRev
1:manyReflex Items with BOM structures require a 1:N split into Epicor's Part master, PartMtl (BOM lines), and PartRev (revision/routing) records. We extract all Item records including part numbers, descriptions, costing methods (FIFO/average), and pricing tiers, then explode Reflex BOM relationships into PartMtl rows with operation sequence, quantity-per, and scrap-percent. PartRev records are created for each active revision with the routing from Reflex labor routing. Costing method transfers via the CostID on the Part record. Stock and non-stock flags map to the Part's TypeCode (Stock, Non-Stock, Service, Mischarge).
Reflex ERP
Projects
Epicor Prophet 21
Project + WBS + Phase + Cost Code
1:manyReflex Projects as cost-tracking entities with budget lines and actuals map to Epicor Project with a WBS (Work Breakdown Structure) and Phases. We extract project headers, budget line amounts, and actual costs from Reflex's project cost tracking, then create Epicor Project records with Phase entries for each cost category. Budget-versus-actual comparisons are preserved in ProjectPhase rows. Change orders from Reflex become ProjectPhase or ProjectTask records. Note that Reflex-specific billing milestones and revenue recognition schedules may require manual configuration in Epicor Project Billing if the customer uses percentage-of-completion recognition.
Reflex ERP
Open AP
Epicor Prophet 21
AP Invoice + AP Payment
1:1Open Accounts Payable records from Reflex (linked to Vendor IDs with invoice numbers, amounts, due dates, and payment terms) map to Epicor AP Invoice and AP Payment records. We extract open AP at the agreed cut-off date, create AP Invoice records with the invoice date, due date, vendor reference, and amount, then link any pre-existing AP Payments. Credit memos and prepayments require explicit disposition: we recommend either applying credit memos to open invoices or creating a vendor credit record, and prepayments are recorded as AP Prepayments linked to the Vendor. Reflex's open AP aging buckets are validated against Epicor's AP aging report post-migration.
Reflex ERP
Open AR
Epicor Prophet 21
AR Invoice + AR Payment
1:1Open Accounts Receivable records from Reflex (linked to Customer IDs with invoice, amount, due date, and aging buckets) map to Epicor AR Invoice and AR Payment records. We extract open AR at cut-off, create AR Invoice records with the invoice date, due date, customer reference, and amount, then link any pre-existing AR Payments. Reflex credit memos, deposits, and prepayments are flagged for disposition: credit memos apply to open invoices, deposits become unapplied customer payments, and prepayments are recorded as AR Prepayments. Customer aging buckets in Epicor AR aging are validated against Reflex's AR aging report to confirm balance integrity.
Reflex ERP
Fixed Assets
Epicor Prophet 21
Asset
1:1Reflex Fixed Asset records (acquisition date, cost, depreciation method, accumulated depreciation, useful life) map to Epicor Asset with the depreciation convention and schedule preserved. We extract the full asset register including fully depreciated assets, map Reflex depreciation methods to Epicor depreciation methods (straight-line, double-declining, sum-of-years), and preserve the accumulated depreciation balance. Assets linked to specific GL accounts in Reflex are re-linked to the corresponding Epicor GL Account during import. Asset maintenance schedules are inventoried for rebuild as Epicor Equipment records if the customer uses Epicor MES.
Reflex ERP
Work Orders
Epicor Prophet 21
Job + JobMtl + JobOper
1:1Reflex Work Orders (linking Items, BOMs, and labor routing) map to Epicor Job records with JobMtl (material requirements) and JobOper (operation steps). We extract open and closed work orders with labor hours and material consumption, preserving the link back to the Reflex Item and BOM. For open work orders, we create Epicor Job records with the job date, part number, quantity, and start/due dates. For closed work orders, we migrate the summary (total labor hours, total material cost, total operation time) as a historical record without creating a live Job. Note that Reflex closed work orders impact COGS and inventory simultaneously; Epicor's job close process follows a separate posting sequence.
Reflex ERP
Documents
Epicor Prophet 21
Document Management (ERP Document Attachments)
lossyReflex Document Manager attachments linked to transactions and master records are flagged during extraction with their entity type, record ID, and file path reference. We do not migrate binary document files as part of standard scope, but we deliver a written index mapping each Reflex document URL to the destination entity (Customer, Vendor, Part, Project, Job, AP Invoice, AR Invoice) and the recommended upload method in Epicor Kinetic's Document Management. The customer's admin uploads the actual files post-migration. Reflex custom tables and user-defined fields are similarly flagged with their table name, field names, and record counts for manual rebuild as Epicor UD tables and UD fields.
Reflex ERP
Users
Epicor Prophet 21
User + Group
lossyReflex User records with role assignments are extracted for name, email, role profile, and active/inactive status. We map users to Epicor Kinetic User accounts by email. Reflex permission sets are Reflex-specific and do not map to Epicor's security model; instead, we deliver a written permissions matrix mapping each Reflex role to the equivalent Epicor Kinetic security group and screen-level access rights. The customer's Epicor admin rebuilds the security groups in Kinetic based on this matrix. Inactive Reflex users are provisioned as inactive Epicor users to preserve historical Owner references on records.
Reflex ERP
Tax Codes
Epicor Prophet 21
Tax Region + Tax Code + Tax Category
lossyReflex Tax Codes defining jurisdiction and rate for sales and purchase transactions map to Epicor Tax Region and Tax Code records. We extract all active tax codes with their rates and jurisdictions, then configure Epicor Tax Regions to match. Historical tax adjustments and nexus-specific codes that apply only to certain states or provinces require manual review during Epicor configuration because Epicor's tax engine uses a different jurisdiction assignment model than Reflex.
| Reflex ERP | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Chart of Accounts | GL Account (GLAccount)1:1 | Fully supported | |
| Customers | Customer1:1 | Fully supported | |
| Vendors | Vendor1:1 | Fully supported | |
| Items | Part + PartMtl + PartRev1:many | Mapping required | |
| Projects | Project + WBS + Phase + Cost Code1:many | Mapping required | |
| Open AP | AP Invoice + AP Payment1:1 | Mapping required | |
| Open AR | AR Invoice + AR Payment1:1 | Mapping required | |
| Fixed Assets | Asset1:1 | Mapping required | |
| Work Orders | Job + JobMtl + JobOper1:1 | Mapping required | |
| Documents | Document Management (ERP Document Attachments)lossy | Mapping required | |
| Users | User + Grouplossy | Fully supported | |
| Tax Codes | Tax Region + Tax Code + Tax Categorylossy | Mapping required |
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.
Reflex ERP gotchas
Intercompany banking does not work seamlessly
Minimum 5 Full Client Access Licenses creates a floor on user count migration
Module-spanning data relationships require careful sequencing
Direct database access requires customer-side coordination
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 deployment model confirmation
We audit the source Reflex ERP environment across module usage (Active modules from the 50 available), data volume (account count, customer count, item count with BOM complexity, project count, open AP/AR count, work order backlog, and fixed asset register), and any Reflex custom tables or user-defined fields. We confirm the Epicor deployment model (on-premise, private cloud on Azure/AKS, or SaaS) and the target Epicor Kinetic version. The discovery output is a written migration scope document covering record counts per object, BOM complexity classification, project accounting complexity, and a deployment-model-specific extraction plan.
Extraction strategy and Reflex data access
We determine the extraction method based on the destination Epicor deployment: for Reflex on-premise, we use direct SQL queries against the unified Reflex database to extract relational records in dependency order; for Reflex cloud or hosted, we use the CCC login portal export functionality. We extract in record-dependency order: Chart of Accounts (all), then Customers and Vendors in parallel, then Items (with BOM explosion), then Projects (with budget and actuals), then Open AP and Open AR at cut-off, then Fixed Assets, then Work Orders. Each extraction produces a row-count report and a data-quality sample for review.
Epicor schema configuration and BOM transformation design
We configure the Epicor destination schema in a Sandbox environment before any data import. This includes provisioning GL Account structure, Customer and Vendor type codes, Part records with PartMtl BOM lines from the Reflex BOM explosion, Project WBS and Phase setup, Tax Region and Tax Code configuration, and UD fields for any Reflex-specific flags. The BOM transformation logic (Reflex nested Item relationships to Epicor PartMtl rows) is designed and tested against a sample BOM set before full import. Epicor deployment model is confirmed (cloud SaaS vs on-premise) because it affects whether direct DB access or REST API is used for import.
Sandbox migration and reconciliation
We run a full migration into the Epicor Sandbox using production-like data volume from Reflex. The customer's operations and finance leads reconcile record counts (Accounts, Customers, Vendors, Parts with BOMs, Projects, AP/AR invoices, Assets, Jobs) and spot-check 25-50 records per object against the Reflex source. We validate GL trial balance between Reflex and Epicor, AP aging against the cut-off AP register, and AR aging against the cut-off AR register. Any mapping corrections and BOM transformation errors are fixed before production migration begins. This sandbox validation typically takes one to two weeks.
User reconciliation and permissions matrix handoff
We extract every distinct Reflex User with their role assignments and map them to Epicor Kinetic User accounts by email. Users without matching Epicor accounts go to a reconciliation queue for the customer's admin to provision. We deliver the written permissions matrix mapping each Reflex role to the equivalent Epicor Kinetic security group and screen-level access rights. Epicor Kinetic Cloud and SaaS deployments use the Epicor Identity service for user provisioning; on-premise deployments use the local User Administration. This step runs in parallel with the final sandbox validation.
Production migration in dependency order with cutover
We run production migration in record-dependency order: GL Accounts first (all other objects reference them), then Customers and Vendors in parallel, then Parts with BOM explosion, then Projects with WBS and Phases, then Open AP invoices and Open AR invoices with disposition decisions for credit memos and prepayments, then Fixed Assets, then Work Orders. Each phase emits a row-count reconciliation report before the next phase begins. We freeze Reflex writes during cutover, run a final delta migration of any records modified during the window, then enable Epicor as the system of record. We deliver the document link inventory, custom field inventory, and permissions matrix as the handoff package for the customer's admin team to complete post-migration.
Platform deep dives
Reflex ERP
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 Reflex ERP 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
Reflex ERP: Not publicly documented.
Data volume sensitivity
Reflex ERP 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 Reflex ERP to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your Reflex ERP 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 Reflex ERP
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.