ERP migration
Field-level mapping, validation, and rollback between Oracle E-Business Suite and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
Oracle E-Business Suite
Source
Epicor Prophet 21
Destination
Compatibility
10 of 12
objects map 1:1 between Oracle E-Business Suite and Epicor Prophet 21.
Complexity
BStandard
Timeline
8-12 weeks
Overview
Moving from Oracle E-Business Suite to Epicor ERP is a cross-vendor structural migration. Oracle EBS stores master and transactional data across multiple product schemas—AR splits across RA_CUSTOMERS, RA_ADDRESSES, and HZ_PARTIES; AP invoice headers and lines are separate tables; BOM structures and routings are cross-referenced by structure-type codes—while Epicor Kinetic uses a unified Company, Part, JobMtl, and POLINE model with configure-to-order and MES depth for manufacturing. We extract from the APPS schema using Oracle-certified tools, sequence entity loads in dependency order to respect referential integrity constraints enforced by database triggers, and flatten Oracle's multi-schema party-account hierarchy into Epicor's customer model. We do not migrate Oracle Workflows, custom PL/SQL procedures, Oracle Reports, or Oracle Form personalizations as code; these are inventoried in a written handoff document for the customer's admin team. Epicor Kinetic's subscription pricing model typically reduces annual ERP cost compared to Oracle's perpetual-license-plus-22%-support structure, particularly for organizations that do not require Oracle's full multinational legal-entity and regulatory-compliance depth.
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 Oracle E-Business Suite 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.
Oracle E-Business Suite
GL Ledgers
Epicor Prophet 21
GL Account and Fiscal Year
1:1Oracle GL stores multiple ledgers per legal entity with configurable segment structures in GL_CODE_COMBINATIONS. We extract the chart of accounts, journal batches, and period balances from GL_BALANCES. Each Oracle Ledger maps to an Epicor Fiscal Year and Ledger combination. Epicor's segment structure uses a different accounting dimension model; we collapse Oracle's N-segment chart (commonly 6-10 segments: company, business unit, account, department, product line, etc.) into Epicor's master data dimension fields and preserve the original Oracle CCID as a reference field for audit.
Oracle E-Business Suite
Suppliers (AP Vendors)
Epicor Prophet 21
Vendor
1:1Oracle PO_VENDORS + PO_VENDOR_SITES_ALL store supplier records with address book entries, bank accounts (IBY_EXT_BANK_ACCOUNTS), payment terms, and site assignments. We flatten Oracle's site-based supplier model into Epicor's Vendor with vendor addresses and bank account records as related entities. Oracle payment terms (POZ_TERMS) map to Epicor Terms records. Purchasing assignments at the vendor-site level are preserved as vendor address defaults.
Oracle E-Business Suite
Customers (AR)
Epicor Prophet 21
Customer
1:manyOracle AR customers split across RA_CUSTOMERS, RA_ADDRESSES, and HZ_PARTIES: a single party (person or organization) can have multiple customer accounts and multiple address sites. We flatten this into Epicor's Customer entity by joining HZ_PARTIES.PARTY_ID to RA_CUSTOMERS.CUSTOMER_ID, collapsing all party-level contact and address data into one Customer record per operating unit. Profile classes, credit hold statuses, and Collector assignments from AR_CUSTOMER_PROFILES map to Epicor Customer CreditHold and Terms fields.
Oracle E-Business Suite
AP Invoices
Epicor Prophet 21
AP Invoice
1:1AP_INVOICES_ALL and AP_INVOICE_LINES_ALL store invoice headers and distributions separately. We extract balance-owing amounts, hold statuses, and payment terms from AP_PAYMENT_SCHEDULES. Oracle's invoice-level and line-level tax records from AP_TAX_LINES migrate to Epicor's InvoiceTax records. Invoice distributions (APInvoiceExpB不要再) map to Epicor APInvoiceExpense records tied to GL accounts.
Oracle E-Business Suite
AR Invoices
Epicor Prophet 21
AR Invoice
1:1AR_INVOICES_ALL and AR_RECEIVABLE_LINES_ALL store invoice headers and receivable lines with AR transaction types. We extract balance remaining from AR_RECEIVABLES_TRX and map Oracle's legal-entity org_id to Epicor's Company. Oracle's Remit-To address hierarchy (HZ_PARTIES) migrates as the Epicor customer bill-to and ship-to address records.
Oracle E-Business Suite
Open Purchase Orders
Epicor Prophet 21
POHEADER + POLINE
1:1PO_HEADERS_ALL and PO_LINES_ALL store PO headers and lines with authorization status and type codes. We flag lines in APPROVED status as eligible for target load; DRAFT and REJECTED lines are excluded unless the customer explicitly requests them. Oracle's schedule-based distributions (PO_DISTRIBUTIONS_ALL) map to Epicor POLineTax and PORel records. PO approval workflows do not migrate; we document approval limits and thresholds as a written inventory for the customer's admin to configure in Epicor approval chains.
Oracle E-Business Suite
Inventory Organizations
Epicor Prophet 21
Site + Part
lossyMST_ORGANIZATIONS defines Oracle org structure; MTL_SYSTEM_ITEMS_B defines the item master with organization-specific on-hand quantities. Subinventory assignments and locator hierarchies require careful mapping to Epicor's PartBin and warehouse structure. Oracle's org_id maps to Epicor Plant/Site. We extract on-hand quantities from MTL_ONHAND_QUANTITIES_DETAIL and map each org-specific inventory record to Epicor PartBin records. Oracle's revision control (MTL_ITEM_REVISIONS) maps to Epicor PartRev for revision tracking.
Oracle E-Business Suite
Bills of Material
Epicor Prophet 21
JobMtl + JobOper
1:1BOM_STRUCTURES_B and BOM_ROUTINGS_B store multi-level BOMs and routing sequences. Oracle BOM types (M, A, E, T for manufacturing, phantom, planning, template) must map to Epicor JobMtl and JobOper JobHead records. The explode/implode topology between BOM levels must be preserved in correct topological order during load or the job structure will not nest correctly. We perform a topological sort of the BOM tree before generating Epicor JobMtl records with the correct bill and sequence.
Oracle E-Business Suite
Work Orders
Epicor Prophet 21
JobHead + JobMtl + JobOper
1:1WIP_JOB_SCHEDULE_SCHEDULES stores discrete and process work orders with status codes (pending, released, complete, closed, cancelled). Open and released WIP jobs require material allocations (WIP_MTL_ALLOCATIONS) and routing step sequencing (WIP_OPERATIONS). We extract job start and completion dates, scrap percentages, and alternate routing flags. Closed and cancelled jobs are excluded unless the customer requests historical reporting records. Epicor's JobMtl and JobOper are linked to JobHead; we resolve the JobNum and PartNum references during the transform phase.
Oracle E-Business Suite
Projects and Expenditure Items
Epicor Prophet 21
Project + LaborDtl
1:1PA_PROJECTS_ALL and PA_EXPENDITURES store project headers and costed transaction lines. Resource breakdown structures and billing rates require cross-module mapping to Epicor's project costing engine. Oracle's expenditure type and organization segments map to Epicor ProjectPhase and LaborDtl burden rates. We extract PA_BURDEN_COSTS and PA_REVENUE_COSTS for project-level financial data. Project forecasts and budgets stored in PA_BUDGET_BASE map to Epicor ProjectBudget records.
Oracle E-Business Suite
Employees (HRMS)
Epicor Prophet 21
Employee
1:1HRMS employee records span PER_ALL_ASSIGNMENTS_F and PER_PERSONS_F with assignment grades, supervisors, cost centers, and termination dates. Effective dates on assignments require period-aware extraction to preserve the correct employment history in Epicor Employee records. Oracle HRMS functionality requires Epicor Human Capital Management or a separate HRIS integration; we migrate the employee master and cost center assignments only if Epicor HCM is in scope. If the destination is Epicor ERP without HCM, we migrate employee records as a reference table only.
Oracle E-Business Suite
Attachments (FND)
Epicor Prophet 21
Document Management
1:1FND_ATTACHED_DOCUMENTS and FND_LOBS store binary files associated with entities across modules. We extract the LOB content or file paths and map them to Epicor's Document Management records linked to the corresponding entity (Customer, Vendor, Part, Job). PDF and Office document attachments migrate as-is; legacy Oracle Report output files (RDF-generated PDFs) require format conversion or are flagged as candidates for Epicor Report Builder rebuild.
| Oracle E-Business Suite | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| GL Ledgers | GL Account and Fiscal Year1:1 | Fully supported | |
| Suppliers (AP Vendors) | Vendor1:1 | Fully supported | |
| Customers (AR) | Customer1:many | Fully supported | |
| AP Invoices | AP Invoice1:1 | Fully supported | |
| AR Invoices | AR Invoice1:1 | Fully supported | |
| Open Purchase Orders | POHEADER + POLINE1:1 | Mapping required | |
| Inventory Organizations | Site + Partlossy | Mapping required | |
| Bills of Material | JobMtl + JobOper1:1 | Fully supported | |
| Work Orders | JobHead + JobMtl + JobOper1:1 | Mapping required | |
| Projects and Expenditure Items | Project + LaborDtl1:1 | Mapping required | |
| Employees (HRMS) | Employee1:1 | Fully supported | |
| Attachments (FND) | Document Management1: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.
Oracle E-Business Suite gotchas
EBS database lives behind a three-tier architecture
Multi-schema data integrity requires APPS-read before partial loads
Module activation creates ghost tables and cross-dependencies
CVE-2025-61884 unauthenticated data exposure in Configurator Runtime UI
Per-module licensing inflates target ERP cost
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 module scope definition
We audit the source Oracle EBS environment via the APPS schema and FND_PRODUCT_INSTALLATIONS, identifying which modules are active (Financials, Purchasing, Inventory, WIP, Projects, HRMS) versus licensed-but-unused. We extract record counts for each entity, identify multi-org setups (MULTI_ORG flag, ORG_ID assignments), and flag any XX_ custom tables referenced by the customer's PL/SQL procedures. We pair this with an Epicor Kinetic edition assessment: Epicor Prophet 21 for distribution, Epicor Kinetic for manufacturing, or Epicor Lumber for forest products. The discovery output is a written migration scope and Epicor module recommendation.
Database cloning and APPS-schema extraction
We coordinate with the customer's Oracle DBA to create a full cloned copy of the production database using RMAN or Data Guard active duplication. All extraction runs against the clone, not production. We connect via Oracle SQL*Net or JDBC to the APPS schema and run module-specific extraction queries in dependency order: HZ_PARTIES (Party model), then PO_VENDORS, RA_CUSTOMERS, GL_CODE_COMBINATIONS, MST_ORGANIZATIONS, MTL_SYSTEM_ITEMS_B, then BOM_STRUCTURES_B and BOM_ROUTINGS_B, then transactional tables (AP_INVOICES_ALL, AR_INVOICES_ALL, PO_HEADERS_ALL, WIP_JOB_SCHEDULE_SCHEDULES, PA_EXPENDITURES). We validate row counts against Oracle concurrent request outputs for reconciliation.
Epicor schema provisioning and BOM topology planning
We provision the Epicor Kinetic environment with Companies, Plants/Sites, and Warehouses matching the Oracle org structure. Part and PartBin records are created first so that JobHead and JobMtl references can be resolved during import. We perform the BOM topological sort during this phase and produce a phased BOM insertion plan that respects parent-before-child constraints. GL account mapping from Oracle's N-segment CCID chart to Epicor's dimension segments is finalized with the customer's finance team before any GL balance extraction begins.
Sandbox migration and reconciliation
We run a full migration into Epicor Kinetic in a non-production environment using production-like data volumes. The customer's finance team reconciles GL balances (debit/credit totals by period) against Oracle GL reports; the operations team spot-checks 25-50 BOM structures, 30-50 inventory on-hand records, and 20-30 open PO records against the Oracle source. BOM structure integrity (topological ordering) is validated by exploding the migrated BOM in Epicor and comparing the exploded cost to Oracle's BOM cost rollup report. Any mapping corrections happen here.
Production migration in dependency order
We run production migration in record-dependency order: Sites and Warehouses (from Oracle org structure), GL accounts and fiscal years, Vendor and Customer master, then transactional records (AP/AR invoices, POs, WIP jobs), BOM structures and routings (in topological order), inventory on-hand quantities, project headers and expenditure items. Each phase emits a row-count reconciliation report before the next phase begins. Open POs and WIP jobs are the final transactional phase because they reference vendors, customers, parts, and GL accounts that must already exist.
Cutover, validation, and rebuild handoff
We freeze Oracle EBS writes during cutover, run a final delta migration of any records modified during the cutover window, then enable Epicor ERP as the system of record. We deliver the written inventory of Oracle Workflows, custom PL/SQL procedures, Oracle Reports, and Oracle Form personalizations to the customer's admin team with a recommended Epicor equivalent (Epicor Functions, BAQ scripts, Kinetic Report Builder). We do not rebuild Oracle workflows or reports as part of the migration scope. We support a two-week hypercare window where we resolve any reconciliation issues raised by the customer's team during parallel operation.
Platform deep dives
Oracle E-Business Suite
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 Oracle E-Business Suite 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
Oracle E-Business Suite: No documented public API rate limits for core modules; API access requires Oracle Integration Cloud or custom middleware.
Data volume sensitivity
Oracle E-Business Suite 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 Oracle E-Business Suite to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your Oracle E-Business Suite 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 Oracle E-Business Suite
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.