The biggest problems come in when your apps are doing hacky things they shouldn't be doing. This is a common issue with things like Electron, or React Router, and of course, Webpack.

If you are fairly careful and conservative, and lucky enough to be using software after it has matured, I think most upgrades will wind up being pretty uneventful for you.

I'm saying it explicitly: your exception project probably sucked. That's probably why it was tricky to upgrade. It may not have been your fault or even the fault of the people who wrote it. But for example, it was never architecturally a good idea to have Webpack automatically import browserify Node stubs. It was never a good idea to load Node modules from within an Electron renderer thread. Not always your fault. A reasonably well-archirected app usually refactors decently into changes that fix these issues. A poorly architecture app is so fragile it's hard to imagine refactoring anything without something breaking a few miles away. If you have the latter, then no shit that upgrading dependencies sucks... I mean, changing anything else sucks too.

This isn't the root cause of every horror story... But it's a lot of them

But that's where you have to balance the gain updating the old toolchain against the benefits in your specific situation. Are you going to spend a lot of time on the project, or is it just a few bug fixes? Can you revive the old toolchain? Is the old toolchain churning out good enough production ready assets?

Upgrading dependencies can be a trap. Like, in the past, I've delegated a bugfix that shouldn't take more then an hour or two to a co-worker, only to see them waste an entire day in dependency / NPM hell.

To my mind, there needs to be a compelling case or argument that justifies sinking time in an upgrading exercise.