JD Edwards 64-Bit Migration Checklist: Everything You Need to Know Before Upgrading
July 14th, 2026
5 min read
By Frank Jordan
A JD Edwards 64-bit migration is an important step toward maintaining a modern, supported ERP environment. While the migration process itself is typically straightforward, every JD Edwards environment is different. Factors such as your current Tools Release, infrastructure, customizations, and third-party integrations can all influence the work required before upgrading.
That's why preparation matters. Taking the time to assess your environment before beginning a migration can help identify potential issues early, reduce project risk, and minimize disruptions during the upgrade process.
The good news is that most JD Edwards 64-bit migrations are highly manageable when potential obstacles are identified early. In most cases, the 64-bit conversion itself is not the difficult part. Oracle has spent years maturing the platform and providing a clear migration path. The challenges organizations encounter are typically tied to custom code, aging infrastructure, undocumented integrations, project scope, and resource availability.
The goal of this checklist isn't to identify reasons not to migrate—it's to help you understand your environment well enough to create a realistic migration plan.
Use the checklist below to verify your current environment, identify key dependencies, and prepare for a successful upgrade.
1. Identify Your Current JD Edwards Environment
Why It Matters
Before planning a 64-bit migration, you need a clear understanding of your current JD Edwards environment. Your Tools Release, application release, and existing architecture will influence the migration path available to you and help identify any prerequisites that should be addressed first.
What to Verify
- Current Tools Release
- Current application release
- Existing deployment server configuration
- Remaining 32-bit components
- Oracle support status
Questions to Ask
- Do we know our current Tools Release?
- Do we know our current application release?
- Have all JD Edwards environments been documented?
- Are any critical components still dependent on 32-bit processing?
2. Review Your Infrastructure
Why It Matters
Reviewing infrastructure early helps ensure operating systems, databases, and hardware are aligned with your migration plans and supported by your long-term technology strategy.
What to Verify
- Operating system versions
- Database versions and compatibility
- Server capacity and performance
- Hardware lifecycle status
- Vendor support requirements
- Web application server and Java versions
Questions to Ask
- Are our operating systems supported?
- Is our database version compatible with our migration plans?
- Does our infrastructure have the capacity to support future growth?
- Are any servers approaching end-of-life?
3. Inventory Customizations and Custom Business Functions
Why It Matters
Standard JD Edwards applications typically migrate without significant issues. The areas that often require the most attention are custom business functions, custom C code, and other modifications developed outside of Oracle.
What to Verify
- Custom business functions
- Custom C code
- Modified applications and UBE’s
- Third-party customizations
- Documentation for existing customizations
Questions to Ask
- Which custom business functions are still actively used?
- Are any customizations undocumented?
- Have we reviewed our custom objects to determine whether any can be replaced with User Defined Objects (UDOs)?
- Which customizations require additional testing?
4. Review Third-Party Integrations
Why It Matters
Most JD Edwards environments exchange data with external systems, making it important to understand how those connections will be validated during the migration.
What to Verify
- Integrations/Middleware connections (Oracle Application Integrations, WebSphere, Boomi, Salesforce, cloud solutions, etc.)
- External applications (Bar-code solutions, print/archive software, E1 security applications, freight/shipping calculations, etc.)
- EDI systems
- Reporting platforms (ReportsNow)
- Interfaces and data exchanges
Questions to Ask
- Have all integrations been documented?
- Which interfaces are business-critical?
- Are there any unsupported third-party solutions in use?
- Who owns each integration?
5. Understand How Your Application Release Impacts the Migration
Why It Matters
Your current JD Edwards application release plays an important role in determining your migration path. While some organizations choose to combine an application update with a 64-bit migration, others prefer to complete those projects separately. Understanding your current application release and update level helps identify prerequisites, compatibility requirements, and available migration options before the project begins.
What to Verify
- Current JD Edwards application release
- Current Application Software Update (ASU) level
- Dependencies between your application release and Tools Release
- Oracle-supported migration path for your environment
- Compatibility with your planned 64-bit migration
Questions to Ask
- What JD Edwards application release are we currently running?
- Are we current on the latest Application Software Updates (ASUs) required for our environment?
- Are there any application prerequisites that should be completed before migrating to 64-bit?
- Would combining an application update with our 64-bit migration make sense for our environment, allowing us to complete testing and validation as part of a single project?
- Do we understand the dependencies between our application release and Tools Release?
6. Build a Testing Strategy
Why It Matters
Testing should be planned long before the migration begins. A structured testing strategy helps ensure technical functionality, integrations, and business processes continue working as expected after the upgrade.
What to Verify
Development Testing
- Technical functionality
- Package builds
- Custom object validation
Integration Testing
- Third-party systems
- Interfaces and data exchanges
User Acceptance Testing (UAT)
- Business workflows
- Critical transactions
- Department-specific processes
Performance Testing
- Response times
- Batch processing
- System performance
Questions to Ask
- Who will participate in testing?
- Have critical business processes been identified?
- Have testing timelines been established?
- How will issues be tracked and resolved?
7. Select Your Migration Approach
Why It Matters
Not every organization follows the same migration path. Understanding your options early helps establish realistic expectations and avoid unnecessary project delays.
What to Verify
Full 64-Bit Migration
- Long-term migration strategy
- Infrastructure readiness
- Resource availability
Temporary Deployment Server Migration
- Business justification
- Technical limitations
- Long-term migration roadmap
Questions to Ask
- Is a full 64-bit migration feasible today?
- Are we considering a temporary workaround?
- Do all stakeholders understand the long-term implications of our chosen approach?
8. Plan Around Business-Critical Dates
Why It Matters
Even a well-executed migration can create unnecessary risk if it occurs during critical business periods.
What to Verify
- Payroll processing schedules
- Year-end activities
- Compliance deadlines
- Peak operational periods
- Major business events such as acquisitions or expansion
Questions to Ask
- Are there blackout periods we should avoid?
- When are key business teams available for testing?
- Could seasonal activity impact project timelines?
9. Prepare a Rollback and Recovery Plan
Why It Matters
As with any technology initiative, it's important to establish backup and recovery procedures before go-live.
What to Verify
- Backup procedures
- Recovery procedures
- Recovery testing
- Escalation processes
- Communication plans
Questions to Ask
- Have backups been validated?
- Has recovery testing been performed?
- Does everyone understand the rollback process?
10. Validate the Environment After Migration
Why It Matters
Migration success should be measured by business outcomes, not just technical completion. Validation ensures the environment is functioning as expected before normal operations resume.
What to Verify
- Package builds complete successfully
- Customizations function properly
- Integrations and interfaces operate correctly
- Security settings remain intact
- Critical business processes perform as expected
- Database table record counts match if a separate installation was leveraged
- Integrity and audit reports match
Questions to Ask
- Have all validation activities been completed?
- Have business users signed off on testing?
- Are there any outstanding issues that require resolution?
Frequently Asked Questions
How Long Does a JD Edwards 64-Bit Migration Typically Take?
The timeline depends on the complexity of your environment. Organizations with current infrastructure and minimal customizations may complete the migration relatively quickly, (8 – 24 weeks) while environments with extensive custom code, integrations, or outdated infrastructure often require additional planning and testing. The best way to estimate a timeline is to assess your environment before beginning the project.
Do Custom Business Functions Need to Be Updated?
Not always, but they should be reviewed as part of your migration checklist. Standard JD Edwards applications typically migrate without significant issues, while custom business functions and custom C code often require additional testing or modifications.
Should we rationalize our E1 customizations?
If the E1 applications are updated, it is strongly recommended to review the various customizations that may be candidates to be migrated to a user defined object (UDO). An example is application form text, or vocabulary overrides could be changed to a UDO, so they don’t have to be retrofit each time the application is updated. Orchestrations can be crafted to reduce process time and clicks.
Can I Migrate My Deployment Server First?
In some situations, migrating the deployment server can serve as a temporary workaround. However, most organizations should view this as a short-term solution rather than a replacement for a complete 64-bit migration strategy.
What Should Be Tested Before Going Live?
At a minimum, organizations should test customizations, third-party integrations, critical business processes, security roles, and system performance. A thorough testing plan helps identify issues before they impact end users.
What Is the Most Important Step Before Starting a 64-Bit Migration?
Understanding your current environment. Before upgrading, organizations should document their Tools Release, infrastructure, customizations, integrations, and application release levels. This assessment serves as the foundation for every other step in the migration process.
Turning Your Checklist into a Migration Plan
A successful JD Edwards 64-bit migration starts long before the upgrade itself. By taking the time to understand your environment, review infrastructure requirements, identify customizations, validate integrations, and build a thorough testing strategy, you can reduce risk and avoid many of the issues that commonly delay migration projects.
While every JD Edwards environment is unique, the checklist in this article provides a practical framework for evaluating readiness and planning your next steps.
If you're preparing for a JD Edwards 64-bit migration and aren't sure where to start, ERP Suites can help evaluate your current environment, identify potential dependencies, and develop a roadmap that aligns with your business and technical requirements.
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.
.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)
