The same thing happens with the hope for the "next generation" product solving all the ills of the current generation. Or the assumption that the code you have inherited was created by fools a number of years back.
The reality is that software has a set of maturity related bugs and a set of structural, intractable issues that are related to the design and architecture of the system. Each piece of software has it's unique set of intractable issues.
Software that has been in production has typically reduced it's maturity related bugs. The software built on top or that integrates with it is built around those intractable issues. When you move to a new piece of software - either a new architecture or the "groundbreaking ng version of XYZ", you end up with swapping a set of *known* intractable issues, for a set of *unknown* intractable issues plus a set of maturity related bugs.
Similar to TFA, the risks of old+known vs new+immaturity+unknown needs to have another factor similar to "value-add". If the value-add *really* adds a lot of stare the risks in the eye and march forward. If the value add is marginal, make sure the meta-benefits (performance, maintainability, etc) are clear and understood, otherwise you may be facing a train wreck of an upgrade.
Seen it many times, always wary of the ngXYZ project...