The Hidden Complexities of Releasing New Versions on IBM^® i

Delivering a new release of Rocket^® DevOps is always a milestone. It represents months (or years) of effort from development, testing, documentation, and support teams. But for those of us in the IBM^® i ecosystem, the release process is rarely straightforward. 

Let’s highlight the less visible aspects of product releases: The challenges that come with compatibility, upgrades, and long-term support. While every vendor and product team face their own unique set of hurdles, these three recurring themes are what I’ve seen surface often during release cycles. But  how can organizations navigate them? 

1. Keeping pace with IBM i operating system updates 

IBM^® i continues to evolve, with frequent Technology Refreshes (TRs) and periodic major releases. Each change brings improvements, but also potential risks for software vendors.

• Compatibility risks: Even small changes in IBM i can alter behavior in ways that impact our product. APIs may be deprecated, security models enhanced, or system tools replaced.
• Testing demands: Before any release, we invest heavily in testing across multiple IBM i versions to ensure stability. This requires not only technical effort but also access to test environments running each supported release.

What you can do:

• Maintain a dedicated lab of environments spanning supported IBM i versions.
• Collaborate with IBM early in the Technology Refresh cycle to anticipate breaking changes.
• Provide customers with clear IBM i version support matrices. 

2. Interdependencies with third-party tools 

Modern IBM i applications rarely exist in isolation. Our product integrates with Git^® source control, CI/CD platforms, ticketing systems, and even security solutions. The challenge is that these third-party tools evolve independently. 

• Version Drift: A new release of a third-party tool may suddenly break our integration.
• Vendor Coordination: We’re often reliant on other vendors’ roadmaps and priorities, which may not align with ours.

What You Can Do

• Build robust, standards-based integrations wherever possible.
• Maintain automated test pipelines that exercise integrations with the latest versions of third-party tools.
• Offer guidance to customers on “certified” third-party versions we have tested. 

3. Upgrading customers from older versions of our software 

Not every customer upgrades frequently. Some may be running versions of our product that are five, ten, or even 15 years old — a strategy that carries significant risk. Upgrading customers to the latest release is rarely a one-click process. 

• Multiple jumps required: Sometimes, the product architecture has changed so significantly that direct upgrades aren’t possible. Customers may need to step through multiple interim versions.  
• Data conversion: Schema changes and configuration transformations must be carefully managed to avoid disruption.
• Risk aversion: Customers understandably worry about the impact on mission-critical applications. 

What You Can Do

• Provide clear upgrade paths and documentation outlining required steps.
• Where possible, deliver migration utilities to automate data and configuration transitions.
• Offer professional services or partner support for complex upgrades. 

4. Supporting older versions when dependencies change 

Even after releasing a new version, older versions remain in use. Supporting them can be difficult, especially when third-party dependencies like Java^® or compilers evolve.

Shifting Ground: For example, when Oracle^® or IBM changes Java support policies, older versions of our product may no longer run reliably.
Customer Expectations: Some customers expect older versions to remain fully supported, even when the underlying platform no longer cooperates.

What You Can Do

• Define and communicate a clear support lifecycle policy (e.g., N-2 releases).
• Provide customers with advance notice when third-party changes affect older versions.
• Encourage proactive upgrades rather than reactive problem-solving. 

5. Other challenges worth mentioning 

The issues above are common, but they are by no means the only difficulties in delivering a new release. For example: 

• Localization and multi-language support.
• Hardware differences across customer sites.
• Security compliance requirements (e.g., encryption standards).
• Customer-specific customizations that complicate upgrades.
   

Final thoughts

Releasing a new version of software on IBM i is never just about adding features. Every release is a balancing act of priorities, trade-offs, and risk mitigation. For Rocket Software, it’s about compatibility, continuity, and the confidence of customers who rely on our product for mission-critical workloads.

There’s rarely a single, flawless approach to releasing software — especially in complex environments like IBM i. Success comes from a deliberate blend of disciplined testing and validation, clear and consistent communication, and well-defined policies that guide support and lifecycle planning. When these elements are in place, organizations reduce risk, improve reliability, and also build credibility. By being transparent about what’s involved, what’s evolving, and what’s expected, we foster trust and create a stronger foundation for long-term partnership and performance. 

IBM is a trademark of International Machines Corporation

Oracle, Java, MySQL, and NetSuite are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Git and the Git logo are either registered trademarks or trademarks of Software Freedom Conservancy, Inc., in the United States and/or other countries