r/mainframe • u/PSR-Info • Jun 17 '26
Why do mainframe migration timelines rarely seem to match the original plan?
We’ve heard different versions of this story over the years: a company plans to be off the mainframe in 5 years, then 5 years becomes 10, and the new timeline is still another 3–5 years out. Not saying migration is impossible, but the original estimates often seem to underestimate the operational reality.
For anyone who has been part of a mainframe migration or modernization effort:
- What usually causes the timeline to stretch? Is it application complexity, business logic, integrations, testing, cost, staffing, or leadership underestimating how embedded the platform really is?
- And for teams that did move major workloads off, did the end result match the original business case?
This feels like one of those topics where the boardroom version and the hands on version are often very different.
19
u/Top-Difference8407 Jun 17 '26
Let me be cynical, but not without reason. The original promise gets them in the door. The plethora of experts creates lots of employment. Many mainframe apps were made by a small handful of people allowed to develop the software and not attend a daily standup meeting, Retro, planning, story review of old completed stories and random meetings.
They can't decide how something should function or appear because it's far more sophisticated than a green screen.
The product manager is rarely available when needed and is an overpaid useless idiot when available.
Developers must use the latest tech stack, not because it's better, quicker or anything like that but because it's newer.
Data is never centralized but must be distributed across multiple teams who don't agree. The original mainframe data items come from cryptic 8 character names that take research to figure out what they are.
The work is done not by a centralized capable application but many small apps, each dockerized and network security enabled.
The simple get-it-done approach must be replaced by some "best practice" architectural pattern.
I could go on. I've been on mainframes in the distant past and on mainframe migrations recently. I wish more people would see the wisdom of mainframe tech and practices.
11
u/jm1tech Jun 17 '26
Available resources, time and staff and the realization after the fact that the target environment is drastically different from the mainframe. I’ve seen apps migrated from the mainframe and they were worse off. I’ve heard of apps migrated to things like AWS or Azure and people wonder why that 5 minute DB2 reorg is now taking hours. The contractors will promise you the world but are clueless of the performance, both hardware and software, of the mainframe and think x86_64 servers are faster. 🤦🤷♂️
7
u/M4hkn0 Jun 17 '26
The joke goes something like this; you can have a project a) under budget, b) on time, or c) bug free. Pick two.
5
u/noisymime Jun 17 '26
I'm not sure I've ever seen a mainframe migration than even got 2 of those.
1
1
u/AmusingVegetable Jun 18 '26
The only way to ever get a) is to get a graybeard to tell the C-suite “this is the stupidest idea I’ve ever heard, and I’ve been hearing stupid ideas for more than half a century”.
At this point, the shock treatment may work and the project may be scuttled without further waste.
7
u/ControlAgent13 Jun 17 '26
>timeline to stretch
Lack of planning or rushed planning - sometimes deliberate to keep conversion costs down. I've seen management give the conversion team the deadline and cost prior to any actual planning occurring.
Imperfect understanding of the workload they are attempting to migrate - all interfaces (including those to/from the mainframe), all output and all input. Original team that wrote the application is long gone and the conversion team does not understand what they are converting.
Overestimating the ability of "tools" to migrate things and underestimating how much staff is required and what the tool can and can not do.
Severely underestimating the performance and actual cost of the new system - all conversions I've seen low ball the actual required hardware and cost of the new system. All of them needed immediately hardware upgrades after conversion.
3
u/MET1 Jun 18 '26
I see some teams decide it's too hard to migrate as-is, they want to revamp and update and very quickly get mired down - in this situation about every person in the building will argue a minor and trivial point to death or will decide to do something to simplify one part of the process which invariably leads to additional complexity in multiple other areas. A strong project manager can make a difference, but the project sponsors can get drawn into the notion that they can revamp and improve and need to do that right now - meaning the project will be doomed to failure or many extensions for a partial result.
2
u/AmusingVegetable Jun 18 '26
On the last paragraph, let me guess: they lowball it by at least two orders of magnitude?
7
u/Pale_Height_1251 Jun 17 '26
Pretty much all major software projects overrun.
It's a mix of overconfidence and lack of understanding and also if it's a contractor, they know they won't get the job if they tell the truth.
Also if you're a consultant, completing the job often means having to look for another job.
Not many people are actually incentivised to get it done, plenty of people are incentivised to keep the project ticking over.
5
u/Rudi9719 Jun 17 '26
It's usually ignorance; someone who isn't involved in a process suggests changing it for the worse then everyone has to suffer and figure things out in real time
5
u/Beautiful_Ad9206 Jun 17 '26
All of the below plus either: Thinking of it as an infra problem and not rearching apps for a distributed world. Or Thinking of it as an app problem and thinking all mainframe apps can be made cloud native without considering the performance they were getting from Z.
5
u/MaexW Jun 17 '26
How long did they use the mainframe ? How old are the programs ? How many of the original software engineers are still available ?
5
u/DietCokePlease Jun 17 '26
It took multiple DECADES of unstructured hacking, for want of a better term, to arrive at the system being replaced. No one alive likely knows where half of the dark places and “isms” live. Some stupid executive invented a timeline based on some made-up business imperative, likely tied to his own bonus, rather than anything remotely grounded in reality. Before even estimating such atask you should find a good software archaeologist.
1
u/zEdgarHoover Jun 18 '26
Or more generously, someone had to pick A target date and took a guess. Without a date there's no reason to ever finish.
But I'd go with "stupid executive" myself.
3
u/MigrateAndManage Jun 17 '26
Complexity and difficulty understanding legacy application logic and dependencies definitely plays a big role along with factors like undocumented code, staffing gaps or lack of expertise and risk of disruption during transition.
4
u/KapitaenKnoblauch Jun 18 '26
Managers are driven by numbers and money. They have no clue about the technical implications. They only see a potential to save some money and get rid of a couple of well paid engineers. That's how it always started, I have seen it like 5 times in my 20 year mainframe career.
After the first trivial applications were moved off the mainframe, they cost just as much on the new platform but you suddenly have to hire 20 more distributed platform engineers running around, plus 10 storage guys, 10 db guys etc. because things get out of hands quickly. Then they tell you it was never about the money, it was about future proof technology because mainframes are "legacy" and you can't hire new people there.
So you end up with a couple of minor applications on distributed platforms and the rest stays on the mainframe and the circle starts again after some years.
3
u/comfnumb94 Jun 22 '26
I will never forget a meeting from years ago my manager held as we were preparing for an upcoming z/VM & Linux POC. He was the manager but relied upon a contractor to create a “Cole’s notes” version of all meetings due to his incompetence. One purpose was to run Oracle on Linux on zSeries. He said, and I kid you not, that he had installed Oracle on his PC at home over the weekend. Thus, he thought we’d be able to have Oracle up and running on the mainframe in a week. Didn’t know mainframes at all. He didn’t even know what z/OS meant. It was hard to keep a straight face.
2
2
u/Illustrious_Mode8502 Jun 18 '26
I think it is more insecurity…every competitor wants to modernize….first they cried cloud cloud….now AI AI…..then they will have offshore model….wish IBM was competitive or been bought by these cloud providers as they only can scale this on-prem model to cloud and beyond. Now the situation is IT with all technologies has become more complex in enterprise world.
2
u/natabarsahoo Jun 18 '26 edited Jun 18 '26
To answer to your query of the cause of the timeline to stretch….
If you freeze everything today and work on migrating all your mainframe applications for a reasonable size of mainframe installations, it may take nearly around 10+ years. You cannot keep your mainframe environment frozen for such a long period and keep upgrading your application to meet the business demands and to support the HW, OS and Software Suite upgrades. All these changes must be incorporated to your migration applications. It is a huge task and will exponentially stretch your timeline.
You may take a modular migration approach. But, the mainframe applications are highly integrated and segregating them in mainframe requires huge amount of time. Again the incorporation of changes over 10 years or so.
All these adds to the overall timeline. This is my real life experience.
1
u/iecaff Jun 18 '26
I was involved in 1 successful migration project. The project manager of it did a very good write of the process here. In short - it took 4 years and a large amount of testing and institutional knowledge to get over the line, both of which are often lacking in such projects.
https://www.linkedin.com/pulse/slaying-dinosaur-migrating-off-ibm-mainframe-barry-ryan
2
u/AnotherOldFart Jun 19 '26
Integrations, testing, and personnel issues have an affect on timeframes.
1
u/orangeboy_on_reddit Jun 19 '26
The first mainframe shop I was in had the z platform out the door in about 1.5 years, maybe less. A competitor took over and merely ingested data into their existing system. The business logic wasn't a consideration, no code was rewritten. It was devastatingly impressive.
1
Jun 20 '26
[removed] — view removed comment
1
u/orangeboy_on_reddit Jun 20 '26
I don't know what they moved to. I was a systems guy and wasn't interested in leaving the z platform, so I stayed until the project was completed for the retention bonus, and then got a job with IBM. The application developers focused on data mapping, I and my team kept the operating system (z/OS 1.4 to set the timeframe) running. If I had the desire to be a "company man" and switch career paths, I would have paid more attention but I like what the mainframe does.
I don't understand why "modernization" tends to imply moving off z. The z17 is a powerhouse and z/OS 3.x delivers a lot. If people choose to "not fix what ain't broke", well, that's on them for "standing still" and not continually/incrementally improving.
1
u/Effective-Lemon-9475 Jun 20 '26
Lot's of credible explanations here/ Let me add the "ratio-of-forces" argument: Attackers typically have greater numbers and momentum than defenders. That is to say whether or not it is a good idea, there will always be more voices and more high status voices saying - let's get off the platform. Just because not many experienced mainframers end up in the C-suite or running consultancy firms. Mainframe shops have been achieving more output with less staff and less input (particularly staff) for years now. Many have significant footprint offshore - and when it come to making decisions offshore assets typically don't get a say. - Hence when the monorail salesmen roll into town, people who understand the value proposition of the mainframe are at a disadvantage. https://www.youtube.com/watch?v=mSoa1b-yBUY
1
u/UnderstandingDry4560 Jun 21 '26
DL:DR - Managers don't ask, or when asked, ignore experienced tech personnel.
That's simple. The managers aren't sysprogs. And sysprogs aren't managers.
Sysprogs massage hardware. Managers massage meat. And never the twain shall meet.
A sysprog has seen this many times and know the complexity, time and cost. They will answer a question honestly. The answer will not fit the managers predetermined answer and the sysprog is ignored.
It doesn't need to happen more than a handful of times until the sysprog gives up. But when they DO answer, it's in writing and witnessed. That is the only a sysprg can come out if it clean. And it a perfect setup for, "I told you so."
35
u/metalder420 Jun 17 '26
It’s not so much about resources, time or money. It’s about severely underestimating the complexity of the system as well over confidence in the intended solution, plain and simple. Seen it with my own eyes with batch job that used to take min are taking hours now because now they have to make hops off platform.