Private equity acquisitions that touch custom IBM i software follow a predictable pattern. The financial model looks clean, and the consolidation thesis is sound. Then the integration team discovers that the operational logic of a 30-year-old custom RPG application does not map to SAP. Three years of consulting spend later, the conclusion is the same: it will not fit.
Custom IBM i software built over decades encodes the specific operational logic of one business. It does not always map to the generalized workflows that enterprise platforms are designed to support. Private equity consolidations that try to replace these environments with SAP or similar platforms often succeed financially but fail operationally. The safest decision a deal team can make is a genuine code-level assessment before committing to any platform.
Acquirers Consistently Underestimate Custom IBM i Environments
The mistake is not malice or a simple disregard for custom software. It is a failure to look under the hood before closing the deal.
Private equity firms excel at financial modeling and market positioning. They do not always excel at understanding what a custom RPG application has been quietly doing for 30 years.
When a business builds its operational logic directly into IBM i software over decades, that logic does not announce itself. You won't find it searching through a specification document that outlines what it does. You can only discover the value of these software tools in the code. It lives in the job scheduler, in the data structures, in the sequence of routines that nobody fully documented.
The operational intelligence is embedded, and the only way to discover it is to run the system. By the time most acquirers recognize this, they have already committed to the migration.
The Reality of a Three-Year SAP Consolidation
A private equity firm acquired a company in the electronics industry. The acquired business had a unique manufacturing process and a custom IBM i application built specifically around that process. The acquirer already owned SAP licenses and saw a straightforward consolidation opportunity: six acquired companies, one enterprise platform, compressed overhead.
Bob Losey has spent his career inside IBM midrange environments, founding Source Data Products in 1979 after six years at IBM. Across more than four decades of engagements, He's watched platform decisions unfold that enterprise consultants consistently get wrong.
"The private equity company thought we can just compress these six companies that we acquired into the SAP software that we already owned. And after about three years, they finally said it won't fit ever. We have to keep this company separate. We can make the general ledger work, but we can't make the operations work." – Bob Losey, Founder and President, Source Data Products
That's three years of significant consulting spend. The conclusion was that the custom environment could not be replaced.
That is a predictable outcome for anyone who understands how custom IBM i applications encode the way a specific business runs. I touched on related issues in a post about why new system implementations fail.
What Gets Underestimated in Every IBM i Acquisition
The value of custom software is invisible until someone tries to replicate it. Off-the-shelf distribution or manufacturing packages are designed around how most businesses in an industry operate. A company that has been refining its own software since the late 1970s has built something around how it specifically operates. That includes all the edge cases, workarounds, and judgment calls that accumulated over decades of real production use.
Consider a small distribution company running a solid 20-year-old IBM i system that evaluated alternatives. The prominent Windows-based platforms it reviewed came in at $200,000 to $300,000 in licensing alone. Implementation estimates stretched from one to three years. All-in projections landed somewhere between $500,000 and several million dollars.
For a 14-person operation whose people make daily commodity trading decisions based on judgment rather than software-generated trend analysis, that spend was impossible to justify. The existing system worked, and replacing it cost far more than the software. The business also had to consider operational disruption, retraining costs, and the years-long productivity drag.
Most organizations calculate the license fee and stop there. They do not account for what IBM i software competitive advantages have already been built into the existing environment.
Not sure whether your IBM i environment is a migration candidate or a platform worth preserving? Talk to the Source Data team before any commitments narrow your options.
Performing Due Diligence on IBM i Custom Software
If you hold an acquisition role or advise on platform consolidation, whether you can technically migrate is secondary. You need to look at what the software does and what you might lose with the transition to the replacement platform.
Finding those answers will require someone who can read the code. You're not just evaluating it from a business requirements document, but actually reading it to see what it does.
Source Data's team has encountered IBM i applications with 85-page RPG day-end routines running logic that no one at the client organization could fully explain. The team has diagnosed general ledger failures on systems running V4R3 that no other resource could resolve. We've moved environments from V5R3 directly to V7.5, skipping intermediate versions.
A related risk that acquirers frequently overlook is what happens when IBM equipment transitions from active IBM maintenance to extended hardware maintenance. IBM outsources technical support to independent engineers who do not receive IBM's proprietary tools for relinking system boards to serial numbers. If a system board fails under extended maintenance, the system may be unrecoverable. Deal teams that treat software as a line item and hardware as a commodity learn this the hard way.
We touched on this issue in a post about the hidden risk of IBM extended hardware support. It is one of the most concrete liabilities in any acquisition that involves aging on-premise IBM i infrastructure.
The Cloud Hosting Alternative for IBM i
Not every acquired IBM i environment needs to migrate off the platform. Some need to be stabilized, right-sized, and maintained in a form that does not require on-premise hardware commitments.
Cloud hosting through a platform like Cloud400 moves the environment off aging hardware and into a maintained, disaster-recovery-capable infrastructure without touching the application layer. The custom logic stays intact, and the hardware risk disappears. The operational continuity the acquirer was trying to preserve through the SAP consolidation is actually preserved, at a fraction of the cost.
For mid-market IBM i environments, cloud hosting often produces 30 to 70 percent savings compared to on-premise hardware renewal, with no loss of application functionality. That is a different calculation than the one most integration teams are running.
The IBM i total cost of ownership analysis has shifted significantly since IBM eliminated perpetual software licensing. Organizations that have not revisited those numbers recently are working from an outdated picture.
Common Questions About Private Equity Evaluating IBM i Software in Acquisitions
Can enterprise platforms like SAP replace a custom IBM i application?
There are many cases where these software platforms cannot replace custom IBM i applications. Enterprise platforms are designed around common industry workflows. A custom IBM i application built over decades encodes the specific operational logic of one business. Consolidation attempts often succeed on the financial reporting side but fail on the operational side, where the business actually runs.
How long does a failed IBM i platform consolidation typically take before organizations reverse course?
Multi-year efforts are common. Organizations might spend two to four years on these projects before concluding the migration cannot deliver the required operational functionality. The earlier a genuine technical assessment happens, the shorter that window tends to be.
What makes custom RPG applications so difficult to document or replace?
Custom RPG applications accumulate logic through incremental modifications over time. Developers who wrote critical routines often retired without transferring knowledge. The result is operational intelligence that exists only in the running system and is only fully understood by reading the code directly. A business requirements interview does not surface it.
Is cloud hosting a viable alternative to migrating off a custom IBM i application?
Yes, in many situations. Moving an IBM i environment to a hosted platform like Cloud400 reduces aging-hardware risk and provides disaster recovery capability. It can also preserve the custom application layer without requiring migration to a new platform. For mid-market environments, it also frequently reduces total infrastructure costs by 30 to 70 percent compared to on-premise hardware renewal.
What should an M&A due diligence team look for in an IBM i environment?
Due diligence should include a review of the application code itself, not just a business requirements interview. Key areas include the complexity of day-end and batch routines, the codebase's age and documentation status, and the current OS version. It is also important to know whether institutional knowledge of the system has left the organization, and the hardware maintenance status of any on-premise equipment.
What is the realistic cost range for replacing a mid-market IBM i application?
Costs vary based on application complexity and replacement platform. Licensing for prominent Windows-based alternatives in the mid-market commonly ranges from $200,000 to $300,000. Total project costs, including implementation, training, and productivity loss, sometimes reach $500,000 to several million dollars. Those figures do not account for operational disruption or the risk of replicating logic the replacement platform cannot handle.
When is the right time to start an IBM i assessment before an acquisition or integration project?
Earlier than most organizations initiate the conversation. A company with two years before a planned transition has meaningful options around hosting, right-sizing, upgrade paths, and genuine migration feasibility. A company 90 days into a post-acquisition integration has very few. The assessment does not have to be exhaustive to be useful. Even a code-level review of the highest-risk routines changes the quality of the decisions that follow.
Start the Assessment Before the Decisions Are Already Made
The earlier an IBM i environment gets an honest technical review, the more options remain on the table. Source Data provides assessments without obligation. When the numbers do not favor a move, that is the answer you get.
Is your organization approaching a hardware refresh, a data center consolidation, or an acquisition that touches IBM i infrastructure? Connect with the Source Data team before commitments narrow your options.
