Oracle's recent announcement regarding the transition away from 32-bit support has prompted many JD Edwards customers to evaluate their readiness for a 64-bit environment.
For some organizations, the transition is already complete. For others, especially those running older tools releases or legacy infrastructure, preparation may require additional planning.
The good news is that moving to 64-bit is about understanding your current environment, identifying dependencies, and creating a roadmap for the future.
If you're wondering where to start, here are the key areas every organization should evaluate before beginning a 64-bit migration.
Which JD Edwards Customers Should Be Preparing Right Now?
While every organization should understand its current environment, some customers should prioritize planning sooner rather than later.
This includes organizations that:
- Are running older JD Edwards tools releases prior to 9.2.5
- Have not completed a significant upgrade in several years
- Rely heavily on custom business functions
- Operate complex integrations with third-party systems
- Are planning broader infrastructure or database upgrades
If any of these situations apply to your organization, now is a good time to begin evaluating your readiness for a 64-bit environment.
Step 0: Determine Your Current 64-Bit Readiness
Before creating a migration plan, it's important to understand your starting point.
Not every JD Edwards customer is beginning from the same place. Some organizations have already completed portions of the 64-bit transition, while others may still be running older tools releases that require additional planning.
Start by documenting your current tools release, deployment server configuration, and upgrade history. The goal is to understand how much migration work has already been completed and identify any immediate gaps that need attention.
Deliverable: A readiness summary that documents your current tools release, deployment server status, and overall migration starting point.
Step 1: Build a Complete Environment Inventory
Once you understand your starting point, the next step is documenting your JD Edwards ecosystem.
Inventory all environments—not just Production—including Development, Test, and Training environments. Create an inventory of JD Edwards release levels, databases, operating systems, web servers, enterprise servers, and major integrations.
Just as importantly, identify all inbound and outbound integrations. This includes EDI transactions, reporting platforms, middleware solutions, third-party applications, custom interfaces, and any systems that exchange data with JD Edwards.
The goal isn't to evaluate what needs to change yet. At this stage, you're simply creating a complete picture of what exists today.
Deliverable: A comprehensive environment inventory document that captures your JD Edwards architecture, supporting systems, and integration landscape.
Step 2: Evaluate Infrastructure Supportability and Future Plans
With a complete inventory in hand, the next step is determining which components can support your future-state environment.
Review the support status of your servers, operating systems, databases, middleware, and related infrastructure. Identify components approaching end-of-life, no longer supported by Oracle, or already scheduled for replacement.
This is also the time to consider future initiatives such as cloud migrations, hardware refreshes, virtualization projects, or database modernization efforts. Many organizations discover that combining these initiatives with a 64-bit migration reduces overall project cost and disruption.
Questions to consider include:
- Are any servers scheduled for replacement within the next few years?
- Are database upgrades already being planned?
- Will future cloud initiatives impact migration decisions?
- Are any critical infrastructure components nearing end-of-support?
Deliverable: A list of infrastructure dependencies, supportability concerns, and recommended upgrades that should be incorporated into the migration plan.
Step 3: Assess Customizations and Custom Business Functions
Once you've documented your environment, the next step is understanding how customizations may impact the migration.
For many organizations, custom code represents the greatest unknown in a 64-bit migration. Standard JD Edwards functionality is generally straightforward to migrate because Oracle provides the tools and processes necessary to support the transition. Custom objects, however, require additional review.
Start by identifying custom business functions, applications, reports, tables, Named Event Rules (NERs), and other modifications that have been developed over time. Then evaluate which customizations are actively used, which may no longer serve a business purpose, and whether source code and supporting documentation are available.
Questions to consider include:
- Do we still have the source code?
- Does anyone on staff understand how the customization works?
- Is the customization still necessary?
- Could standard JD Edwards functionality replace it?
This assessment can help reduce risk while also identifying opportunities to simplify the environment before migration begins.
Deliverable: A catalog of custom objects prioritized by business importance and migration risk.
Step 4: Create a Testing Plan
With infrastructure and customization requirements identified, the next step is to determine how the upgraded environment will be validated.
Testing should be planned before any migration work begins. Waiting until the upgraded environment is available often leads to delays, incomplete testing, and missed business requirements.
Start by identifying the individuals who should participate in testing, including representatives from departments such as Finance, Distribution, Manufacturing, Human Resources, and IT. Then define the business processes that are critical to daily operations and must be validated after the migration.
Examples may include:
- Order-to-Cash
- Procure-to-Pay
- Financial Close
- Payroll Processing
- Reporting and Analytics
- EDI Transactions
- Orchestrations
- Third-Party Integrations
The goal is to establish clear ownership, testing responsibilities, timelines, and success criteria before the migration project begins.
Deliverable: A testing plan that identifies participants, business processes, testing timelines, and validation criteria.
Step 5: Create an Upgrade Roadmap
The final preparation step is bringing everything together into a structured project plan.
At this point, you should have a clear understanding of your current environment, infrastructure requirements, customizations, and testing needs. The roadmap transforms that information into an executable migration strategy.
Start by defining the scope of the project. Depending on your environment, the initiative may involve:
- A 64-bit migration only
- A JD Edwards tools upgrade
- A broader technology refresh
- A larger modernization initiative
From there, establish ownership, timelines, resource requirements, project dependencies, and key milestones.
Questions to answer include:
- Who owns the project?
- What internal resources are available?
- What budget has been allocated?
- What systems must be upgraded first?
- What downtime window is acceptable?
- Are there business blackout periods that should be avoided?
A typical roadmap often includes phases such as:
- Assessment and Planning
- Infrastructure Preparation
- Upgrade and Migration
- Testing and Validation
- Production Cutover
- Post-Go-Live Support
Creating a roadmap early helps organizations manage risk, align stakeholders, and maintain momentum throughout the project.
Deliverable: A documented migration roadmap with defined phases, ownership, milestones, and timelines.
What If You're Not Ready for a Full Migration?
Not every organization is ready to begin a full 64-bit migration immediately.
In some situations, it may be possible to move the deployment server to a 64-bit environment while postponing a broader migration effort. This approach can provide temporary flexibility and allow organizations additional time to prepare for a larger project.
However, this should generally be viewed as a short-term option rather than a long-term strategy. For most organizations, the best approach is to continue building a roadmap toward a fully supported 64-bit environment.
Deliverable: A temporary path forward that can provide additional planning time while longer-term migration activities are being evaluated.
The Bottom Line
Preparing your JD Edwards environment for 64-bit is less about the migration itself and more about understanding your environment, identifying dependencies, and planning effectively.
Organizations that take the time to assess their infrastructure, review customizations, build a testing strategy, and create a roadmap are typically able to complete the transition with fewer surprises, less disruption and will be more likely to implement transformational changes to get more ROI.
At ERP Suites, we help JD Edwards customers evaluate their current environment, identify potential risks, and develop practical upgrade strategies that align with their business goals. Whether you're planning a full technology refresh or simply beginning to assess your readiness for 64-bit, having a clear plan in place can make all the difference.
The sooner you understand where your environment stands today, the more options you'll have tomorrow.
Frank Jordan is a CNC technology consultant with over 300 customer engagements. Read Frank Jordan's blog on JD Edwards and ERP technology. His work with JD Edwards Orchestrator Studio earned ERP Suites three Distinguished Partner Awards for digital innovation at Oracle Partner Summit. Frank is the co-author of Advanced Tuning for JD Edwards EnterpriseOne Implementations and a frequent conference presenter.
Topics:
.png?width=650&height=325&name=Blog%20Images%202_1%20(2).png)
.png?width=650&height=325&name=Blog%20Images%202_1%20(1).png)
.png?width=960&height=540&name=Blog%20Images%20(98).png)
.png?width=960&height=540&name=Blog%20Images%20(88).png)
.png?width=960&height=540&name=Blog%20Images%20(86).png)
.png?width=960&height=540&name=Blog%20Images%20(85).png)
.png?width=960&height=540&name=Blog%20Images%20(83).png)
.png?width=960&height=540&name=Blog%20Images%20(75).png)
.png?width=960&height=540&name=Blog%20Images%20(71).png)
.png?width=960&height=540&name=Blog%20Images%20(3).png)
