Home/Application analysis
z/OS application analysis and migration assessment
Open-ended and calculable: what does an application really consume, what does it depend on, and how much cost genuinely disappears if it leaves?
The opening question
“Migration” is not one decision but four
Every application has several sensible paths. Which one applies depends on two quantities that can be measured — and that most sites do not have to hand.
Retain
Stay and modernise: open up interfaces, renew development processes, reduce consumption in a targeted way.
Rehost
Lift and shift onto another platform. Fast, but the technical debt moves with it.
Refactor
Automated conversion plus manual work. Realistic conversion rates are well below 100 %.
Replace / retire
Standard software or decommissioning. Regularly underestimated and often the most economical lever.
The two quantities that carry the decision: measured resource consumption and dependency structure. Without the first the business case cannot be calculated; without the second the migration cut cannot be defined.
The core
Share of load is not share of cost
The intuitive approach — “this application accounts for 15 % of CPU work, so we save 15 % of cost” — is simply wrong under classic sub-capacity pricing.
What matters is not volume but the contribution to the monthly peak. And once an application is removed, another load often sets the new peak: the effect saturates, it is non-linear. That is why we calculate iteratively, not additively.
- Build a consumption time series per application at interval granularity
- Subtract the candidate from the partition's time series
- Recalculate the rolling 4-hour average and the monthly peak per machine
- Account for peak shifting and iterate across multiple candidates
- Check second-round effects: processor utilisation, third-party licences, possible model reduction
Attribution
How consumption is attributed to an application at all
Analysing only the address space view attributes all database load to the database system — instead of the applications that cause it. That is a common and consequential error.
Application model in the policy
The methodically clean route: model the applications in the classification rules. Consumption per application is then available continuously — no retrospective reconstruction. The effort is small and steering is not affected.
A view into the subsystems
Transaction monitors and databases provide consumption per transaction and per access path. Only then does load land with the causing application rather than the subsystem.
The unattributable share
The sum of application-level CPU time is systematically lower than the partition's total consumption. A chargeback model must define how that overhead is allocated — otherwise nothing adds up to 100 %.
The best-documented cautionary case
At a British bank in 2018 the data migration succeeded technically — and the new platform then failed under production load. Five million customers were affected, more than 225,000 formal complaints followed, and the regulator imposed a fine of £48 million, on top of roughly £33 million in customer redress.
The lesson is not a warning against migration but against inadequate capacity and load validation. That part can be calculated beforehand.
A valid outcome too
Sometimes the answer is: stay and modernise
We are not here to justify a predetermined outcome. If the numbers favour staying on z/OS, we say so — and show the modernisation path that then makes sense.
- Open up interfaces — expose existing applications as modern services without touching the core
- Selective refactoring instead of wholesale conversion, prioritised by consumption and change frequency
- Offload to specialty engines — realistically assessed: the calculation only works with sufficient capacity
- Retire first — unused programs and jobs cost maintenance, testing and CPU time
FAQ
Questions about the migration assessment
Our applications are not modelled in the policy. Is it still possible?
Yes. We reconstruct attribution from naming patterns, service classes and the subsystem view and build virtual applications from them — including a note where a class is assigned to several applications and double counting occurs. In parallel we recommend anchoring the model permanently in the classification rules so that attribution no longer needs reconstruction.
Do you also cost the target platform?
We deliver the current-state side: measured consumption, load profile, dependencies and the platform cost that genuinely disappears. Target platform costing belongs to the respective target architecture project — our figures are its input.
Why don't you quote success rates for mainframe migrations?
Because the widely circulated figures cannot be traced to a primary source. We prefer to argue with verifiable mechanisms and documented individual cases. That is more robust than a catchy percentage.
How does this relate to the cost analysis?
Closely. The migration assessment uses the same data basis and the same time series logic as the performance and cost analysis. Commissioned together, the data preparation effort occurs only once.
Measure before you decide.
We will show you what your current data already allows you to conclude.