Congratulations. By now you should have migrated to Db2 13 for z/OS bringing you up-to-date with Db2 versions. But now what?
For too many organizations, the answer is: pretty much the same thing we were doing before.
The migration project gets completed, Db2 13 goes into production, everybody celebrates, and then the environment continues operating largely as it did under Db2 12. Applications continue using the same SQL, packages remain at older application compatibility levels, operational procedures change very little, and many of the capabilities delivered with Db2 13 remain unused.
There is nothing inherently wrong with being cautious. In fact, caution is usually a good characteristic for anyone responsible for mission-critical Db2 systems. But there is a difference between controlled adoption and simply ignoring new capabilities.
Installing Db2 13 and exploiting Db2 13 are two very different things.
Db2 Is No Longer a Once-Every-Few-Years Event
Long-time Db2 professionals remember when a new version meant a large, discrete migration project. You installed the new release, migrated the catalog, tested applications, and then operated on that version until IBM delivered the next one.
Continuous delivery changed that model.
With Db2 13, IBM delivers many new capabilities through the maintenance stream as they become ready. Function levels and application compatibility levels provide mechanisms for controlling when those capabilities become available to the subsystem and applications.
As of September 2026, Db2 13 has progressed through Function Level 509 (V13R1M509), which IBM delivered in April 2026. FL509 introduced capabilities including catalog table-space conversion to UTS, subnet filtering for the Resource Limit Facility, online ownership transfer for certain application objects, additional utility-history information, I/O counts in real-time statistics, and improvements involving data-sharing page P-lock contention.
The important point is not any particular function delivered by FL509. It is that Db2 continues to evolve after you migrate to each new version!
That requires a corresponding change in how DBAs think about Db2 maintenance.
Know What Level You Are Actually Running
One of the complications of continuous delivery is that saying, "We're running Db2 13," doesn't tell us everything we need to know.
There are several related levels to understand: code level, catalog level, function level, and application compatibility level. They work together, but they are not the same thing.
The code level reflects the Db2 code installed through maintenance. The catalog level identifies the level of the Db2 catalog. The function level determines which continuously delivered capabilities have been activated. And APPLCOMPAT controls which new SQL capabilities and behaviors an application can use.
IBM provides the -DISPLAY GROUP command as one way to determine the code, catalog, and function levels of your Db2 environment.
This is important because you can have the code installed for a capability without actually having that capability available for use.
And even after activating a new function level, your applications do not automatically have to adopt every new SQL behavior. In most cases, new SQL syntax and behavior require the application to operate at the corresponding APPLCOMPAT level.
That separation is a feature, not a problem. It gives DBAs control.
APPLCOMPAT Is Your Friend
I've encountered organizations that view APPLCOMPAT primarily as another complication associated with Db2 maintenance. I prefer to look at it as a risk-management mechanism.
Suppose your subsystem is operating at a newer Db2 13 function level, but you have an important application that has not yet been thoroughly tested against the corresponding SQL behavior. You do not necessarily have to move that application forward immediately.
IBM specifically designed APPLCOMPAT so applications can adopt new capabilities when the organization is ready. Applications can continue operating with behavior associated with earlier compatibility levels even when the subsystem has moved ahead.
That is extremely useful in large enterprises where hundreds or thousands of packages may support applications with very different development schedules and business priorities.
Indeed, IBM recommends that customers not immediately raise the subsystem's default APPLCOMPAT level after migration or function-level activation. Applications should first be verified at the higher level and incompatibilities addressed.
In other words, continuous delivery does not mean reckless delivery... it means controlled delivery.
Don't Forget About Performance
New function is not the only reason to examine what Db2 13 offers. Performance improvements can be just as important. And sometimes more important.
Db2 13 has delivered improvements involving sort processing, INSERT processing, index look-aside optimization, Fast Traversal Blocks, external security processing, and other areas. Function Level 506, for example, introduced an optimization for certain queries containing large residual IN-list predicates that IBM says can substantially reduce CPU consumption for applicable SQL.
But there is an important lesson here for DBAs: a performance enhancement sitting in the product documentation isn't improving your workload merely because you migrated to Db2 13. Some enhancements become effective when maintenance is applied. Others depend on function levels. Optimization improvements may require a full prepare of the SQL before a new access path can take advantage of them. For static SQL, that generally means a bind or rebind.
And that means you need to understand how new Db2 capabilities intersect with your existing package management, access-path management, statistics, testing, and REBIND strategies.
Simply installing Db2 isn't performance tuning.
Make Exploitation an Ongoing DBA Discipline
So what should you be doing?
Periodically review what IBM has delivered since your last Db2 capability assessment. Determine your current code, catalog, function, and application compatibility levels. Review the new-function APARs and function levels that have become available. Identify enhancements relevant to your workloads, and determine what must happen before you can safely exploit them.
Then prioritize.
You do not need to implement every new feature just because IBM delivers it. That would be just as misguided as ignoring everything new. A high-volume transaction processing environment may benefit from different enhancements than a mixed analytics environment. Security improvements may be urgent for one organization while SQL or utility improvements provide greater value for another.
The objective should be deliberate exploitation.
Ask what business, performance, availability, security, or operational problem a capability solves. Test it appropriately. Understand its prerequisites. Determine its effect on applications and access paths. Then introduce it under controlled conditions.
That sounds like traditional DBA discipline because it is.
Migration Is the Beginning, Not the End
There is a tendency to treat a Db2 migration as a destination. We get to Db2 13, declare success, and move on to the next project. Continuous delivery makes that mindset obsolete.
Db2 13 is not a static piece of software that looks exactly the same several years after installation. IBM continues to add capabilities through function levels and new-function APARs. Indeed, Db2 13 has moved from its initial 2022 function levels through FL509 in 2026.
That means Db2 professionals need an ongoing process for evaluating what is available, what is activated, what applications can exploit, and what provides meaningful value.
So take a look at your environment. You know you're running Db2 13, but how much of Db2 13 are you actually using?
That is a much more interesting question.
