Migration playbook
Migrate from JD Edwards to Odoo
JD Edwards is not going away: Oracle offers Premier Support for EnterpriseOne 9.2 through at least 2037. Companies leave it for other reasons: the specialist skills it needs, customisations written in JD Edwards tools that only a few people can change, and a system sized for a larger business than they run today. This is how a JD Edwards EnterpriseOne or World installation moves to Odoo: what data comes across, what is rebuilt, and how the cutover is run.
Last reviewed:
- Discovery
- 1 weekDiscoveryends with a written plan and a fixed price
- Price, set after discovery
- FixedPrice, set after discoveryagreed before any build work
- Oracle Premier Support for EnterpriseOne 9.2
- 2037Oracle Premier Support for EnterpriseOne 9.2"through at least 2037", Oracle, read 29 Oct 2026
We run JD Edwards-to-Odoo moves as part of our Odoo migration services: data mapping, balances reconciled before cutover, and a parallel run before you switch off JD Edwards.
Why businesses migrate from JD Edwards to Odoo
-
Scarce JD Edwards skills
Running JD Edwards needs CNC administration, developers who know its toolset and functional consultants who know its tables. Those skills are specialised and shrinking, so support depends on a few people or one outside firm. Odoo is Python and PostgreSQL, which far more developers already know.
-
Customisations only a few people can change
Years of Form Design Aid changes, Named Event Rules and custom business functions make every upgrade a project of its own. Many companies stay on an old release because retrofitting the changes costs too much. A migration is the point to drop what the business no longer uses and rebuild the rest as Odoo modules.
-
A system sized for a bigger company
JD Edwards was built for complex, multi-site enterprises. A business that has divested, consolidated or simply never used most of it pays to run infrastructure and licences it does not need. Odoo covers finance, inventory, manufacturing, purchasing, sales, CRM, helpdesk and e-commerce in one database.
-
Users who want a modern interface
JD Edwards World runs on green-screen IBM i sessions, and EnterpriseOne forms are dense. Odoo runs in a browser and a mobile app with the same screens, so warehouse, sales and field users can work without a desk.
-
New e-invoicing and tax mandates
E-invoicing rules are spreading country by country. Odoo ships localisations for many of them, such as Saudi ZATCA, Italy FatturaPA, India GST and Peppol, inside the product, rather than as separate add-ons.
-
No deadline, so the timing is yours
Because Oracle supports EnterpriseOne 9.2 through at least 2037, nothing forces the move. That lets you pick a quiet period, migrate one company or site at a time and keep JD Edwards read-only for history.
What survives the migration
Plain-English breakdown of what we move, what we re-map, and what gets rebuilt in Odoo's framework rather than ported.
| Data category | Coverage | Detail |
|---|---|---|
| Address book (customers, suppliers, employees) | Fully migrated | Address book records (F0101) with who's-who contacts, addresses, tax IDs, payment terms and credit limits become Odoo contacts. Customer master (F03012) and supplier master (F0401) settings map to Odoo customer and vendor settings. |
| Items and branch/plant data | Fully migrated | Item master (F4101) and item branch records (F4102) become Odoo products with their warehouses, units of measure, costs and reorder settings. Branch/plants become Odoo warehouses or companies, decided in discovery. |
| Bills of materials, routings and work centres | Fully migrated | Multi-level bills of materials (F3002), routings (F3003) and work centres (F30006) become Odoo BOMs, operations and work centres. Discovery counts them and checks which are still in use before anything is moved. |
| Chart of accounts and business units | Partial / mapped | JD Edwards accounts are business unit, object and subsidiary. In Odoo the object account becomes the general ledger account, and business units become companies, analytic accounts or both, agreed with your finance team and auditor. |
| Opening balances | Fully migrated | General ledger balances from the account balances table (F0902), open receivables (F03B11) and open payables (F0411) are loaded at a cutover date and reconciled to JD Edwards before sign-off. |
| Open sales and purchase orders | Fully migrated | Open sales order lines (F4211) and open purchase order lines (F4311) move with their quantities, prices and dates, so the team carries on from where JD Edwards stopped. |
| Stock on hand and lots | Fully migrated | Quantities by item, location and lot (F41021, F4108) load as Odoo opening stock with cost, so lot and serial tracking carries on. |
| General ledger history | Partial / mapped | The years of account ledger (F0911) history you need for reporting are loaded as summarised or detailed journals. Older history stays in JD Edwards, kept read-only, or in an archive database. |
| Dates and codes | Fully migrated | JD Edwards stores dates as Julian numbers (CYYDDD) and many values as user-defined codes. The migration scripts convert dates and map each code list to Odoo fields or tags. |
| Customisations (Form Design Aid, Named Event Rules, business functions) | Rebuild in Odoo | JD Edwards customisations do not port. Discovery lists each one with who uses it; standard Odoo covers some, and the rest are rebuilt as Odoo modules in Python. |
| UBE reports and Report Design Aid output | Rebuild in Odoo | Batch reports (UBEs) and custom report layouts are rebuilt as Odoo reports, dashboards or spreadsheets. Only the reports someone still reads are rebuilt. |
| Orchestrator, EDI and integrations | Rebuild in Odoo | Orchestrations, EDI interfaces and other integrations are rebuilt on Odoo's API or EDI connectors, one by one, and tested against the trading partner before cutover. |
Our phased approach
-
Discovery week
1 week, fixed priceA senior consultant reviews your JD Edwards release, modules, companies, business units, customisations, reports and integrations. You get a written migration plan, a timeline and a fixed price.
-
Sandbox migration
Set in the discovery planMigration scripts read the JD Edwards tables, convert Julian dates and user-defined codes, and load a sandbox Odoo. Your finance and operations teams check balances, items, BOMs and open orders until they reconcile.
-
Odoo configuration and rebuilds
Runs alongside the sandboxCompanies, accounts, taxes and localisations are configured, and the customisations, reports and integrations kept in discovery are rebuilt and tested in the sandbox.
-
Training
Before cutoverRole-based training on the sandbox, using your own data, so each team practises its daily work before go-live.
-
Cutover
A planned weekendJD Edwards stops taking new transactions, the final load runs, and finance reconciles balances before users start in Odoo.
-
Parallel run and stabilisation
At least one month-end closeJD Edwards stays read-only while Odoo runs live. We fix what surfaces and stay on call until the first month-end close in Odoo is signed off.
Typical timeline
The timeline is set at the end of discovery. It depends most on the number of companies and business units, how many customisations and UBE reports are kept, the years of ledger history you want in Odoo, and the integrations to rebuild. Large groups usually move one company or site at a time, which takes longer overall and lowers the risk of each cutover.
Indicative cost
We price each JD Edwards migration after the one-week discovery, as a fixed price that changes only if the scope does. Odoo Enterprise licences are billed separately by Odoo S.A.
Risks and mitigations
-
Risk: Business unit structure that doesn't map one to one
Mitigation: We design the Odoo companies and analytic accounts with your finance team in discovery and test them against a past JD Edwards month before the sandbox load.
-
Risk: Customisations nobody documented
Mitigation: Discovery reads the object librarian and interviews each team, so every changed object has an owner and a decision: drop, cover with standard Odoo, or rebuild.
-
Risk: Decades of data of mixed quality
Mitigation: We profile the tables before loading, merge duplicate address book records and inactive items, and agree what history comes across.
-
Risk: Costing method differences
Mitigation: JD Edwards standard or weighted-average costs are compared with Odoo's costing methods in discovery, and the inventory valuation is reconciled at cutover.
-
Risk: EDI and trading-partner interfaces
Mitigation: Each EDI document set is rebuilt and tested with the trading partner in the sandbox before cutover, so orders and invoices keep flowing on day one.
-
Risk: Production that can't stop
Mitigation: Open work orders finish in JD Edwards and new ones start in Odoo from an agreed date, so the plant does not stop for the cutover.
Who should migrate
Mid-size companies on JD Edwards EnterpriseOne or World whose system is more than the business needs, whose customisations hold back every upgrade, or who depend on one person or firm to keep it running. Particularly distributors and manufacturers that want one system for finance, stock, production and sales. Not a fit: groups that rely on JD Edwards' depth in areas such as complex project costing or heavy asset management and have the skills to keep running it.
Frequently asked questions
-
Is JD Edwards end of life?
No. Oracle says Premier Support for JD Edwards EnterpriseOne 9.2 is available through at least 2037. Companies move to Odoo for cost, skills and simplicity, not because support is ending, so you can choose the timing.
-
Can Odoo handle JD Edwards business units?
Yes, through Odoo companies and analytic accounts. The object account becomes the general ledger account and each business unit becomes a company, an analytic account or both, depending on how you report. We agree the design with your finance team before any data moves.
-
Do you migrate from JD Edwards World on IBM i as well as EnterpriseOne?
Yes. The data is read from the IBM i database for World and from the EnterpriseOne database for E1. The tables and the mapping are much the same; the extraction differs.
-
What happens to our JD Edwards customisations?
They are listed in discovery with who uses each one. Some are covered by standard Odoo, some are no longer needed, and the rest are rebuilt as Odoo modules. Nothing is rebuilt without an owner who still uses it.
-
How much history do we bring across?
Usually opening balances, open documents and the years of ledger history you report on. Older history stays in JD Edwards, kept read-only, or in an archive database you can query.
-
Do you have a JD Edwards migration case study?
Not a published one yet. We use the same method as our other ERP migrations, such as SAP Business One to Odoo and NetSuite to Odoo: a fixed-price discovery, sandbox loads reconciled with your finance team, and a parallel run before JD Edwards is switched off.
-
What is the first step?
A call to go through your JD Edwards release, modules, companies and main integrations. If a move makes sense, the next step is the one-week discovery. Book a call.