ERP migration

Migrate from Oracle JD Edwards EnterpriseOne to Dolibarr ERP

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

Oracle JD Edwards EnterpriseOne logo

Oracle JD Edwards EnterpriseOne

Source

Dolibarr ERP

Destination

Dolibarr ERP logo

Compatibility

62%

8 of 13

objects map 1:1 between Oracle JD Edwards EnterpriseOne and Dolibarr ERP.

Complexity

BStandard

Timeline

5-8 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Migrating from Oracle JD Edwards EnterpriseOne to Dolibarr is a cross-architecture move from a modular enterprise ERP with an AS400/DB2 legacy table layer to a lightweight open-source ERP/CRM on PHP and MySQL. JDE stores data across dozens of tightly coupled tables (F0101, F0901, F4101, F4211, F4311) with packed-decimal and date-format conventions that Dolibarr does not natively consume. We extract records via JDE's AIS REST API and direct database queries, transform them to Dolibarr's llx_thirdparty, llx_product, llx_commande, and llx_accounting_record structures, and import through Dolibarr's REST API with batch chunking. JDE's Advanced Pricing schedules (F4072), custom UBEs, and User Defined Objects have no direct Dolibarr equivalent; we deliver a written inventory of these for the customer's admin to rebuild. Media objects stored in F00165 require the R98MODAT pre-export utility before they are eligible for extraction. Dolibarr's workflow module is substantially less capable than JDE Workflow; we flag every approval and escalation chain requiring manual rebuild in Dolibarr's built-in workflows or third-party addon ecosystem.

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

Dolibarr ERP logo

Dolibarr ERP

What's pulling them in

  • Free open-source core with no per-user license fee makes it the lowest-cost entry point for small teams needing ERP and CRM in one package.
  • Self-hosted deployment gives full data ownership and eliminates vendor lock-in, especially attractive to businesses with compliance requirements.
  • Modular architecture means teams enable only the features they use, keeping the interface uncluttered and reducing learning curve.
  • Fast installation with no technical knowledge required — one reviewer set up multiple businesses in minutes using their own hosting.
  • Active community forum and marketplace of third-party add-ons provide support and extension options without mandatory subscription costs.

Object mapping

How Oracle JD Edwards EnterpriseOne objects map to Dolibarr ERP

Each row shows how a Oracle JD Edwards EnterpriseOne object lands in Dolibarr ERP, 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

Dolibarr ERP

Third Party (llx_societe) and Contact (llx_socpeople)

1:1
Fully supported

JDE's Address Book (F0101) is the master entity table for customers, suppliers, employees, and prospects, with contact details in F0111 and phone numbers in F0116. We extract Address Book records with their AN8 (address number) as the primary key and map each to Dolibarr llx_societe (the third-party record) and llx_socpeople (the contact person). Address type (customer vs supplier) maps to Dolibarr's client and fournissor flags on llx_societe. JDE category codes (user-defined fields on F0101) map to Dolibarr custom fields we create during schema setup. Lookup dependencies are resolved by AN8 before contact insert.

Oracle JD Edwards EnterpriseOne

General Ledger (F0901)

maps to

Dolibarr ERP

Accounting Record (llx_accounting_bookkeeping)

1:many
Fully supported

JDE GL records (F0901) carry account codes, amounts, fiscal year periods, and company identifiers in a multi-ledger structure. Dolibarr's accounting module stores entries in llx_accounting_bookkeeping with account number, debit/credit, and period. We extract F0901 by fiscal year, map JDE account numbers to Dolibarr's chart of accounts, and split compound journal entries into individual ledger lines. Note that Dolibarr's accounting module is double-entry only; JDE's multi-ledger flexibility does not map directly and may require account number restructuring for organisations with more than one legal entity ledger.

Oracle JD Edwards EnterpriseOne

Accounts Payable (F0411, F0414)

maps to

Dolibarr ERP

Vendor Invoice (llx_facture_fourn) and Purchase Order (llx_commande_fournisseur)

1:1
Fully supported

JDE AP records (F0411 for header, F0414 for distribution) store vendor invoices with payment terms, G/L distribution, and receipt matching. We map F0411 document number to Dolibarr llx_facture_fourn, vendor AN8 to the supplier Third Party lookup, and F0414 distribution lines to llx_facturefourn_det. Open AP invoices with outstanding balances carry forward; paid invoices migrate as historical records with a paid status. Note that Dolibarr does not have native three-way matching automation; the matching logic is documented for admin to implement as manual procedures.

Oracle JD Edwards EnterpriseOne

Accounts Receivable (F0311, F03B11)

maps to

Dolibarr ERP

Customer Invoice (llx_facture) and Sales Order (llx_commande)

1:1
Fully supported

JDE AR records (F0311 and F03B11) store customer invoices with open or closed status, payment terms, and aging buckets. We map to Dolibarr llx_facture for invoices and llx_commande for related sales orders. JDE invoice numbers and A/R document numbers become Dolibarr ref and ref_client fields. Open invoices migrate with their outstanding balance; paid invoices migrate with the paid status flag set. JDE's aging buckets (F03B14) are computed on import rather than stored directly since Dolibarr computes aging from invoice due dates.

Oracle JD Edwards EnterpriseOne

Item Master (F4101)

maps to

Dolibarr ERP

Product (llx_product)

1:1
Fully supported

JDE Item Master records (F4101) carry item number, description, unit of measure, cost, category codes, and stocking type. We map to Dolibarr llx_product with the JDE short item number or second item number used as the product ref. Unit of measure conversions from F41003 migrate as Dolibarr unit-of-measure entries. Cost layers from F4101 (standard, last, and average cost) map to cost fields in llx_product. Category codes become Dolibarr custom fields or tags since the category code hierarchy in JDE (with up to 30 user-defined category code fields) does not have a direct Dolibarr equivalent.

Oracle JD Edwards EnterpriseOne

Inventory Branch/Plant (F4102)

maps to

Dolibarr ERP

Warehouse Stock (llx_product_stock)

1:many
Fully supported

JDE stores branch/plant inventory levels in F4102, with one row per item per branch. Dolibarr stores stock per warehouse in llx_product_stock. If the source JDE environment uses multiple branches, we split each F4102 row into separate llx_product_stock entries, creating Dolibarr warehouses named after the JDE branch/plant identifier (MCU field). Stock quantities, locations, and lot/serial numbers from F4108 migrate to Dolibarr's lot/serial tracking tables.

Oracle JD Edwards EnterpriseOne

Sales Order Header (F4211)

maps to

Dolibarr ERP

Customer Order (llx_commande)

1:1
Fully supported

JDE Sales Order headers (F4211) carry order number, customer AN8, order date, requested date, branch/plant, and order total. We map to Dolibarr llx_commande with the JDE order number preserved in ref_client. Header-level pricing and taxes embedded in F4211 are extracted separately and mapped to order line tax entries. Order status (F4211 SDDOCST field) maps to Dolibarr's ligne_statu values (DRAFT, VALIDATED, SHIPPED, CLOSED, CANCELLED). Parent-account resolution uses AN8 to lookup the customer's llx_societe record.

Oracle JD Edwards EnterpriseOne

Sales Order Line (F42119)

maps to

Dolibarr ERP

Order Line (llx_commandedet)

1:1
Fully supported

JDE Sales Order lines (F42119) store item number, quantity ordered, quantity shipped, unit price, discount, branch/plant, and line status. We map to Dolibarr llx_commandedet linked to the parent llx_commande. The JDE item number maps to the Dolibarr product reference; if the item is a kit or assembly, we map the bill of materials lines to separate order lines. Line-level taxes from F42119 transfer to tax lines in llx_commandedet. Quantity delivered in JDE becomes shipped quantity in Dolibarr on a 1:1 basis.

Oracle JD Edwards EnterpriseOne

Purchase Order (F4311)

maps to

Dolibarr ERP

Supplier Order (llx_commande_fournisseur)

1:1
Fully supported

JDE Purchase Orders (F4311) store vendor, line items, quantities, prices, and delivery schedules. F4311's row structure intermingles receipt and invoicing lines, so we extract header, line, and schedule data separately and reconstruct them as Dolibarr llx_commande_fournisseur records. Vendor AN8 resolves to the Dolibarr supplier Third Party. The POLT (line type) field determines whether the line is a standard order line or a miscellaneous charge, which maps to Dolibarr's service vs product line distinction.

Oracle JD Edwards EnterpriseOne

Work Order (F4801, F3112, F3003)

maps to

Dolibarr ERP

Project / Task (llx_projet, llx_projet_task)

lossy
Fully supported

JDE Work Orders (F4801) carry routing and operation step data across multiple linked tables (F3112 for operations, F3003 for BOM). Dolibarr does not have native manufacturing work orders; we map work order headers to llx_projet records with work order number as ref and description from F4801. Operations and BOM lines map to llx_projet_task entries with planned hours and dates. Note that Dolibarr's project module does not support routing step sequencing or machine resource scheduling; this is a documented gap for the customer's manufacturing team to address with third-party addons or manual procedures.

Oracle JD Edwards EnterpriseOne

Advanced Pricing (F4072)

maps to

Dolibarr ERP

No direct equivalent

lossy
Fully supported

JDE Advanced Pricing schedules stored in F4072 carry multi-level, volume-sensitive, and formula-based pricing rules with effective date ranges. Dolibarr has no native equivalent to Advanced Pricing; complex pricing rules do not migrate. We extract the full pricing rule hierarchy during discovery, document every price adjustment group, break quantity tier, and formula, and deliver a written pricing schedule inventory. The customer's admin rebuilds key pricing rules in Dolibarr's product price list module or documents requirements for a third-party pricing addon.

Oracle JD Edwards EnterpriseOne

Media Objects (F00165)

maps to

Dolibarr ERP

Document Management (llx_ecm_files)

1:1
Mapping required

JDE stores attachments, images, and embedded documents in F00165 and the filesystem. Oracle requires running R98MODAT before export to load all media objects into the database table. We run R98MODAT as a pre-export step on Tools Release 9.2.1 and later, then extract F00165 records and their associated binary content. Media objects map to Dolibarr's ECM file management (llx_ecm_files) linked to the relevant parent record (Third Party, Product, Order). We resolve the parent reference by matching JDE's object type and key to Dolibarr's entity and rowid before inserting each file record.

Oracle JD Edwards EnterpriseOne

User Defined Objects (UDOs)

maps to

Dolibarr ERP

No direct equivalent

lossy
Mapping required

Custom reports (UBEs), custom tables, and other UDOs tracked in JDE's Object Management Workbench have no direct Dolibarr equivalent. We document every UDO project assignment during discovery (using P98401 to identify modified and custom objects), extract UDO metadata, and deliver a written UDO inventory with object type, project reservation, and modification flag. UDOs are not data records and are not migrated. Dolibarr's PHP addon framework is the replacement path for custom business logic.

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

Dolibarr ERP logo

Dolibarr ERP gotchas

High

Foreign key constraint errors on cross-distribution database restore

High

SQL injection vulnerabilities in version 9.0.1

Medium

Custom fields stored as JSON in extraoptions require field-by-field deserialization

Medium

Decimal precision and rounding configuration affects price fields

Low

No native iOS/Android app forces reliance on browser

Pair-specific challenges

  • Dolibarr REST API lacks bulk endpoints for high-volume imports

    Dolibarr's REST API is designed for single-record CRUD operations rather than high-volume data ingestion. JDE environments with large transaction histories (tens of thousands of GL lines, order records, or inventory movements) require us to batch records into manageable chunks with retry logic and exponential backoff. The API also has per-endpoint rate limits that we must honour. For migrations exceeding 50,000 records of a single object type, we may need to use Dolibarr's direct MySQL database write path in addition to the API, which requires elevated database credentials and careful transaction management to avoid schema validation bypass.

  • JDE packed-decimal and date formats require explicit transformation

    JDE stores numeric fields in packed-decimal (COMP-3) format and dates in Julian format in some legacy tables. Dolibarr's MySQL backend uses standard numeric and date types. We must explicitly cast and transform every numeric and date field during the extract-to-load pipeline. Skipping this step results in corrupted numeric values (e.g., a quantity of 100.00 appearing as a large negative integer) or dates falling in the wrong century. We validate numeric ranges and date boundaries on a sample of 100 records before running the full batch.

  • Advanced Pricing schedules have no Dolibarr equivalent

    JDE's Advanced Pricing engine (F4072) supports multi-level, volume-sensitive, and formula-based pricing rules with commodity table lookups, customer-specific adjustments, and effective date windows. Dolibarr's pricing module is a simple price-list model without rule-based adjustment chaining. Complex pricing hierarchies from JDE do not migrate. We document every pricing rule during discovery and deliver a pricing schedule rebuild guide, but the admin must manually reconstruct key rules in Dolibarr's product price list or via a third-party pricing addon.

  • Media objects silently excluded without R98MODAT pre-export step

    JDE stores some media objects as filesystem files rather than in the F00165 database table. Oracle's recommended approach is to run the R98MODAT utility before any migration export to load all media objects into the database. If R98MODAT is not run, 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. For environments on earlier Tools releases, we flag the additional steps required before media object export can proceed.

  • Dolibarr workflows are substantially less capable than JDE Workflow

    JDE Workflow supports threshold-based approval chains, conditional routing, escalation timers, and originator/manager threshold suppression. Dolibarr's built-in workflow module is designed for simple document state transitions (Draft to Validated to Closed) without the branching logic, multi-level approval chains, or notification threshold controls that JDE Workflow provides. Approval and escalation workflows do not migrate; we deliver a written workflow inventory with every JDE Workflow configuration documented (trigger, conditions, threshold settings, escalation paths) for the customer's admin to rebuild in Dolibarr's workflow module or a third-party workflow addon.

Migration approach

Six steps for a successful Oracle JD Edwards EnterpriseOne to Dolibarr ERP data migration

  1. Discovery and JDE environment audit

    We audit the source JDE environment during a scoped discovery engagement. This includes identifying licensed modules (JDE licenses per functional area), Tools and Applications release versions via P96470, database backend (Oracle or SQL Server), and the F0005 data dictionary scope. We document every table relevant to the migration (F0101, F0901, F4101, F4211, F4311, F4801, F4072, F00165), identify custom UBEs and UDOs via P98401, and flag version mismatches against the Tools Release 9.2.1 minimum required for the R98MODAT utility. We pair this with a Dolibarr module audit to determine which Dolibarr modules (HRM, CRM, Accounting, Stock, Project, Commercial) are required for the target configuration.

  2. Dolibarr schema design and custom field creation

    We design the destination Dolibarr configuration. This includes enabling required modules (Third Party, Contact, Product, Stock, Commercial, Accounting, Project), creating custom fields to capture JDE category codes and user-defined fields, defining the warehouse hierarchy from JDE branch/plant MCU codes, and configuring the Dolibarr chart of accounts based on the JDE GL account structure. For each JDE module in scope, we create the corresponding Dolibarr entity and configure validation rules and required-field settings. Dolibarr runs in a staging environment first for validation before any production migration begins.

  3. Pre-export: R98MODAT and UDO inventory

    Before extracting any data, we run the R98MODAT utility on the source JDE environment (Tools Release 9.2.1 and later) to load all media objects into the F00165 database table. We simultaneously extract the full UDO inventory using P98401 to identify custom and modified objects, capturing object type, project reservation, and modification flag for every UDO. These steps are prerequisites for a complete export and must not be skipped. We document all UDO project assignments before migration for the post-import handoff document.

  4. Extraction, transformation, and data quality checks

    We extract records from JDE's core tables using direct database queries (Oracle SQL or SQL Server T-SQL depending on the backend) for high-volume tables, and the AIS REST API for smaller or more volatile record sets. Every field undergoes explicit type conversion: JDE packed-decimal numeric fields are cast to standard decimal, Julian dates are converted to Gregorian, and alpha fields are trimmed and encoded to UTF-8. We run data quality checks on a sample of 100-200 records per object type before committing to the full batch, validating referential integrity (AN8 lookups resolve to existing records) and checking for null values in fields mapped as required in Dolibarr.

  5. Dependency-ordered import into Dolibarr

    We import records into Dolibarr in strict dependency order: Third Parties and Contacts first (because they are referenced by every commercial and financial record), then Products and Warehouses, then Inventory Stock levels, then Purchase Orders, then Sales Orders and Order Lines, then Financial records (Invoices, GL entries), then Projects and Tasks, then Media Objects via Dolibarr's ECM file module. Each phase emits a row-count reconciliation report comparing imported count to source count, and we flag any records rejected by Dolibarr's validation rules for manual resolution. API rate-limit handling with exponential backoff protects the Dolibarr API from overload during high-volume phases.

  6. Cutover, reconciliation, and workflow rebuild handoff

    We freeze JDE writes during the cutover window, run a final delta migration of any records created or modified since the initial export, then close the Dolibarr staging validation and promote the configuration to production. We deliver the UDO inventory document, the Advanced Pricing schedule rebuild guide, and the JDE Workflow inventory with recommended Dolibarr equivalents to the customer's admin team. We support a one-week post-migration hypercare window for data quality issues. We do not rebuild JDE Workflows, Advanced Pricing rules, or custom UBEs in Dolibarr as part of the migration scope; these are documented for separate rebuild engagements.

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.
Dolibarr ERP logo

Dolibarr ERP

Destination

Strengths

  • Free core software with AGPL license and no per-user mandatory fee for self-hosted deployments.
  • Modular architecture lets teams activate only needed features, keeping the interface focused and the database lean.
  • Self-hosted option provides full data sovereignty and avoids recurring SaaS subscription costs.
  • Built-in CSV/Excel import and export wizard with saved profiles simplifies recurring data operations.
  • Low-code Module Builder allows functional extensions without writing PHP code.

Weaknesses

  • No native documented REST API for programmatic bulk operations — all migrations depend on the import/export wizard or direct database access.
  • Reporting and analytics are weak without paid add-ons, and built-in charts are limited compared to modern SaaS platforms.
  • UI design is described as dated by multiple reviewers, with infrequent visual updates to the default theme.
  • Community-only support for self-hosted deployments means no SLA or guaranteed response time for issues.
  • Security vulnerabilities (CVE-2024-5314, CVE-2024-5315) in version 9.0.1 with no immediate patch reported.

Complexity grading

How hard is this migration?

Standard ERP migration. All 8 core objects map 1:1 between Oracle JD Edwards EnterpriseOne and Dolibarr ERP.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Oracle JD Edwards EnterpriseOne and Dolibarr ERP.

  • Object compatibility

    A

    All 8 core objects map 1:1 between Oracle JD Edwards EnterpriseOne and Dolibarr ERP.

  • 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 Dolibarr ERP 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 Dolibarr ERP data migrations

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

Can't find your answer?

Walk through your Oracle JD Edwards EnterpriseOne to Dolibarr ERP 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 environments with under 10,000 Address Book records, 5,000 inventory items, and no manufacturing or Advanced Pricing data. Projects with full financials (GL/AP/AR with open transactions), work order and BOM data, large media object collections, or Advanced Pricing schedules requiring rebuild documentation move to ten to eighteen weeks because of the extraction complexity, transformation testing, and workflow inventory work.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Oracle JD Edwards EnterpriseOne.
Land in Dolibarr ERP, 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