It's what would be cool and would look good on my resume. (Only half /s)

Nailed it ^^^

Over my 30 years, mostly in Fortune 250's, I've seen 3 mainframe migrations fail. If you're part of the team, the trick is to get another job before people realize -- in year 4 of your "5-year" migration -- that it was never going to work, because managers in other parts of the business will never allow their headcount to be reduced by better IT workflows.

Having worked adjacent to some of these kinds of projects, can't upvote this enough. Not to mention that business doesn't take the suggested 1-2 years to simply document and define test cases for the old/new system to ensure such a new system works, and simply start working on the new system based on what the business/da types drew up. Missing literally tens of thousands of legal edge cases defined in the legacy codebase.

Some people just like to see the world burn. Move fast, break things. Like my bank, ATM, pharmacy, shipping mgmt, hospitals, paycheck services, utility grids...

And then in 5 years someone can rewrite it all again because something else will be cooler and my code will be technical debt.

People may assume that a lot of this mainframe software is "running just fine" but nothing could be farther from the truth. Often you will find that this software was fine when it was written 40-50 years ago, but now it has a lot of deferred maintenance and upgrades which are now a "big problem". Is it a problem that an application that can move millions of dollars is only secured by a strictly 8 character alphanumeric password? You be the judge.

Certainly. A good reason for a migration is that we are in a place where we need to do something major--whether that's modernizing the software on the mainframe that isn't doing the job, moving everything to new platform(s) (including potentially cloud), or some combination of the two--the latter being a pretty common strategy these days. At that point, just adding more duct tape is probably the wrong approach, at least in the medium to long term.

Updating the software to support stronger passwords or rewrite it from scratch, on a totally different platform?

I don’t think you’re making argument think you’re making.

You have no idea. This is not some database field that you can just alter with one statement and update a field on a screen. Things like this get hardcoded into hundreds of thousands of lines of assembler and cobol and need to be changed and tested everywhere. With no automated testing or other tools to mitigate the risk. It is an absolute nightmare. And 5 or 10 years from now it will be way worse because working on a mainframe is a deadend career and very few people are learning it.

I’m not saying it’ll be easy. But what’s even harder is rewriting 50 year old software, with all the bugs that others relay on now (both people and software), wanky and complex business logic, etc, etc.

I’m not saying that you should stick to mainframe. But rewriting it because you need to support strong password is not a reason to do it.

Well, for one, lack of capable personnel. Nobody learns IBM Mainframes in school, and most jobs for them want experience. Furthermore, they're not sexy but boring, with paywalled docs and similar shitty "enterprise" techniques, making it so very few people actually want to or manage to learn them. And it's a dead end, career-wise (very few companies use them, so changing jobs isn't as easy as more widely used tech).

So what will happen when in 10 years the last people you have that know how it works are retired?

Not to mention tech debt.

Completely untrue. Listen to everything Cameron Seay has ever said about the subject. Mainframe programmers are wanted more than ever.

https://www.youtube.com/watch?v=hxxyORcU3Hs https://blog.share.org/Article/mainframe-visibility-ibm-cham...

Which part is untrue? That there isn't enough personnel or that it's a severely limiting career choice? Because what you're saying confirms the first one, and for the second one, not a lot of people dream of working on legacy stuff in a big organisation, and those are your only choices if you're a mainframe programmer. Say in the US, for mainframe work, there are what, 30 banks? 5 airlines? 20 insurance companies? Not a lot of choice, and it's doubtful they'll offer "perks" such as remote work.

Lots of government too. I worked at a government agency that ran it’s business off of mainframe. I worked there as a web developer and we had to consume data from the mainframe in our web apps. Very tedious process.

Yeah, forgot governments, so we can add one more to the list of 'nobody dreams working there as a tech person' list.

Yeah, the hiring process is often 6+ months long for half the pay of private sector jobs, and 1/5 the pay of the consulting companies they bring in to do the bulk of the work anyway.

They are super wanted but it's true that it's very hard to get into.

Want to learn Windows, Linux, cloud whatever? Just build a cheap home lab and play to your heart's content. Because really, training is not how you get good. Nor is certification. It's the hands on experience that comes from running into the crap the vendor doesn't want to tell you. All the little annoying flaws they keep out of the documentation under pressure from marketing.

Good luck doing that with a system Z. Try to find one on eBay for peanuts the way you can get a nice ESXi server.