I have a customer who runs an Ignition vision installation which was deployed in 2018 as v7.9.9. As the application is in the medical field, they have extremely strict isolation and validation requirements for any and all modifications, which means that they do not perform regular upgrades, since any modifications require a re-validation process.
There is now a functional upgrade to the system happening, which will require re-validation anyway, so I have suggested that they upgrade their SCADA at the same time, at the very least to the most recent minor revision (7.9.21) - I also gave them an option to upgrade to 8.1 but they decided not to proceed with that option.
Just trying to work out what things I should be considering in the revalidation process. I have covered off things like re-validating all of the redundancy failover tests, checking all of the device and database connections and alarming, checking logs for new errors or warnings, and functional testing - I'm more looking for things that might have changed between 7.9.9 and 7.9.21 which might be worth specifically identifying and testing. Is there some way I can compile a list of changes between those two versions, to review and identify specific things that might need to be re-tested?
{My Bold.} There's your mistake. Deploying an already end-of-life product when the window of opportunity to re-validate is open is simply insane. Some things are worth walking away from.
As to your question, see the changelogs linked from the downloads page.
It was more a cost thing. Upgrade protection was of limited use for them given that they generally don't update, and the fact that every part of their ecosystem is fully tested, validated, and then does not change. So they opted not to continue with ongoing support. The system has run for 7 years without a single change bigger than "add some more alarming around failed database connections", so I can see the rationale behind that decision.
So when the cost of getting a redundant license back into support to be able to upgrade it more than doubles the cost of what is otherwise a fairly simple project, even before you consider the extra engineering time and validation requirements. It was just never going to get past the bean counters.
I'm sure that when a higher-value project comes along they'll revisit it, when the cost to do so adds 20% instead of 200% to the project budget. In the meantime, they're a good client and I'll help them out within the operating parameters they have available.
I agree with @pturmel. Unless you are targeting a problem which is expected to be fixed in the newer version, it’s not worth it to revalidate an entire SCADA system only for a minor version upgrade (especially one EOL).
If there are no known issues with the current version, consider skipping on the upgrade .
Otherwise, read each of the release notes between versions, note anything relevant & significant .
I've spent time reviewing and documenting all the release notes from all the intermediate versions, but these mostly only tell me about problems that have been fixed. I think what I'm hoping for is some kind of "known bugs" register, where I could filter them by version. If I can get a list of all known bugs applicable to 7.9.21 and 7.9.9, and identify any bugs that did not present in 7.9.9, or are not fixed in 7.9.21, then I have a bit more ability to target my testing.
I guess this probably doesn't exist (at least, not publicly) but worth trying.
.