Note, I am explicitly not asking if this is optimal. I am asking if it is good enough.
There is a tendency to assume 'it works, and that let sleeping dragons be. This is usually correct, my own definition for legacy code is "code that makes money". As such, any modifications to it should be justified in terms of ROI.
The term that I often use for that is technical debt, by no means my own invention, by a very useful concept. This allow me to explain, in terms that makes sense to the client, what are the implications of letting working, but not good enough implementation to stay in place. Or why I need to take a week or two with a couple of developers to refactor parts of the application.
We like to think about refactoring as: changing the internal structure of the code without changing observable behavior. Business people tend to think about it differently. A time in which the development team is going to do stuff that doesn't give me any value. The inability to translate the difficulty to terms that the business understand is important. And framing such discussions in terms of the technical debt into which they will get us into is critical.
Setting expectations about the behavior of the team is just as important as setting expectations about the behavior of the application.