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 %.
Application view
What CICS, Db2 and MQ reveal about an application
The partition view tells you what an application costs. The subsystem view tells you what it consists of and what it depends on — measured from live operation rather than estimated from source code. Shown here are CICS, Db2 and MQ; the same approach applies to IMS and WebSphere.
From the transaction monitor
- Program view instead of transaction ID — which programs run how often, at what CPU time per call. The measured bill of materials for the application.
- Request counts per transaction — file, database and messaging calls. A transaction issuing a four-digit number of database calls is a first-order migration risk: on a distributed target platform every unit of network latency is multiplied by that number.
- Coupling between regions — traffic between regions shows which parts of the application actually belong together and where a cut becomes expensive.
- Access channels — how much load arrives through classic screens and how much through sockets and services. A direct indicator of how well a part can be encapsulated.
- Region-bound state — temporary storage, counters and locks tie transactions to a particular region. Those bindings already prevent distribution today — and they will prevent it again on any target platform.
From the database
- Consumption per application, not per subsystem — evaluating only the address space attributes the entire database load to the database rather than to the applications causing it.
- Access profile — read versus write load, share of sequential access, commit behaviour. That says more about portability than any line count in the code.
- Object coupling under data sharing — which objects are of interest to more than one member. Those are the seams where separation becomes costly.
- Lock contention between applications — it reveals functional coupling that is invisible in the source code because it only emerges at runtime.
- Share on speciality engines — how much of the database load is offloaded today. This share changes the cost that actually disappears considerably, and business cases routinely overlook it.
From messaging
- The system boundaries that actually exist — every queue is a measured interface between two parts of the application. No architecture diagram is as current as this list.
- Who puts, who gets — the direction of traffic shows which part is the client and which the server. That decides which side can move first.
- Persistent or not — persistent messages mean logging, recoverability and hard commitments. They are the most expensive part of a migration and the most frequently underestimated.
- Traffic leaving the system — whatever goes out over channels depends on a partner that is not moving with you. Those connections shape the schedule.
- Message sizes and peaks — throughput alone says little. Only size and distribution over time show what bandwidth and what buffering a target platform needs.
The subsystem view does not replace source code analysis. It is the cross-check: what is coupled in the code need not be expensive at runtime — and what is expensive at runtime is rarely visible in the code.
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.