Basic answer is that you have to make the case that switching meets the needs of the business. For example:
- lower cost of development
- shorter schedule (another shade of #1)
- more apt for meeting process requirements (like software requirements traceability, or build reproducibility, etc).
Making the case on these things also requires something quantitative, not just "we will lower costs because this is the right way to do it!".
One thing to watch out for is that it's too easy for a developer to convince themselves that it would be beneficial to make the change without first going through the basic business filters. Once that happens, you end up with developers who are unhappy with their tools and are doubly frustrated because they think management won't listen. If you can't check off one of the things above, them you'll have no chance of persuading management of anything (unless management is incompetent, but that's for another question).
