The question is not whether IBM i works. Nor is it whether cloud infrastructure is inherently better. The real question is:

Can your current JD Edwards environment continue to meet the business's requirements for resilience, recovery, support and future change at an acceptable level of risk and cost?

For Redfaire client, Little Rapids Corporation, that question ultimately led to a move from JD Edwards EnterpriseOne on IBM i to OCI. Heather Phillips, Vice President of Information Systems at the company, shared key lessons learned at Oracle InFocus.

IBM i itself was not the problem. The risks came from concentrated operational knowledge, unproven disaster recovery and years of technical dependencies that were making future infrastructure decisions more complex.

For other JD Edwards customers, that raises useful questions: When does maintaining the status quo become riskier than changing it? When can a stable JD Edwards environment still represent operational risk?

Technical stability does not automatically mean low business risk.

A JD Edwards environment may run reliably but still depend heavily on specialist knowledge, recovery processes that have not been fully tested, or technical dependencies accumulated over many years.

For a CIO, some of the most important questions are therefore operational:

• How many people could independently diagnose and recover the production JD Edwards environment?
• What happens if the principal infrastructure specialist is unavailable?
• When was disaster recovery last tested end-to-end?
• Did that test include JD Edwards, integrations and real business transactions?
• What recovery time has actually been demonstrated?
• How does that compare with the downtime the business can tolerate?

There is an important difference between a documented recovery objective and a demonstrated recovery capability. Disaster recovery can involve backups, standby environments, replication and high-availability approaches. The right design depends on what the organisation actually needs to recover, how quickly it needs to recover it and how much disruption the business can tolerate. For a JD Edwards decision-maker, “we have a DR plan” should be the beginning of the discussion, not the conclusion.

Why look beyond JD Edwards when assessing a move from IBM i to OCI?

Because JD Edwards may be only one part of what depends on the existing platform. Over time, ERP environments accumulate integrations, custom programs, scheduled processes and specialist applications. Before planning a migration, establish which dependencies still matter.

A practical approach is to classify them:

• Retire: Does this program or interface still serve an active business requirement?
• Replace: Would a supported third-party or alternative solution now be more appropriate?
• Rebuild or modernise: Does the requirement remain valid but the implementation need to change?
• Redirect or reconnect: Can an existing application remain, with its integration or database connection redesigned?

For Little Rapids Corporation, the assessment included EDI, label printing, data integration with Databricks, Vertex and scheduling tools. Some processes were also candidates for modernisation using JD Edwards Orchestrator.

The individual technologies are less important than the principle. Do the archaeology first. Discovering and remediating decades of dependencies during the infrastructure cutover creates unnecessary pressure on the team and the same deadline.

What should you expect from a DB2-to-Oracle Database migration?

Expect to validate performance rather than assume it will transfer unchanged. Database-specific optimisation in DB2 may not be reproduced automatically when moving to Oracle Database.

Little Rapids Corporation encountered this during testing. DB2-created indexes had been compensating for inefficient queries in parts of the existing workload. The team examined those indexes and recreated the applicable ones in Oracle Database. Most of the performance issues were resolved, with a small number of inefficient reports and applications requiring code changes.

Before migration:

• Identify business-critical and resource-intensive workloads.
• Establish representative pre-migration performance.
• Understand database-specific optimisation and indexing.
• Agree acceptance criteria for the target environment.
• Test representative workloads after conversion.
• Investigate differences before assuming application code needs rewriting.

Performance testing should not be a final go-live check. It should begin during migration discovery.

Why does third-party compatibility need to be checked across the whole stack?

Because individual components can be supported while the complete production configuration is not. Little Rapids Corporation encountered this when Fivetran, selected to move JD Edwards data into Databricks, supported Oracle Database 19c but did not at that time support the Oracle AI Database 26ai version that had been planned.

With cutover approaching, the company chose Oracle Database 19c rather than introduce an unproven workaround.That illustrates why compatibility needs to be assessed across the entire environment, including:

• JD Edwards EnterpriseOne application release
• JD Edwards EnterpriseOne Tools release
• Operating system
• Oracle Database release
• Integration and replication tools
• EDI services
• Tax applications
• Analytics platforms
• Custom applications
• Monitoring and operational tooling

The question should not simply be: “Does Oracle support this database?” It should be: “Is the complete production configuration supported by every vendor we depend on to run this business process?”

How should a JD Edwards OCI migration be tested?

At multiple technical and business layers, with the cutover itself rehearsed. A successful infrastructure test does not prove that a customer order will move successfully across JD Edwards, EDI, tax, labelling and downstream processes. Testing should distinguish between:

• Infrastructure and technical testing
• Database migration testing
• JD Edwards application testing
• Integration testing
• Business-transaction validation
• Performance testing
• Cutover rehearsal
• Disaster recovery testing

Little Rapids Corporation ran four database cutover rehearsals. Execution time fell from approximately 14 hours to nine, then seven and finally around five and a half hours. Its production window allowed eight hours.

The lesson is not that rehearsal guarantees an incident-free deployment. It gives the business increasingly realistic evidence that the proposed cutover can be completed within the available window.

Does moving JD Edwards to OCI eliminate downtime?

No. Moving to Oracle Cloud Infrastructure does not make JD Edwards immune to incidents or outages. That is one of the more useful lessons from the Little Rapids Corporation story. The production migration completed within the required window, with the source reporting no data loss, delayed orders or unplanned manufacturing impact during the transition.

Four days later, however, the new environment suffered a seven-hour outage. The meaningful change was not that incidents became impossible. It was the operating model available when one occurred. Little Rapids Corporation could draw on a broader managed-services team during investigation and recovery, rather than depending principally on one internal infrastructure specialist. The business recovered without losing data or orders.

For CIOs, that reframes the resilience discussion. Ask:

• Who monitors production outside core working hours?
• Who receives alerts?
• Who owns initial diagnosis?
• Who has database, operating system and JD Edwards expertise?
• How are incidents escalated?
• Who can restore service if the usual specialist is unavailable?
• How often is disaster recovery rehearsed?

Cloud infrastructure can support high availability, disaster recovery, and monitoring, but the outcome still depends on the architecture and operating practices implemented around it.

When does moving JD Edwards from IBM i to OCI make sense?

It warrants serious assessment when several business and operational risks begin to converge.These could include:

• Key-person dependency
• Unproven disaster recovery
• Increasing legacy and custom dependencies
• Changing integration requirements
• Limited operational capacity
• Increasing infrastructure investment
• Difficulty supporting future data or analytics requirements

None of these factors on its own means a business should migrate. But when several appear together, maintaining a technically stable environment may carry more long-term risk than assessing an alternative. That distinction matters.

The decision is not simply whether IBM i still works. It is whether the operating model surrounding it remains right for the business.

9 questions to ask before keeping JD Edwards on IBM i or moving to OCI

A CIO considering the future of a JD Edwards environment can assess nine areas.

1. Skills and support

• How many people can resolve a serious production incident?
• Is critical knowledge documented and transferable?
• Is there significant dependency on one or two specialists?
• What expertise is available when something goes wrong?

2. Disaster recovery

• Has JD Edwards disaster recovery been tested end-to-end?
• When was it last tested?
• What recovery time has actually been achieved?
• Does that meet the business's real downtime tolerance?
• Were integrations and downstream processes included?

3. Infrastructure lifecycle

• Does the current estate fit the organisation's lifecycle and support strategy?
• Are upcoming upgrades straightforward?
• What investment will be required to maintain the current model?
  
  

4. Custom and legacy dependencies

• Which RPG, CL and other custom programs remain operational?
• Which are genuinely business-critical?
• Which can be retired rather than migrated?
• Are undocumented dependencies understood?

5. Integration and database dependencies

• How many systems exchange data with JD Edwards?
• Which rely on database-specific capabilities?
• What assumptions have accumulated around DB2?
• Have critical workloads been baselined?

6. Third-party compatibility

• Is the proposed combination of JD Edwards, database, operating system and integrations supported?
• Has the complete production stack been checked across every material vendor?

7. Operational capability

• How effective is current monitoring?
• Can problems be detected before users report them?
• Who owns incidents that cross application, database and infrastructure boundaries?
• Is escalation available outside normal working hours?

8. Future requirements

• What new API, integration and data requirements are foreseeable?
• Is the current architecture constraining analytics?
• Are there specific AI use cases with genuine infrastructure or data requirements?
• How much specialist capacity is consumed simply keeping the infrastructure running?

9. Business impact and economics

• What does an hour of unavailable JD Edwards mean to the business?
• At what point does manufacturing or another critical operation begin to stop?
• What investment is required to maintain the current environment?
• What migration, transition and ongoing costs would an alternative create?
• Should every JD Edwards customer on IBM i move to OCI? No.

A business with strong IBM i expertise, proven disaster recovery, manageable dependencies, appropriate vendor support and an architecture that meets its future requirements may have a compelling reason to stay where it is.

But the reverse also matters.

If key-person dependency, uncertain recovery capability, legacy complexity and future integration constraints are appearing together, a stable environment warrants a more formal assessment.

The strongest decision is not necessarily to migrate or to stay. It is to make that decision based on demonstrated business and operational evidence rather than simply the fact that the system is working today.

Conclusion: compare the risk of migration with the risk of standing still

The lesson from Little Rapids Corporation is not that long-standing JD Edwards customers should leave IBM i. It is that “the system works” is insufficient evidence that the operating model remains right for the business. Migration carries risk too.

Applications and integrations need to be discovered. Database performance needs to be tested. Vendor compatibility may affect architecture choices. Cutover needs rehearsal. And, as the Little Rapids post-migration outage demonstrates, moving to OCI does not eliminate the possibility of a serious incident.

So don't start with a predetermined platform answer. Start by understanding:

• The risks and dependencies in the current environment;
• What the business genuinely needs from its future operating model;
• What staying will require; and
• What changing will require.

The real decision is not simply IBM i versus OCI. It is whether the operating model supporting JD Edwards today is the one the business should rely on tomorrow.

If that answer isn't clear, the next step isn't necessarily migration.

It's assessment. If you'd like to talk through your case and understand Redfaire's Cloud 9, OCI Migration Offer offer, reach out to our team.