Upgrading your IBM i operating system is not the kind of project that rewards improvisation. The shops that sail through upgrades start their pre-work eight to twelve weeks out, not the ones that scheduled a weekend and hoped for the best. This checklist distills what Paragon’s IBM i consultants have learned across more than two decades of OS upgrades.
Phase 1: Environment Assessment (8–10 Weeks Before)
Hardware Compatibility
Every IBM i release has a minimum supported hardware generation. If your current system doesn’t meet the requirement for the release you’re moving to, the OS upgrade conversation becomes a hardware refresh conversation first. Check your system model before anything else.
- Run
DSPSFWRSCto confirm your current hardware model and OS level - Check IBM’s documentation for the minimum hardware generation required by your target release before scheduling anything
- Verify available disk space: IBM recommends at least 15% free on the system ASP before upgrade
PTF Currency
Your current system must be at a minimum PTF level before the upgrade. IBM’s upgrade path requires specific cumulative PTF levels to ensure the upgrade process itself runs cleanly.
- Apply the most recent Cumulative PTF package for your current release
- Apply Group PTFs for DB2, Java, and HTTP server
- Run
GO PTFoption 7 to review PTF status - Resolve any PTFs marked as requiring a delayed apply before upgrade weekend
Common mistake: Shops that skip PTF currency on their current release before upgrading frequently hit upgrade failures mid-process. IBM’s upgrade utility expects a certain baseline; if you’re not current, you’ll find out at the worst possible time.
Phase 2: Third-Party Software Audit (6–8 Weeks Before)
Every piece of third-party software on your system, ERP, reporting tools, communications software, security products, needs to be evaluated for compatibility with your target release. This is where most unpleasant surprises live.
- Generate a complete list of installed licensed programs with
DSPSFWRSC *LICPGM - Contact each vendor and request their compatibility matrix for your target release
- Flag any products with no compatible version yet; these become blockers or planned exceptions
- Check IFS-based applications separately; Java and Node.js workloads have runtime dependencies that change between OS levels
Pay particular attention to security and compliance software. IBM i access control products often have OS-specific builds that require upgrade coordination with the vendor.
Phase 3: Application Testing Plan (4–6 Weeks Before)
The most rigorous shops restore a production backup to a separate LPAR, upgrade that environment to the target release, and run structured application testing before touching production. Your testing script should cover at minimum:
- Critical batch jobs. Run your top 10 batch processes end-to-end in the test environment.
- User access and authority. Validate that user profiles and adopted authority function as expected.
- Interfaces and integrations. Test every system-to-system connection, including EDI translators and ERP integrations.
- Output and printing. Spool file handling occasionally behaves differently across OS levels.
- Performance baseline. Run a representative workload and compare metrics to your pre-upgrade baseline.
Phase 4: Upgrade Weekend Preparation
- Full system save to tape or offsite storage immediately before the upgrade begins
- Documented rollback procedure: know how you get back to your prior release if something goes wrong
- Vendor support contacts on standby for any third-party products that showed issues in testing
- Communication plan for end users on expected downtime window
- Post-upgrade validation checklist covering the specific jobs and transactions to run before declaring success
The Five Post-Upgrade Tests
Before bringing users back online, run these five checks every time:
- Sign on as a standard user, not a security officer, and verify basic navigation and job submission work.
- Run a production order through your ERP end to end, from entry to posting.
- Confirm EDI connectivity. Send a test transaction through your EDI translator and verify receipt.
- Verify scheduled job queue. Confirm your automated job schedule is active and jobs are running.
- Check system performance metrics. CPU, memory, and disk I/O should be in expected ranges within 30 minutes of startup.
An IBM i upgrade done right is a non-event. The shops that treat it that way, with structured planning, thorough testing, and documented procedures, consistently complete upgrades on schedule with minimal user impact. Those that improvise find out exactly where their preparation gaps were.
Key Takeaways
- Start pre-work eight to twelve weeks out. The upgrades that go badly are the ones scheduled as a weekend.
- Every release has a minimum hardware generation, so check yours before the OS conversation becomes a hardware conversation.
- Get current on cumulative and Group PTFs for your existing release before upgrading; IBM’s utility expects a baseline.
- Third-party software compatibility is where most surprises hide, so request a compatibility matrix from every vendor.
- Test by restoring production to a separate LPAR, and run the five post-upgrade checks before users return.
Planning an IBM i OS Upgrade?
Paragon’s consultants have managed dozens of IBM i OS upgrades across manufacturing environments. We’ll assess your environment and build a zero-surprise upgrade plan.
Get a free consultation