ERP migration

Migrate from Oracle JD Edwards EnterpriseOne to Epicor Prophet 21

Field-level mapping, validation, and rollback between Oracle JD Edwards EnterpriseOne and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.

Oracle JD Edwards EnterpriseOne logo

Oracle JD Edwards EnterpriseOne

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

80%

12 of 15

objects map 1:1 between Oracle JD Edwards EnterpriseOne and Epicor Prophet 21.

Complexity

BStandard

Timeline

8-12 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from Oracle JD Edwards EnterpriseOne to Epicor ERP is a cross-ERP data migration that requires translating a flat-file-oriented data model built around JDE's F0005 data dictionary into Epicor's relational object schema. JDE stores sales order pricing, taxes, and branch assignments denormalized across F4211 and F42119, while Epicor uses a normalized sales order header-detail structure with separate pricing and tax tables. We resolve that structural difference during transformation, map multi-currency and multi-legislative data to Epicor's fiscal calendar and tax configuration, and preserve historical timestamps from F0901, F0411, F0311, and F4101 before cutover. Workflows, orchestrator schedules, and UBE custom reports do not migrate; we deliver a written inventory of each for the customer's admin to rebuild in Epicor Kinetic Studio.

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

Oracle JD Edwards EnterpriseOne logo

Oracle JD Edwards EnterpriseOne

What's pushing teams away

  • Named User Plus licensing costs scale per-user per-module, making the total cost of ownership unpredictable as headcount grows and driving organizations toward cloud ERP with flatter pricing models.
  • Difficulty customizing workflows and error handling creates friction for teams that need rapid process changes, particularly in fast-moving distribution and order-management environments.
  • MRP limitations where overdue or status-999 sales orders do not propagate demand signals down the BOM hierarchy force organizations to implement manual workarounds or supplemental planning tools.
  • Organizations acquired by companies running different ERP systems face pressure to consolidate onto a single platform, triggering data migration projects away from JDE.
  • Annual support fees at approximately 22% of the perpetual license cost represent a recurring expense that prompts periodic cost-versus-benefit reviews, especially for smaller JDE deployments.

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 Oracle JD Edwards EnterpriseOne objects map to Epicor Prophet 21

Each row shows how a Oracle JD Edwards EnterpriseOne 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 JD Edwards EnterpriseOne

Address Book (F0101, F0111, F0116)

maps to

Epicor Prophet 21

Customer and Supplier records

1:1
Fully supported

JDE Address Book is the master entity for customers, suppliers, employees, and prospects. We export F0101 (master), F0111 (contact info), and F0116 (phone numbers) and map to Epicor Customer or Supplier records by party type. Address book category codes (AN8, AB4, AB5) map to Epicor Custom Fields or Character fields in the party master. Multi-legislative addresses resolve to Epicor's country-specific address formats. The search name from F0101.SRCH becomes Epicor's Name field.

Oracle JD Edwards EnterpriseOne

General Ledger (F0901)

maps to

Epicor Prophet 21

GL Account and GL Journal records

1:1
Fully supported

JDE Account Master (F0901) with chart of accounts stored in business units (MCU), object (OBJ), and subsidiary (SUB) segments maps to Epicor's GL Account structure. We flatten the JDE 3-segment account code (Business Unit.Object.Subsidiary) into Epicor's account string format. Account balances from F0902 migrate as opening balances in Epicor GL. Multi-currency ledgers in JDE map to Epicor separate company currencies or functional currency configurations.

Oracle JD Edwards EnterpriseOne

Accounts Payable (F0411, F0414)

maps to

Epicor Prophet 21

AP Invoice and AP Payment records

1:1
Fully supported

JDE Accounts Payable stores invoices in F0411 and payments in F0414. We extract open AP transactions with outstanding balances and payment terms, mapping JDE payment terms codes to Epicor Terms records. Vendor hold status and 1099 flag from F0411 map to Epicor Supplier flags. Retainage records in F0414 migrate as separate Payable records with retainage hold status.

Oracle JD Edwards EnterpriseOne

Accounts Receivable (F0311, F03B11)

maps to

Epicor Prophet 21

AR Invoice and AR Receipt records

1:1
Fully supported

JDE Accounts Receivable stores invoices in F0311 and receipts in F03B11. We extract open AR transactions with outstanding balances, aging buckets, and dunning levels. JDE's document type (RD, RI, RM) maps to Epicor Invoice, Debit Memo, and Credit Memo types. Multi-currency AR with exchange rate variances migrates with the original rate preserved in Epicor's currency history table.

Oracle JD Edwards EnterpriseOne

Item Master (F4101)

maps to

Epicor Prophet 21

Part and Part Revision records

1:1
Fully supported

JDE Item Master in F4101 maps to Epicor Part master with stocking type, unit of measure, and category code assignments preserved. The stocking type (B/M/O/S) maps to Epicor's Type Code (Stock, Make, Buy, Special). JDE unit of measure conversions from F41003 migrate to Epicor's UOM class and conversion rules. Category codes from F4101 map to Epicor Part Class codes and custom fields.

Oracle JD Edwards EnterpriseOne

Branch/Plant Inventory (F4102)

maps to

Epicor Prophet 21

PartBin (warehouse quantity) records

1:1
Fully supported

JDE F4102 stores per-branch-plant inventory quantities, lot information, and location data. We map each F4102 branch-plant record to Epicor PartBin entries by site and warehouse. Lot number records from F4108 migrate to Epicor Lot records linked to PartBin. Cost layer information from F41026 (Item Cost file) migrates as Epicor Part transactions for FIFO or average cost valuation.

Oracle JD Edwards EnterpriseOne

Sales Order Header (F4211)

maps to

Epicor Prophet 21

OrderHed (sales order header) records

1:1
Fully supported

JDE F4211 stores sales order headers with order type, status, customer address number, and branch plant embedded in the header. We extract order headers and map JDE order status codes to Epicor OrderHed Status (open, partially shipped, closed). Header-level pricing from F4211 is preserved; line-level pricing is extracted from F42119. JDE multi-currency pricing migrates with the original exchange rate.

Oracle JD Edwards EnterpriseOne

Sales Order Line (F42119)

maps to

Epicor Prophet 21

OrderDtl (sales order detail) records

1:1
Fully supported

JDE F42119 stores sales order lines with pricing, tax, and branch plant assignments. We map to Epicor OrderDtl with resolved PartNum, SalesUM,IUM conversions, and quantity breaks. JDE line status and promise date migrate to Epicor OrderDtl Status and ReqDate. Line type codes map to Epicor's line types (standard, make-to-order, job).

Oracle JD Edwards EnterpriseOne

Purchase Order (F4311)

maps to

Epicor Prophet 21

POHeader and PODetail records

lossy
Fully supported

JDE F4311 uses a complex row structure where receipt and invoicing lines are intermingled with purchase order lines. We split F4311 into Epicor POHeader and PODetail records, separating open purchase order lines from completed receipt lines. Schedule dates from F4311.PRDJ migrate as Epicor line delivery dates. JDE approval workflow status maps to Epicor POHeader approval status.

Oracle JD Edwards EnterpriseOne

Work Order (F4801)

maps to

Epicor Prophet 21

JobMtl, JobOper, and JobHead records

lossy
Fully supported

JDE Work Orders carry routing and operation step data across multiple linked tables: F4801 (header), F3112 (operations), F3003 (BOM). We extract the complete work order assembly structure and reconstruct it as Epicor Job records with JobMtl (materials) and JobOper (operations) entries. JDE status codes map to Epicor Job status (planned, released, complete, closed).

Oracle JD Edwards EnterpriseOne

Advanced Pricing (F4072)

maps to

Epicor Prophet 21

PriceLbr and PriceCnd records

lossy
Fully supported

JDE Advanced Pricing schedules stored in F4072 with effective dates, break quantities, and adjustment types map to Epicor Price List records and Price Break conditions. We extract the full pricing hierarchy including volume discounts, customer-specific pricing, and formula-based adjustments. JDE price adjustment rules become Epicor Price Break conditions with matching Qualifiers (customer, quantity, date range).

Oracle JD Edwards EnterpriseOne

Bills of Material (F3002, F3003)

maps to

Epicor Prophet 21

PartMtl (BOM) and PartOpr (routing) records

1:1
Fully supported

JDE BOM data in F3002 (BOM header) and F3003 (BOM detail) with revision and effectivity dates migrates to Epicor PartMtl records. The bill structure type (M for manufactured, K for kit) maps to Epicor BOM Type. Phantom bills map to Epicor Material Type 4. BOM rollup costs from JDE migrate as Epicor BomMtlBurdenCost and BomMtlMtlCost fields.

Oracle JD Edwards EnterpriseOne

Media Objects (F00165)

maps to

Epicor Prophet 21

Document Management records

1:1
Mapping required

JDE media objects (attachments, images, embedded documents) stored in F00165 require running the R98MODAT utility to load filesystem-based media objects into the database before export. We invoke R98MODAT as a pre-export step on Tools Release 9.2.1 and later systems, then export F00165 records as Epicor Document Management records linked to the parent entity (Part, Order, Job, Quote).

Oracle JD Edwards EnterpriseOne

User Defined Objects (UDOs)

maps to

Epicor Prophet 21

Custom Objects (documented for rebuild)

1:1
Mapping required

JDE custom reports (UBEs), custom tables, and other UDOs tracked in the Object Management Workbench do not migrate to Epicor ERP as functional equivalents. We document every UDO's name, project reservation, and data structure in a written inventory. Custom UBEs require a rewrite in Epicor Kinetic Studio Report Builder or a third-party reporting tool (Power BI, SSRS). Custom tables require schema re-creation in Epicor with a migration of their data through standard Epicor data import tools.

Oracle JD Edwards EnterpriseOne

Fixed Assets (F1201, F1202)

maps to

Epicor Prophet 21

Asset records

1:1
Fully supported

JDE Fixed Assets stored in F1201 (master) and F1202 (transactions) migrate to Epicor Asset records with original cost, accumulated depreciation, fiscal year depreciation schedules, and asset status. JDE asset category codes map to Epicor Asset Group. Depreciation methods (straight-line, declining balance, units of production) migrate to Epicor depreciation rules. In-service date and placed-in-service date from F1201 map to Epicor acquisition date fields.

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.

Oracle JD Edwards EnterpriseOne logo

Oracle JD Edwards EnterpriseOne gotchas

High

JDE-to-Cloud version parity is mandatory

High

Media objects must be pre-loaded before export

Medium

User Defined Objects lose their project reservation

Medium

AIS REST API requires token-based authentication on v2 endpoints

Low

Workflow thresholds silently suppress notifications

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

  • JDE Tools Release version must be validated before export

    The JDE export process requires Tools Release 9.2.x with Applications 9.1 or later for compatibility with the Oracle Cloud Migration Utility export format. If the source environment runs an earlier Tools Release, the export script may fail silently or produce malformed output. We check the source system's P96470 (Software Updates) output during scoping and flag any version mismatches before migration planning begins. Epicor ERP does not have a direct import path for JDE's native export format, so we use intermediate CSV or JSON staging with schema mapping rather than a vendor-provided migration tool.

  • Media objects silently excluded without R98MODAT pre-load

    JDE stores some media objects as filesystem files rather than in the database. Oracle's recommended approach is to run the R98MODAT utility to load all media objects into the F00165 table before running any migration export. Failure to invoke R98MODAT means attachments, images, and embedded documents are silently excluded from the dump. We invoke R98MODAT as a mandatory pre-export step on Tools Release 9.2.1 and later systems before any media object extraction begins.

  • Multi-site inventory requires branch-plant mapping to Epicor Sites

    JDE uses Business Units (MCU) as the branch-plant entity across inventory, purchasing, and manufacturing. Epicor ERP uses Sites as the top-level organizational unit, with Warehouses nested within Sites. We must establish a mapping from every unique F4102 MCU to an Epicor Site and Warehouse before inventory records can be loaded. Sites without a defined mapping are flagged during discovery, and the customer's Epicor admin creates the site structure before migration resumes. Inventory cost layers per branch-plant must be reconciled against Epicor's company costing setup.

  • Purchase order receipt and invoicing lines are co-mingled in F4311

    JDE F4311 stores purchase order lines, receipt lines, and invoicing lines in a single table with different document types (OB, OC, OT, etc.). Extracting the correct record subset and reconstructing them as Epicor POHeader/PODetail (for open orders) and AP Invoice records (for received-not-invoiced) requires a complex SQL filter that we document in the mapping specification. We split F4311 into separate Epicor objects: open PO lines become PODetail; received-not-invoiced lines become AP Invoice records linked to the original PO.

  • Workflow, Orchestrator, and UBE schedules do not migrate

    JDE Workflow email notifications, Orchestrator schedules, and custom UBE (Universal Batch Engine) report schedules are application-level configurations that do not export from JDE's table structure and have no direct Epicor equivalent. Epicor Kinetic Studio replaces Orchestrator functionality, and Epicor has a separate report scheduler. We document every active workflow threshold setting, Orchestrator schedule, and UBE batch schedule in a written inventory with a recommended Epicor equivalent for the customer's admin to rebuild post-migration.

Migration approach

Six steps for a successful Oracle JD Edwards EnterpriseOne to Epicor Prophet 21 data migration

  1. Discovery and environment assessment

    We audit the source JDE environment: Tools Release and Applications version from P96470, database backend (Oracle or SQL Server), active modules (Financials, Supply Chain, Manufacturing), F0005 data dictionary extensions, custom UDO count from Object Management Workbench, and media object storage location. We also assess the target Epicor ERP tenant: company structure, site/warehouse setup, chart of accounts format, and existing Part/Customer/Supplier records. The discovery output is a written migration scope with a table-level mapping specification, a JDE-to-Epicor object dependency graph, and a timeline estimate.

  2. Pre-export preparation on JDE source system

    We run the R98MODAT utility to load all filesystem-based media objects into the F00165 database table. We check AIS REST API authentication (token-based for Tools Release 9.2.26.0 and later) and validate connectivity. We document all UDO project reservations before migration and create a rollback checklist. For multi-legislative JDE deployments, we extract fiscal calendars per company code for Epicor fiscal period mapping. We confirm that all traditional objects are checked in for the path code to be exported.

  3. Staging export and transformation

    We export JDE data in dependency order: master data first (Address Book F0101, Item Master F4101), then financial balances (F0901, F0411, F0311, F1201), then transactional data (F4211/F42119 sales orders, F4311 purchase orders, F4801 work orders), then BOM and routing (F3002, F3003, F3112), then pricing (F4072), then media objects (F00165). Each export is written to a staged CSV or JSON file with the original F-prefix column names preserved. We run transformation scripts that flatten the JDE 3-segment account code (MCU.OBJ.SUB) into Epicor's account string format and split co-mingled F4311 rows into separate PO and AP records.

  4. Epicor schema pre-creation and configuration

    Before any data loads, we create the Epicor destination schema: Part records for every JDE item (F4101), Supplier records for every JDE supplier Address Book entry, Customer records for every JDE customer, and GL Account records matching the chart of accounts structure. We configure Epicor sites mapped to JDE MCU values, price lists mapped to JDE pricing schedules (F4072), and order types mapped to JDE document types. The Epicor admin validates the site/warehouse structure before we proceed to record load.

  5. Production load in dependency order with reconciliation

    We load Epicor records in strict dependency order: Part (from F4101), Supplier (from F0101 by supplier), Customer (from F0101 by customer), GL Account (from F0901), then transactional records (AP/AR from F0411/F0311, Orders from F4211/F42119, POs from F4311, Jobs from F4801), then BOM/routing (F3002/F3003), then pricing (F4072), then media objects (F00165). Each phase emits a row-count reconciliation report comparing the JDE export count to the Epicor load count. Discrepancies are investigated before the next phase begins. We use Epicor's REST API with batch chunking and exponential backoff on rate limit responses.

  6. Cutover, delta sync, and post-migration handoff

    We freeze JDE writes during cutover and run a final delta migration of any records modified during the migration window. We validate Epicor financial trial balance against the JDE GL closing balances. We deliver the UDO inventory, workflow threshold documentation, and Orchestrator schedule map to the customer's Epicor admin. We support a one-week hypercare window for reconciliation issues. We do not rebuild JDE workflows, orchestrator schedules, or UBE custom reports inside the migration scope; those are separate engagements for the customer's admin or an Epicor implementation partner.

Platform deep dives

Context on both ends of the pair

Oracle JD Edwards EnterpriseOne logo

Oracle JD Edwards EnterpriseOne

Source

Strengths

  • Cross-platform deployment on Oracle Database, SQL Server, Windows, Unix, and Linux protects existing infrastructure investments.
  • Continuous delivery with six-month feature pack releases keeps the system modernised without requiring disruptive major-version upgrade projects.
  • Over 6,000 global customers across manufacturing, distribution, food and beverage, and real estate create a deep third-party consultant and integration ecosystem.
  • Advanced Pricing supports complex multi-level, multi-currency, and volume-sensitive pricing rules with formula-based and commodity-table pricing.
  • Modular per-module Named User Plus licensing lets organizations license only the functional areas they actively use.

Weaknesses

  • Named User Plus licensing scales per-user per-module, making total cost of ownership difficult to predict as organisations grow and adding users across multiple modules multiplies licence fees.
  • Customisation requires navigating the Object Management Workbench and the development tools layer, which has a steep learning curve compared to modern SaaS configuration approaches.
  • MRP cascading limitations mean overdue or held sales orders (status 999) do not automatically propagate demand signals down the bill of materials hierarchy.
  • Annual support fees at approximately 22% of perpetual licence cost represent a recurring expense that becomes a target for cost-reduction reviews during economic downturns.
  • Integration with modern cloud-native applications requires middleware or connector tooling, as JDE's native AIS REST API is functional but not as developer-friendly as contemporary API platforms.
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 Oracle JD Edwards EnterpriseOne 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

    Oracle JD Edwards EnterpriseOne: Not publicly documented by Oracle for the AIS Server REST API.

  • Data volume sensitivity

    B

    Oracle JD Edwards EnterpriseOne doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Oracle JD Edwards EnterpriseOne 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 Oracle JD Edwards EnterpriseOne to Epicor Prophet 21 data migrations

Answers to the questions buyers ask most during Oracle JD Edwards EnterpriseOne to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your Oracle JD Edwards EnterpriseOne 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 eight and twelve weeks for environments under 50,000 Address Book records, 200,000 GL lines, and no active work order or Advanced Pricing history. Migrations with large transactional volumes (over 500,000 open AP/AR lines), active manufacturing work orders with routing data, multi-site inventory with per-branch-plant cost layers, and complex Advanced Pricing schedules extend to fourteen to twenty-four weeks because of parent-record dependency resolution and BOM cost rollup validation.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Oracle JD Edwards EnterpriseOne.
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