My problem with "if it ain't broken don't fix it" is that there can be many different definitions -- end levels within each definition -- of broken, especially in complex systems. Take a standard example of a software app which is working as it's supposed to (so it's "not broken" in one sense) but is a mess of spaghetti code which makes it insanely difficult to add new functionalities (so it's "broken" in a different sense).

When you look at it it becomes clear that it is important to understand which levels and definitions of "brokenness" are possible in your case, and even more importantly which of them matter and how much. Only then you can look at each proposed solution to find out which of the important problems it solves and how well.