# JD Edwards EnterpriseOne 9.1 to 9.2 Upgrade Checklist > Source: https://netray.co/tools/jde-enterpriseone-9-1-to-9-2-upgrade-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A step-by-step checklist for an EnterpriseOne application upgrade from 9.0 or 9.1 to 9.2, from planning and table conversions to retrofit, packages and go/no-go. ## Category oracle ## Erp JD Edwards EnterpriseOne ## Audience - JDE CNC administrator - JDE upgrade project manager - JDE developer ## Tool **Kind:** checklist **Groups:** #### Planning **Items:** **Text:** Target applications release (9.2) and target tools release agreed and recorded **Critical:** true **Text:** Database, operating system, WebLogic or WebSphere, Java and browser versions checked against Oracle Certifications (MTRs) for the target tools release **Critical:** true Current planner and upgrade ESUs and any required pre-upgrade fixes identified from the Oracle upgrade documentation for your source release Inventory of all modified and custom objects (system codes 55-59 and modified standard objects) exported from OMW Unused custom objects identified (Object Usage Tracking where your tools release supports it, or log evidence) and retired rather than retrofitted Third-party products and interfaces (EDI, tax, bank, BI tools) confirmed compatible with 9.2 data structures Prod-size copy of the source environment available for a timed test upgrade Freeze dates for development and master data changes agreed with the business #### Deployment server and platform pack **Items:** **Text:** Deployment server installed or upgraded with the 9.2 release and target tools release **Critical:** true Platform pack installed on the enterprise server and database server for your platform Installation plan created in the Installation Planner for the upgrade environments Planner ESU applied and the upgrade plan validated before running workbenches Environment, path code and data source definitions reviewed for the new release **Text:** Backups of system, data dictionary, control tables, central objects and business data taken and restore tested **Critical:** true #### Table conversions and control tables **Items:** **Text:** Table Conversion Workbench run in a test upgrade first and every conversion's runtime recorded **Critical:** true **Text:** Conversion logs and PDFs reviewed for every failed or partially converted table before continuing **Critical:** true Control Table Workbench merges (UDCs, menus, data dictionary items) reviewed so custom UDC values and menus survive Custom tables and custom columns added to standard tables accounted for in the conversion plan Total conversion time on the prod-size copy fits inside the cutover window with contingency Row counts captured before conversion for the key business tables #### Spec merges and retrofit **Items:** **Text:** Specification Merge Workbench completed and merge logs reviewed for objects that could not merge **Critical:** true Each modified standard object compared with Visual Compare and retrofit decisions recorded (reapply, drop, replace with standard feature) Custom objects in system codes 55-59 rebuilt and tested against changed 9.2 tables and business functions Custom business functions recompiled on the new tools release and build errors cleared UDOs (queries, grid formats, personal forms, watchlists, orchestrations, E1 pages) migrated and retested Versions of UBEs and interactive applications with processing options reviewed after merge #### Packages **Items:** **Text:** Full package built for each path code and build logs show no errors in business functions **Critical:** true Full package deployed to enterprise servers, HTML servers and development clients Business services package built and deployed if business services are in use Update package process tested for post-upgrade fixes before go-live #### Testing and cutover **Items:** **Text:** Business test cycles completed for order to cash, procure to pay, manufacturing and financial close **Critical:** true UBE baseline runtimes compared between source and target for the critical batch jobs Security (roles, row security, UDO and feature security) migrated and tested with real user roles **Text:** Post-conversion validation: row counts and totals reconciled for F0911, F0902, F4211, F4111 and F0411 between source and target **Critical:** true Integrity reports run, for example R09705 Compare Account Balances to Transactions, and differences explained Cutover plan with hour-by-hour steps, owners and a timed rehearsal **Text:** Go/no-go criteria written in advance and signed off **Critical:** true Rollback plan to the source environment tested, including the point after which rollback is no longer possible **Scoring Note:** Workbench names and order follow the Oracle EnterpriseOne 9.2 upgrade documentation, which differs by database platform and source release. Use the Oracle Upgrade Guide for your platform as the authority for exact steps. ## Content **Intro:** This checklist covers an EnterpriseOne application upgrade from 9.0 or 9.1 to 9.2: planning, deployment server and platform pack, table conversions, spec merge and retrofit, packages, testing and cutover. Use it alongside the Oracle 9.2 Upgrade Guide for your database platform. **Sections:** #### How to use it **Body:** Run the checklist twice: once for the test upgrade on a prod-size copy, and again for the production cutover. The first pass produces the numbers that matter, especially table conversion runtimes and the list of objects that would not merge. Critical items are gates. Export to Excel and add owner and date columns, then review it in the weekly upgrade meeting. Keep the evidence (conversion logs, merge logs, build logs, reconciliation spreadsheets) linked to each item so audit and the business can follow the decisions. **Bullets:** - Do not skip the timed test upgrade - Assign one owner per group - Store logs with the checklist export #### Where the upgrade work happens in EnterpriseOne **Body:** Most of the technical work runs from the deployment server. The Installation Planner defines the upgrade plan, then the Installation Workbench drives the workbenches in sequence: environment and data source setup, control table merges, Table Conversion Workbench for business data, and Specification Merge Workbench for central objects. Modified objects are then retrofitted in OMW, using Visual Compare to see what changed between your version and the new standard object. Packages are built in Package Build and deployed with Package Deployment, and the business services package is a separate build. #### Worked example: sizing the conversion window **Body:** A 9.1 site on SQL Server with 400 million F0911 rows ran a test upgrade on a prod-size copy. The table conversions took 19 hours, longer than the 36-hour cutover weekend allowed once spec merge, package deployment and validation were added. The team archived closed years of F0911 and F0902 history before the upgrade, re-timed the conversions at 11 hours, and wrote the go/no-go point at hour 30. Reconciliation compared F0902 balances by company and fiscal year between source and target before the business signed off. #### Version differences and gotchas **Body:** A 9.0 source upgrade has more table conversions than a 9.1 source, so do not reuse a 9.1 plan for 9.0. Retrofit is usually the largest effort: modified standard objects need comparison object by object, and custom objects in 55-59 can break where 9.2 changed table layouts. Retire unused customisations instead of retrofitting them. UDOs need their own test pass because they are not part of the OMW spec merge in the same way. Finally, a tools release upgrade is a separate exercise from an applications upgrade, though both are often done together. **Bullets:** - Check conversion lists for your exact source release - Plan retrofit effort per object, not per project - Retest UDOs and security as a separate stream **Cta:** If you want an on-prem AI assistant that helps your team compare objects, track retrofit decisions and answer questions about your 9.2 data, we can set that up on your servers. **Faq:** #### What is involved in a JDE 9.1 to 9.2 upgrade? **Answer:** An applications upgrade installs the 9.2 release on the deployment server and platform pack on servers, then runs control table merges, table conversions on business data and spec merges on central objects. Modified and custom objects are retrofitted, full packages are built and deployed, and the business tests and reconciles data before cutover. #### How do table conversions work in JD Edwards? **Answer:** Table conversions change business data tables to the 9.2 structure. The Table Conversion Workbench runs the conversion programs for your source release and writes logs for each. Time them on a prod-size copy, review every log for failures and reconcile row counts and totals on key tables before go-live. #### What does the JDE simplified upgrade mean? **Answer:** Oracle positions 9.2 as a release that stays current through continuous delivery of ESUs and tools releases instead of new major releases, and publishes guidance to streamline the move to it. The jump from 9.0 or 9.1 to 9.2 is still a full applications upgrade with conversions and retrofit; check the Oracle upgrade documents for your source release. #### How long does a JD Edwards 9.2 upgrade take? **Answer:** It depends on data volume, number of modified objects, and test scope. Typical projects run several months, with retrofit and testing taking most of the time. The cutover itself is sized from the timed test upgrade, so measure conversion and package times rather than estimating them. ## Search terms jde 9.1 to 9.2 upgrade, jde 9.2 upgrade guide, jde 9.2 upgrade, jde simplified upgrade, table conversion in jde, jde upgrade checklist, jde retrofit custom objects, jde spec merge upgrade --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json