Not only broken up, but merged again after a while as well.

I think that this is a very solid point, but perhaps the reasoning underlying this type of issue is somewhat more complex. For example, we run a what is now a v5 of our API as a bunch of microservices and have been running it as microservices since v4, about 4 years now. These are "children" of v3 - our monolith. The monolith is still alive and kicking in a much reduced state but the reason we cannot decom it has nothing to do with design or time or priorities - the monolith is sitting in a data centre and is the only regulatory permitted way (in our case) to access the mainframe. So, it sits there as a gatekeeper and will do so for the foreseeable future...

Yes, and I've gone the other way too, i.e. taking a bunch of microservices and rewriting them as a monolith, saving the company over a million dollars a year in the process.

It isn't one or the other, the 'skill' is knowing which to apply when.

To make most of these types of projects work, the sponsor needs to demand an incremental approach that delivers real value, piece by piece, all the way up to retiring the original system(s). Tie-out is also necessary for many projects, and all the associated testing. It is a big grind, which is probably why so many of these projects fail.

> you end up with both the old monolith and new microservices, the monolith never gets fully broken up, and now you need to support two development paradigms forever.

It's not a bad thing, it's actually a quite pragmatic approach. Some folks call it The Citadel:

https://m.signalvnoise.com/the-majestic-monolith-can-become-...

Building monolith is the best way to learn about domain and domain boundaries. Monolith is way more forgiving for your mistakes.

Going all in on microservices is like believing you learned everything there is. Some folks believe that, most of the time they are wrong.