IBM’s zPDT Decision Risks Mid-Tier ISVs and Mainframe Innovation
I’ve been a passionate mainframe (System z) advocate for over 45 years and a staunch supporter of IBM and most of their decisions.
However, when I received an email from IBM on 30 September 2025 announcing, with minimal notice, the discontinuation of the Independent Software Vendors (ISV) zPDT program, I was stunned.
Sitting on the train to London that morning, I opened, read, and then closed the email in disbelief. I simply couldn’t accept what I’d just read.
This is version 3 of the article, and I have struggled with the tone and stance I ultimately wanted to take on this. I shared version 2 with several of the concerned ISVs and with IBM itself. I wanted to give IBM the opportunity to correct any of my musings and provide any additional context around the decision.
I spent an hour on a call with a VP at IBM to discuss the issue, and this article, version 3, contains some of the feedback I received from IBM.
What is zPDT, and Why It’s Essential to the ISV Community
The zPDT is an emulated IBM mainframe environment that runs on standard computing hardware, such as UNIX or Windows servers.
ISVs have relied on zPDT and its predecessors for decades as their primary development, test, and delivery platforms, offering full system control and the flexibility to scale as needed.
Because zPDT operates on comparatively inexpensive hardware, ISVs can avoid the high costs associated with IBM-hosted environments where CPU usage is often metered and long-running jobs or started tasks (STCs) can quickly become prohibitively expensive.
“zPDT delivers the functionality, performance, and autonomy ISVs require, without the substantial financial burden of running on a physical IBM Z system.” – Mark Wilson
In essence, zPDT delivers the functionality, performance, and autonomy ISVs require, without the substantial financial burden of running on a physical IBM Z system.
Why Discontinue Support For zPDT Standalone
IBM Reasoning
Several email exchanges, online meetings, and even a round-table discussion at the recent GS-UK conference took place with IBM. None of these gave myself – nor any ISVs I’d spoken with – a clear understanding of why IBM made this decision, or any indication that they appreciate the profound impact it will have on much of the ISV community.
Some of the reasons IBM had stated are:
- Several ISVs have asked for much simpler, easier-to-manage development environments for their products
- JAVA performance is poor on an emulated solution
- IBM’s desire to give all ISVs a better experience running on real z hardware
Personal Opinion
Having discussed this with IBM, I truly believe IBM has uncovered some misuse of zPDT or even ADCD. IBM was guarded about any details for obvious reasons. My fear with IBM ending support as a reaction to those who want to do something illegally is just that they will find another way, dare I mention Hercules at this point!
It does feel as though some bad actors have really messed this up for those of us who follow the rules and have derived great value from what is a great solution.
Partner Plus Communication
Timing is everything in life, and it’s truly ironic that, the day before the ISV zPDT notification, IBM Partner Plus sent out an email titled: “Our common commitment to ethical conduct” stating:
“Every time you talk to a customer or make a decision, you’re showing what our partnership is all about trust, integrity, and doing things the right way.” – IBM Partner Plus email
I am not sure the communication around the decision IBM has made is in any way in the spirit of partnership for those of us who haven’t done anything wrong.
Vertali Response
From Vertali’s perspective, we rely on zVM and maintain several Sysplex environments to test and support our products. The so-called replacement for zPDT, HDISV, currently does not support z/VM or Sysplex configurations.
IBM has stated that the HDISV solution will have zVM and Sysplex support, and they want to work with the affected ISVs to solve all the issues we, the ISVs, perceive with the proposed HDISV solution. One unconfirmed rumour is that IBM will continue to use zPDT internally and that it’s only been withdrawn for external use — which seems very unfair to me if true!
I contacted a local IBM Business Partner, who estimated that a z16 A02 rack-mounted system would cost more than £350,000 (USD 458,000), and that’s before adding any disk or a backup solution. I will have a very difficult time explaining this to my Financial Director.
“An IBM Business Partner estimated that a z16 A02 rack-mounted system would cost more than £350,000.” — Mark
On-Prem or Cloud
Many of IBM’s clients depend heavily on their partnerships with ISVs, and this decision will inevitably have a negative impact on both.
IBM has stated that it is looking to create a bundled offering for hardware that will significantly reduce the cost of an on-premise solution for those who don’t want to use the HDISV offering.
“A cloud solution is just someone else’s computer!” – Mark
I know several other vendors, such as Vanguard, Trident, Action Software, and many other companies that will want their own on-premise solution, as we all know, a cloud solution is just someone else’s computer!
Security Concerns
There has been considerable email traffic across various forums and zPDT groups, with numerous concerns raised. In my opinion, one of the most serious issues is security. During one of my discussions with IBM, I was advised that we should not store our source code on any of the proposed hosted solutions, and I was assured that the environment is secure.
As someone who regularly conducts security assessments and penetration tests, I can confidently say that I have never encountered a system without vulnerabilities.
“As someone who regularly conducts security assessments and penetration tests, I can confidently say that I have never encountered a system without vulnerabilities.” – Mark Wilson
Even if source code were excluded, ISV binaries could still be reverse-engineered, and with IBM retaining full hardware-level control, they would have the technical capability to potentially copy any volume without the hosted ISVs knowledge.
Data Sovereignty
Another challenge for IBM is that of “Data Sovereignty”. The HDISV is a US-based solution, and for many ISVs outside the USA, this will be an issue when sending system information and dumps, etc., outside of Europe.
IBM doesn’t currently have a European-based solution, though it has some options it’s considering.
I also discussed with IBM the possibility of several ISVs coming together as a group and purchasing a single, larger z processor. Allowing them to share the purchase, maintenance, and running costs (power, people, etc).
Unfortunately, the current zOPD software licence prohibits that. I think this is one IBM could fix quite quickly. It could be a great solution for certain ISVs, who I believe would be quite happy to give IBM the right to come and audit the usage of the solution.
Where Does This Leave Us
I don’t believe IBM fully appreciates the level of disruption this decision will inflict on mid-tier and smaller ISVs, nor the depth of frustration and sense of being let down that so many of them have expressed. This move has already caused a visible erosion of trust across the ISV community.
“zPDT is going away and I don’t believe there is anything the ISV community can do to change that.” – Mark Wilson
zPDT has proven to be a stable, effective, and affordable platform for most ISVs whose businesses depend on it. Removing it is a big blow for many of the ISVs and could undermine the very ecosystem that has supported IBM’s mainframe success for decades.
Proposed Solutions
IBM must step up and provide the solutions that have been discussed:
- HDISV support for zVM
- HDISV support for Sysplex
- Build a European-based HDISV or work with a partner to build it
- Offer affordable, on-premise hardware bundles for those ISVs who don’t want to use — or who don’t trust — a cloud-based solution
- Potentially create a zOPD licence that can be used on z hardware alongside other zOPD licensed users
IBM must mitigate the significant disruption this change will cause to the ISV community, a community that plays a critical role in supporting IBM clients worldwide.
Absolutely agree with you Mark! HDISV does not seem like a good way forward even if solutions are found to the first 3 of your items listed.
Master, wouldn’t migrating from zPDT to zP&D be a cloud implementation for distributing the same ADCD?
– “IBM has stated that the HDISV solution will have zVM and Sysplex support, and they want to work with the affected ISVs to solve all the issues we, the ISVs, perceive with the proposed HDISV solution”
They may have STATED that, but have so far shown no actual interest in doing that.
– “I was advised that we should not store our source code on any of the proposed hosted solutions, and I was assured that the environment is secure.”
Um, ok? It’s secure, but not? Make up your minds…
IBM seems intent on shooting its feet off. There is ZERO chance I can get a real Z, or permission to put our code on some cloud thing. So I guess we abandon the market.
Thanks for your article. Is zD&T same as zpdt?
We completely agree with Mark.
Our concern about IBM’s sudden change of course is absolute.
The process for contracting the ZPD service with IBM was already long and complex, but we all know what a powerful company IBM is.
The expected increase in the cost of maintaining a test environment will be enormous, because it’s not just the cost per use but also the required disk space. In the zPDT environment, the disks were files on the low-cost hardware where they ran; the number of disks was almost irrelevant. Now, IBM will also charge for storage, backups, and data transfer.
The ISV ecosystem has always had a niche in the market for two reasons:
– It provided the client, at any given time, with what IBM couldn’t. Either because IBM wasn’t interested in developing it or because of the delays caused by long development cycles.
– And when IBM did develop it, the ISV made it even simpler, faster, and cheaper.
But it was still very positive for IBM because:
How many times has IBM waited to see what market share some ISV solutions had before deciding which facilities to develop?
In this case, we acted as a testing ground for IBM’s marketing and R&D departments.
Regarding intellectual property:
Throughout our long professional careers, we’ve all experienced contractual incidents with IBM in which IBM is the one breaking the contract. And we had to refrain from taking legal action because the cost of litigation could be several times higher than our annual revenue.
What do I mean by this?
In the on-premises zOPD environment, your software and procedures were protected within your own environment, not even shared in the cloud.
The new environment will be subject to IBM’s willingness not to read or copy it. We probably won’t even find out, but even if we suspect it or have evidence that it’s been copied, will we have to litigate in the USA to protect our rights? IBM knows that the cost would be prohibitive.
And if we have to set up an on-premises zSeries environment, the development cost will be prohibitive for small businesses.
In three or four years, only those companies with sufficient hardware infrastructure will remain in the ecosystem, and even then, only if IBM decides to qualify them as clients.
I’m usually optimistic, but this time I’m finding it difficult.
Nearly 2 decades ago IBM yanked Flex-ES away from the ISVs with no alternative except “get a real mainframe”. Eventually IBM did onboard ISVs to RDP with a heavy discount and after 18 months released the zPDT. This just feels like history on repeat, except there is no light at the end of the tunnel of a successor to the zPDT.
IBM’s recent actions in the mainframe market raise significant concerns regarding their impact on customers and independent software vendors (ISVs). These measures appear to create substantial barriers for vendors and increase operational costs for ISVs, which could limit competition and innovation within the ecosystem.
Given IBM’s dominant position in the z hardware market and its considerable influence over the z software space, such strategies warrant careful evaluation. Stakeholders should assess whether these practices align with principles of fair competition and consider the potential regulatory implications.
Vanguard has been a committed participant in the mainframe ecosystem for decades and as an ISV, we have actively supported and developed innovative solutions for the IBMz Series. We’ve seen similar situations arise in the past where the vendor community was asked to adapt quickly to hardware changes, which can be quite challenging.
Previously, the discontinuation of virtual solutions for development compelled us to invest in IBM hardware, only for a more cost-effective option to later reappear in the ISV Marketplace. This cycle can be frustrating for many ISVs.
As highlighted in the IBM Partner Plus email, “Every time you talk to a customer or make a decision, you’re showing what our partnership is all about: trust, integrity, and doing things the right way.” We believe that fostering this sense of trust is crucial, especially when significant changes arise.
In line with this, we must emphasize the importance of security in our partnership. We all understand that we should never compromise on protecting our source code, as it is the foundation of our innovations and trustworthiness.
We also believe that a collaborative approach could greatly benefit the ISV community. For instance, the possibility of several ISVs coming together to purchase a single, larger z processor could allow them to share costs related to the purchase, maintenance, and operation (including power, personnel, and related expenses).
We would greatly appreciate clearer communication regarding these changes, including the rationale behind their decisions. The sudden nature of these announcements, coupled with the lack of advanced notice, leaves many of us to be concerned about the implications for smaller organizations. We hope that future discussions will foster an environment of collaboration and transparency, ensuring that the vibrant ecosystem we’ve built remains strong and inclusive with client focused offerings.
The latest word from IBM is that HDISV will not in fact support the use of zVM or Sysplex and to get those functions ISVs will instead need to use zRDP. With a simple 2 system sysplex requiring zVM and 4 guests, the zRDP metered approach for resource usage is going to be cost prohibitive for many ISVs.
IBM also walked back their support for site to site VPNs into the HDISV solution. Instead, they are “exploring” a certificate based way of accessing the environment. No word on when that might come to fruition.
There are simply too many open switches in what increasingly looks like a solution that was not entirely thought out before it was forced upon the ISVs.
https://www.ibm.com/docs/en/test-accelerator-for-z/2.x?topic=demand-environments
@Rod IBM Test Accelerator for Z has some significant gaps when compared to zPDT. Many ISVs using zPDT have already voiced it is not a useful replacement for the processes they support now with zPDT.
Mark, have IBM also pulled the IBM Developer for z Development and Test Environment? https://www.ibm.com/products/z-development-test-environment.
It is the commercial version of zPDT, wrapped up for customers instead of ISVs.
While at IBM, I was the System z leader of Application Development marketing. While ISV’s had zPDT to reduce their costs, large financial institutions could buy dev tools, but had to use “production mips” for test with major subsystems. We estimated it would cost a financial firm $200-300,000 per user. IBM was very concerned about production workloads on z emulators. When I brought this business proposal for development only, I received permission to have the Rational brand imbed the zPDT in their offerings for a price that was pretty close to Windows development costs. Roughly $12,000 per user.
Could this be a better approach than HDISV? While there is a cost, it includes the ADCD, which is kept up to date for commercial purposes.