This is really a frustrating subject for me. For years I have seen and experienced the angst of trying to get a new technology or new product not just on the table, but just to be considered by a team of IT folk. It's really amazing how people that live and breath technology, which infers a sense of change and progress, many of these people absolutely fear change. Here's but one example.
Many reasons are dragged out as defense for resistance to change. Some cite the age old "if it ain't broke, don't fix it" phrase. Others argue the stability and security uncertainties aspects. Some argue the licensing costs angle. Whatever the case, these are all flawed arguments when it comes to considering a new technology candidate. Let's break it down shall we?
If it ain't broke...
How do you even know what's broken? How many IT "experts" can honestly say they've used EVERY SINGLE feature and option available to them for any given product? None. Not because that would be admitting some sort of egotistical failure. But because we simply don't need every feature and option. I can't even count how many times I've seen geeks smile when they discover, unexpectedly, that the new product does something better than the incumbent product. Whether it's a matter of time savings or greater flexibility and capability. Again, you may not know your current solution is broken until you give another product consideration.
Stability and Security...
Sure. You are 100% comfortable with your current product. You know every bit and byte it encompasses. There is no way there's a vulnerability hidden inside your baby. Statistically speaking there is no greater assurance that a "released" product is any more secure or predictable than its successor (e.g. an upgraded version). And while there is possibly a greater statistical predictability for one known product over a completely unknown (different) product, there is still no statistical assurance it is safer than the unknown product. Familiarity and vulnerability do not relate. It's an emotional attachment that holds no tangible value beyond the human aspects (training/learning curve, problem resolution response processes, support mechanisms). These are all easily addressed by the "consideration" phase.
Licensing and Costs...
Maybe you're still on the buy-as-needed cycle, rather than the newer subscription model. No problem. Maybe you're convinced that the new version or product won't deliver enough benefit to offset the upgrade costs. Maybe so. But how will you ever know until you really put it into a thorough testing environment? This is what I'm talking about. If you do your testing correctly, it should result in a tangible analysis of time savings, increased capability, and reduced effort (i.e. labor hours) to clearly support an evaluation against the upgrade costs. Don't knee-jerk on this, think it through.
Too many decisions are knee jerk or based on emotional attachment. Emotional attachments are the wellspring of vendor existence. They absolutely LIVE for you to become attached to their solutions. Break the emotional attachment and stick to a logical attachment. Don't fall into the trap. Your duty is to your employer, not the vendor. Saving your company money and providing increased capability are what you should be concerned with. Not coming to work wearing a vendor polo shirt or baseball cap.
Resist the urge to wear (IT) vendor apparel to work. It's a billboard that says "I'm resistant to change - I fear it"