This is a systems argument, not just software. It applies to choosing to do anything. I would rearrange these points, but they are essentially correct. You don't make changes for the sake of change or because something is cool, you make changes when:<p>1. Necessity. You need something that the current system is not doing for you. That might be scalability, or performance, or stability, or having good maintenance procedures, or compatibility with another system... In order to justify this change, you must clearly understand and document what it is that you want to do and how the existing system cannot do it.<p>2. Cost. Could be dollars paid for licenses, or for consultants, or for attention required from your own people, but excessive cost is certainly a convincing reason to change a system. You do need to make sure that the cost of implementing the new system isn't going to exceed the cost of keeping the old one. That can be non-obvious.<p>I have lumped in "difficult" with "cost" because they are the same thing with two names. Cost in time to change or time to learn or time to implement always converts directly to a cost in dollars and a cost in opportunities to do something different.