ERP migration
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
Source
Dolibarr ERP
Destination
Compatibility
8 of 13
objects map 1:1 between Oracle JD Edwards EnterpriseOne and Dolibarr ERP.
Complexity
BStandard
Timeline
5-8 weeks
Overview
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.
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 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)
Dolibarr ERP
Third Party (llx_societe) and Contact (llx_socpeople)
1:1JDE'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)
Dolibarr ERP
Accounting Record (llx_accounting_bookkeeping)
1:manyJDE 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)
Dolibarr ERP
Vendor Invoice (llx_facture_fourn) and Purchase Order (llx_commande_fournisseur)
1:1JDE 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)
Dolibarr ERP
Customer Invoice (llx_facture) and Sales Order (llx_commande)
1:1JDE 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)
Dolibarr ERP
Product (llx_product)
1:1JDE 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)
Dolibarr ERP
Warehouse Stock (llx_product_stock)
1:manyJDE 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)
Dolibarr ERP
Customer Order (llx_commande)
1:1JDE 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)
Dolibarr ERP
Order Line (llx_commandedet)
1:1JDE 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)
Dolibarr ERP
Supplier Order (llx_commande_fournisseur)
1:1JDE 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)
Dolibarr ERP
Project / Task (llx_projet, llx_projet_task)
lossyJDE 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)
Dolibarr ERP
No direct equivalent
lossyJDE 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)
Dolibarr ERP
Document Management (llx_ecm_files)
1:1JDE 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)
Dolibarr ERP
No direct equivalent
lossyCustom 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.
| Oracle JD Edwards EnterpriseOne | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Address Book (F0101, F0111, F0116) | Third Party (llx_societe) and Contact (llx_socpeople)1:1 | Fully supported | |
| General Ledger (F0901) | Accounting Record (llx_accounting_bookkeeping)1:many | Fully supported | |
| Accounts Payable (F0411, F0414) | Vendor Invoice (llx_facture_fourn) and Purchase Order (llx_commande_fournisseur)1:1 | Fully supported | |
| Accounts Receivable (F0311, F03B11) | Customer Invoice (llx_facture) and Sales Order (llx_commande)1:1 | Fully supported | |
| Item Master (F4101) | Product (llx_product)1:1 | Fully supported | |
| Inventory Branch/Plant (F4102) | Warehouse Stock (llx_product_stock)1:many | Fully supported | |
| Sales Order Header (F4211) | Customer Order (llx_commande)1:1 | Fully supported | |
| Sales Order Line (F42119) | Order Line (llx_commandedet)1:1 | Fully supported | |
| Purchase Order (F4311) | Supplier Order (llx_commande_fournisseur)1:1 | Fully supported | |
| Work Order (F4801, F3112, F3003) | Project / Task (llx_projet, llx_projet_task)lossy | Fully supported | |
| Advanced Pricing (F4072) | No direct equivalentlossy | Fully supported | |
| Media Objects (F00165) | Document Management (llx_ecm_files)1:1 | Mapping required | |
| User Defined Objects (UDOs) | No direct equivalentlossy | 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.
Oracle JD Edwards EnterpriseOne gotchas
JDE-to-Cloud version parity is mandatory
Media objects must be pre-loaded before export
User Defined Objects lose their project reservation
AIS REST API requires token-based authentication on v2 endpoints
Workflow thresholds silently suppress notifications
Dolibarr ERP gotchas
Foreign key constraint errors on cross-distribution database restore
SQL injection vulnerabilities in version 9.0.1
Custom fields stored as JSON in extraoptions require field-by-field deserialization
Decimal precision and rounding configuration affects price fields
No native iOS/Android app forces reliance on browser
Pair-specific challenges
Migration approach
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.
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.
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.
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.
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.
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
Oracle JD Edwards EnterpriseOne
Source
Strengths
Weaknesses
Dolibarr ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. All 8 core objects map 1:1 between Oracle JD Edwards EnterpriseOne and Dolibarr ERP.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Oracle JD Edwards EnterpriseOne and Dolibarr ERP.
Object compatibility
All 8 core objects map 1:1 between Oracle JD Edwards EnterpriseOne and Dolibarr ERP.
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 JD Edwards EnterpriseOne: Not publicly documented by Oracle for the AIS Server REST API.
Data volume sensitivity
Oracle JD Edwards EnterpriseOne 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 JD Edwards EnterpriseOne to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
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 consultationAdjacent paths
Other ways to leave Oracle JD Edwards EnterpriseOne
Other ways to arrive at Dolibarr ERP
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.