1, You're not screwing anything up. You're creating some new product from scratch, and resources spent learning a new tool will be resources saved in future projects that use the same tool.
2, And old releases have bugs that will hardly be fixed because the support has been dropped. Follow the six month rule, and then, if you find more bugs, report. It is a lot more likely that the bugs in a new version will be fixed, and quickly, than in an old version.
3, The amount of resources the change will save due to its improvements. I am not saying it will always net positive, but it will also not net negativly always, so it is worth a study. Dismissing because "We don't know" is not a valid excuse, or should not be.
4, Once more, use the six months rule. Anything that is still a hype after six months in a fast paced market like IT is worth a look only for this merit.
5, Again, it depends on how much time the change will save BOTH in the current project and in future ones. A mistake always made is to consider only the current project as time spent. This is unfair and will lead to biased results that will cause the change to be refused nearly always.
6, You talk like my manager. Are you him?
I know you are not making any judgement. You are telling me what you have heard before, probably when faced with the same situation. Problem is, when faced with counter arguments the final answer is "We don't know" or "We don't want to". It is a lose lose situation.
1. The current runs perfectly. Why spend any resources to risk screwing that up?
2. New releases often introduce new bugs / problems. (Vista, heh heh)
3. ANY change requires SOME resources. How much can you spare?
4. Often, the "latest, greatest" technology turns out NOT to be. Many people prefer to wait to see how adoption goes.
5. Change often requires education. Have time for that right now?
6. <add your own>
Not making a judgment either way. Just pointing out a few things off the top of my head that concern shops already overloaded.