Mainframe modernization: four routes, and what they really cost
A mainframe is rarely replaced because it is broken. It is replaced because nobody left knows it, or because an integration with the rest of the estate can no longer be built. That difference decides which route fits.
Four ways, priced in risk
They are often presented as a ladder where the last rung is best. They are not: in the right place all four are the right answer.
- Leave it and open it upThe system stays and gets a modern interface beside it so the rest of the estate can reach it. The cheapest route and often the wisest when the system does what it should and simply cannot be reached.
- Rehost without rewritingSame application, different layer underneath — emulation or an environment at a provider. Risk is low because the logic does not change; what you solve is the hardware and the skills under it, not the readability of the code.
- RebuildBuild the functionality again on a modern stack. The most expensive, the longest, and the only one that genuinely clears out the original complexity. Defensible only when someone can explain what the old system does — which is precisely the problem that started the programme.
- Replace with a packageIf the process is not unique: standard software instead of bespoke. The largest saving over time and the largest collision in the short term, because the process has to bend to the package rather than the other way round.
What we do in this, and what we do not
We are not an application builder and we do not pretend to be. This is where we add value in such a programme.
The environment around it
Network, storage, integrations, backup and the new platform layer. That work exists on every route, and it is the part that delays an application programme when it is not ready.
People to carry the programme
Network, cloud and systems engineers through staffing, for the period when two environments run side by side. That is the phase in which a team is structurally too small.
What we do not do
Rewrite the application, unpick the business logic or take on a code migration. There are firms that do nothing else; we would rather say that at the start than halfway through.
Further reading
What this connects to.
Questions we get about this
The ones that come up most, answered briefly.
Do you carry out the application migration yourselves?
No. We do the environment around it — network, storage, integrations, backup and the new platform layer — and we supply people for the period when two environments run side by side. Rewriting the application belongs with firms that do nothing else.
Is leaving it in place a serious option?
Often the wisest one. If the system does what it should and the problem is that the rest of the estate cannot reach it, a modern interface beside it is cheaper and far less risky than rebuilding.
Which route fits this system?
Tell us what runs, who knows it and where it pinches. We say which of the four routes we would take and which part of it belongs with us.
Practical IT knowledge in your inbox
New guides on management, security and the workplace, written by the people doing the work. No sales talk, and you can unsubscribe in one click.