Adapted and summarized by ChatGPT. Download Paul’s full article.
Migrating to a new version of a critical platform like Db2 for z/OS might sound daunting, but with the right strategy, it can be manageable and an opportunity to improve operational efficiency. Db2 13 is built for a simpler transition than past versions, offering enhancements that further support online upgrades, better planning flexibility, and minimal business disruption.
This article outlines seven key steps you can take—even before you order Db2 13—to lay a solid foundation for a successful migration.
Setting the Stage for Migration
Db2 has long led the way in enterprise database migration strategies. From early fallback mechanisms to coexistence across versions, each new version of Db2 continues to make the process more stable and flexible. Db2 13 for z/OS is no different. It introduces a smaller fallback SPE (Small Programming Enhancement), introduces no catalog or directory changes during the first function level (FL100), and allows coexistence with version 12 systems during upgrades.
With some task optimization and sequencing, this project can be started swiftly and enhance the overall experience.
1. Treat Migration as a Project, Not a bunch of tasks
The most successful migrations treat the process as a formal project, with a designated leader, stakeholder buy-in, and defined objectives. Db2 installations typically span multiple subsystems and applications—this complexity demands coordination.
Your first step should be assembling a cross-functional project team, pulling in voices from system programming, application development, and operations. Review documentation from your last migration, leveraging that experience.
Time is of the essence: Db2 12 support ends on December 31, 2025. As of this writing, Db2 13 has already delivered nine function levels (the latest being FL507), many of which were released through continuous delivery. While the FL100 milestone ensures you’re officially on Db2 13, a complete migration plan must include forward-looking feature adoption as well.
2. Verify Prerequisites and Compatibility
You can’t migrate to Db2 13 unless your system is already at Db2 12 function level 510 (via APAR PH33727). Additionally, you’ll need the fallback SPE (PH37108) and other maintenance like PH43770 for IRLM.
Use the DISPLAY GROUP DETAIL command (if PH50072 is applied) to generate a Migration Readiness report. Don’t forget: these reports won’t catch everything. Collaborate with your project teams to verify you’re truly ready, assessing incompatibilities, deprecations, and removed items across dev, test, and production environments.
3. Educate Yourself and Your Team
Db2 13 is not just an upgrade. Understanding what it can do is crucial.
There are several trusted educational sources:
- IBM Redbooks, like Db2 13 for z/OS Technical Overview and Performance Topics
- IBM’s “What’s New in Db2 13” documentation
- Db2&You, Rocket Software’s free workshop series that organizes Db2 13 features by business roles and functional categories
These resources help you move beyond just “what to install” and into the territory of “how to use it well.” With continuous delivery changing the shape of Db2 regularly, staying informed isn’t optional—it’s essential.
4. Assess Risks and Obsolete Features
Incompatibilities, deprecated features, and removed components are part of every major version release—and Db2 13 is no exception.
Run the Db2 12 DSNTIJPE (or DSNTIJPM in Db2 13) to surface: – Deprecated objects – Incomplete definitions – Items that may cause catalog maintenance issues – IVP (Initial Verification Program) dependencies
This job creates over 20 reports and is available even in Db2 12 with the right APARs installed. Review ZPARMs and application defaults to understand what has changed. The key here is early identification—don’t wait until you’re mid-migration to find a potential project show stopper..
5. Mediate High-Risk Areas (Plans, Packages, and Red Alerts)
Plan/Package Management
Older plans and packages can create friction during migration. While Db2 does allow runtime conversion of older packages, this process can degrade performance. Use PLANMGMT(EXTENDED) and the SWITCH option to maintain and roll back packages if needed.
Features like APREUSE(WARN) and APREUSE(ERROR) help manage access path changes during REBINDs. These tools help maintain consistency without blindly accepting performance regressions.
Also, don’t forget the Application Compatibility (APPLCOMPAT) setting—it allows you to control when DML changes take effect for specific applications. But beware: relying on it forever is not a strategy. Begin planning to upgrade applications to newer APPLCOMPAT levels over time.
Red Alerts
Check IBM’s Red Alert system for any high-impact items that could affect your migration. At the time of this writing, one notable alert relates to Partition-By-Range (PBR) RPN page sets in data sharing installations.
6. Use Db2 12 to Prepare and Validate
Before you ever install a Db2 13 library, you can—and should—validate your system using Db2 12 tools. DSNTIJPE, mentioned earlier, is such an example.
Start with:
- DSN1COPY with CHECK option for catalog and directory page sets
- CHECK DATA and CHECK INDEX
- RUNSTATS to help CHECK operations run smoothly
- Next, execute Db2-provided consistency jobs like:
- DSNTESQ: Verifies internal catalog relationships
- IVP: Though the full test suite isn’t needed until late-stage migration, running it early gives you a baseline
- DSNTIJXZ: Recreates your current ZPARM settings (DSNTIDxx) by analyzing your system and logs
These prep steps ensure you’re not building your migration on a shaky foundation.
7. Coordinate with Third-Party Vendors
Your applications rely on more than just Db2—what about your vendor tools? These must be reviewed for compatibility with Db2 13 and its function levels.
If you’re using IBM Db2 Tools, IBM provides a regularly updated compatibility chart. For other vendors, reach out directly and make this part of your project timeline. Failing to coordinate tooling upgrades has derailed more than one otherwise successful migration.
Final Thoughts
While the idea of migrating to a new version of Db2 may initially seem overwhelming, following a structured, proactive plan makes all the difference. Db2 13 was designed with ease of adoption in mind, offering streamlined catalog handling, and robust validation tools. Use the time before end-of-support for Db2 12 wisely—much of the groundwork can begin now.
Start by assembling your team and building a migration roadmap. Educate your stakeholders, assess risks, and validate your environment using the assets you already have. The seven steps in this article are not just helpful—they’re essential to getting ahead of the curve.
And if you’re looking for guided support, consider Rocket Software’s Db2&You initiative—a no-cost, facilitator-led program designed to make the entire process clearer, smarter, and better aligned to your business goals.
For more resources and upcoming sessions of Db2&You, email db2andyou@rocketsoftware.com.
This article was adapted and summarized by ChatGPT. Download Paul’s full article in PDF format.
Paul Bartak has been working with IBM databases since 1985, including the first version of DB2 on MVS. As an IBM customer for 14 years Paul worked in Application Development, Database Administration, and DBA. He joined IBM in 1999 as an Information Management Technical Specialist, teaming with Sales to present, design, install, demonstrate, and evaluate IBM Information Management solutions in a pre-sales environment; gaining multiple certifications in Database Administration, Data Replication, Blockchain, and Cloud Computing. Currently, as a Distinguished Engineer with Rocket Software, Paul is focused on the tools used to maximize DB2 for z/OS value, with emphasis in database cloning and DevOps processes. He supports multiple Db2 User Groups, has been a speaker at several IDUG and Insight/Think conferences, is a Redbook/Redpaper author, and IBM Champion.