What I really need is something powerful enough to break through the "This process has worked for 20 years, why should we change it?" argument.

It's hard to really judge what would be a good argument without being a witness of the scene. But I'll try to help you frame your arguments so that they may be heard.

I assume your audience to have be a non-expert level of knowledge on the topic, and to have an interest in staying the current course. They have different concerns and responsibilities, and they may suffer serious consequences if something goes wrong, so you'll have to work from that mindset. Anticipate some of the questions or worries they might have:

• What new capabilities would this bring? Is there something that we currently cannot do, that we would like to do, and that this new thing would allow us to? Start on a positive note.

• What is the impact on release schedules? What is the cost of implementing this change towards the immediately next release? What are the costs and benefits to following releases?

• Will this entail a change in process? As distinct from the release schedule, will this change require that people in the release process change their ways? Will this be transparent to them, or will they need to adapt? Will you need to cooperate with other departments? People are resistant to change.

• Are there imminent dangers to sticking with the current system? Does the current process have software or hardware dependencies that have gone or will go end-of-life soon? Does it rely on specialised knowledge from individuals that drives up hiring costs? Does it have a potential security hole that the new system plugs (bonus points if this hole can lead to legal action)? Don't hand-wave or 'maybe' or 'probably' this: the sense is that it worked well for 20 years, so the burden of proof is on the advocate of change.

Also, be specific about problems and solutions. If you can't find specific examples, use honest estimates from your position as an expert. Examples of other companies/departments/entities adopting such a change, preferrably from your industry, and their evaluation of that change, will help you. (Don't pick examples that had some sort of publicised IT issue in recent years, or the onus will be on you to prove that this change was not the cause.)

You may find this answer to Convince the Company I Work for to Implement Version Control? helpful.

What I really need is something powerful enough to break through the "This process has worked for 20 years, why should we change it?" argument.

It's hard to really judge what would be a good argument without being a witness of the scene. But I'll try to help you frame your arguments so that they may be heard.

I assume your audience to have be a non-expert level of knowledge on the topic, and to have an interest in staying the current course. They have different concerns and responsibilities, and they may suffer serious consequences if something goes wrong, so you'll have to work from that mindset. Anticipate some of the questions or worries they might have:

• What new capabilities would this bring? Is there something that we currently cannot do, that we would like to do, and that this new thing would allow us to? Start on a positive note.

• What is the impact on release schedules? What is the cost of implementing this change towards the immediately next release? What are the costs and benefits to following releases?

• Will this entail a change in process? As distinct from the release schedule, will this change require that people in the release process change their ways? Will this be transparent to them, or will they need to adapt? Will you need to cooperate with other departments? People are resistant to change.

• Are there imminent dangers to sticking with the current system? Does the current process have software or hardware dependencies that have gone or will go end-of-life soon? Does it rely on specialised knowledge from individuals that drives up hiring costs? Does it have a potential security hole that the new system plugs (bonus points if this hole can lead to legal action)? Don't hand-wave or 'maybe' or 'probably' this: the sense is that it worked well for 20 years, so the burden of proof is on the advocate of change.

Also, be specific about problems and solutions. If you can't find specific examples, use honest estimates from your position as an expert. Examples of other companies/departments/entities adopting such a change, preferrably from your industry, and their evaluation of that change, will help you. (Don't pick examples that had some sort of publicised IT issue in recent years, or the onus will be on you to prove that this change was not the cause.)

You may find this answer to Convince the Company I Work for to Implement Version Control? helpful.