This is really aimed at people who implement and support commercial systems within their own organisations rather than those who develop and support in house code (I have systems under each of those categories here).
Typically, commercial systems that an organisation has bought into, each version will have its own support lifespan, and at the end of that lifespan, support for that version will cease, and the vendor will require an upgrade to a newer version that is currently supported as a condition of providing continued support for that application.
Such requirements will undoubtedly be outlined in the contract the organisation has signed up to at the time they first bought into the application, and possibly also detailed on their own support website, discussion fora etc. However, they are soon forgotten about and the signed contract gets stuck in the bottom of a filing cabinet somewhere.
While in house support staff can undoubtedly keep people up to date and recommend upgrading said applications to a newer version to the appropriate managers, where the managers have an "If it ain't broke, don't fix it" attitude, the only thing that makes it happen will be logging a support call and being told you are on an unsupported version and please upgrade.
I've already tried getting the boss to add into the annual schedule of work an upgrade to each application to the latest production version of it at that time, but that's "too much work with everything else on at the moment" - which is generally a recipe for a problem in the future.
We have had this twice over the last couple of years and can possibly see it happening again in a few months time if we don't get a move on with something else; has anybody here got any hints/tips/suggestions to ensure that upgrades are carried out in good time before supported versions go out of support (which ends up with a rush upgrade going live not being fully tested, which brings its own issues)?
John
Typically, commercial systems that an organisation has bought into, each version will have its own support lifespan, and at the end of that lifespan, support for that version will cease, and the vendor will require an upgrade to a newer version that is currently supported as a condition of providing continued support for that application.
Such requirements will undoubtedly be outlined in the contract the organisation has signed up to at the time they first bought into the application, and possibly also detailed on their own support website, discussion fora etc. However, they are soon forgotten about and the signed contract gets stuck in the bottom of a filing cabinet somewhere.
While in house support staff can undoubtedly keep people up to date and recommend upgrading said applications to a newer version to the appropriate managers, where the managers have an "If it ain't broke, don't fix it" attitude, the only thing that makes it happen will be logging a support call and being told you are on an unsupported version and please upgrade.
I've already tried getting the boss to add into the annual schedule of work an upgrade to each application to the latest production version of it at that time, but that's "too much work with everything else on at the moment" - which is generally a recipe for a problem in the future.
We have had this twice over the last couple of years and can possibly see it happening again in a few months time if we don't get a move on with something else; has anybody here got any hints/tips/suggestions to ensure that upgrades are carried out in good time before supported versions go out of support (which ends up with a rush upgrade going live not being fully tested, which brings its own issues)?
John