I don't know of any case where a mainframe couldn't, in principle, be replaced by a server farm. However, maintaining a sufficiently reliable and secure server farm is a specialist job too so the benefits aren't always clear cut.
Ease of migration is really down to what the mainframe is doing and for how long. In practice, they tend to be in place for a number of years in hub-type roles e.g. general ledgers, payment systems. That sort of thing. The effect is that extricating them is extremely complex and expensive.
However, these issues aren't really limited to mainframes. We have the same problems with trying to extricate Sparc Solaris applications. We generally want to replace them with Lintel as we use them in most applications. But doing so is horribly complicated as they're embedded in byzantine flows that few understand and the systems often assume a level of hardware reliability that commodity boxes don't have.
You could replace these things with something newer but the concerns by various parties can outweigh the willingness to fight and you probably don't want to be on the receiving end of "I told you so".
Oh god, no, don't even think about it. It's hard enough migrating away from a code base in Java, written 10 years ago and that runs on pretty much anything. Imagine how hard it is to migrate from a code base written in languages known best by engineers in retirement, that only runs on extremely expensive supercomputers made by almost a single company (IBM).
But the worse thing is that you can't just pull the guts out of the software that runs all the transactions of huge financial organisations. You can't just throw a switch and stop all financial activity in a big bank, while you swap a new system in place, because every second of downtime costs millions. Millions! Who is going to take the responsibility for that?
So change never happens because nobody dares make it. One day mainframes will outlive the last people who can program them competently and then we'll all be in trouble.
It's been done. Design and implement a replacement system, run it in parallel for a meaningful timeframe, then switch over. You need a parallel implementation simply as a "hot backup" in case your primary system fails for whatever reason anyway, and it's easier to implement real-time redundancy in current systems anyway. (This was the niche that Tandem Computers served.)
I think most mainframes in the USA are used to run old legacy systems that will be needed not much longer (or that's the plan, anyway), like shop-order control for old weapons systems -- tasks for which no replacement system would be necessary because the need ends with the project.
I guess we 've worked in the same place then :)
Mainframes have backup built-in already, and then they're also ran in twos with one as further backup. The amount of redundancy built in those systems is just insane and quite unmatched by anything in the "distributed" world.
So for example where I work(ed) the mainframe network is touted as having 99,999% uptime. In my time there, there was an "outage" that affected the whole business quite severely... and it was on a distributed (not a mainframe) server. I don't think anyone remembers the mainframes ever having failed for good.
They're just beasts. There's solid reasons to use them the way they're used. The fact that they're a bit archaic... well, to be fair so is Linux. So what? If it works, it works.
I worked at a place operating a Unisys mainframe running code written mostly from 1972 through 1985. That "mainframe" is probably a 4U Xeon with an emulator running on it. There have been active projects (and easily a billion spent) to replace that mainframe since at least 1996.
Remember that mainframe systems mostly automated totally manual tasks, so businesses were literally built around them. The use cases left are mostly core applications like general ledgers, rules engines for big complicated processes, etc. They work pretty well, and most of the modernization budgets get spent replacing supplemental systems running Solaris, Windows, etc that are aging less gracefully than the mainframe.
I wonder how much of my 1986 code is still in use.