Hi all,
I’m going to be upgrading a multi-gateway architecture from 8.1 to 8.3. Generally speaking, I have the process for updating a singular gateway along with custom code changes for the project for 8.1 to 8.3 with no issues. The main issue comes when I have multi-gateways with backups and ignition servers dedicated for data-collection with ignition edge. Think of it as Ignition gateways collecting data, with frontend gateways getting that data and running perspective, each active gateway coming with a backup gateway as well.
As I have to do this upgrade live, my plan is to start with the gateways that receive data and go lower level from there. Meaning start with the frontend (backups first) then make my way down to the gateways running historian and ignition edge. I was wondering if anyone else has experience with this and can comment on any edge cases I may be missing here.
Thanks for taking a look!
Your plan of attack is correct, and matches that which is outlined in the 8.1 to 8.3 Upgrade Guide:
To prevent data loss, the central Gateway hosting the data must be upgraded to 8.3 first. This includes Gateways where the main Alarm Journal, audit profile, and history provider are configured. After taking your Gateway offline and upgrading it, ensure that the Gateway is running correctly.
Once the primary Gateway has been successfully upgraded to 8.3, you can proceed to upgrade each of your remote and Edge Gateways that utilize data storing services.
You should perform an upgrade of some of your gateways in a test environment first, and confirm functionality before you attempt a full migration. I would not plan on deploying a partial migration. Note that some strategic partner modules are still not released on Edge yet, especially EFM drivers by CirrusLink, which were targeted for Q1 2026 release. Perhaps soon…
Beyond that, read the upgrade guide a few times over, it highlights some important details.
A detail not mentioned is how memory tags are configured (stored value persistence).
Otherwise, a redundant Edge + redundant Full pair that I upgraded was very seamless.
I overlooked this detail. Assuming you mean redundant gateway first, you should reconsider might be correct.
I believe Ignition still recommends upgrading the Master gateway first (by first failing over to the backup node, confirm functionality, then begin the upgrade on the Master).
This was outlined in a How-To from a few years ago:
https://support.inductiveautomation.com/hc/en-us/articles/360047136192-Upgrading-or-Patching-a-Redundant-Ignition-Pair
It looks like official help docs recommend upgrading Backup node first:
1 Like
I suggest check Java compatibilities before any upgrade.
Something to be aware of is that, perhaps obviously with minor/major version migrations but less obvious with patch version migrations, if you migrate one and not the other, the Master will not be able to sync any project changes to the backup while there’s a version mismatch.
You probably shouldn’t be leaving a master and backup with mismatched versions for too long, but a customer of ours had their reasons and it meant we were essentially stuck with the project fixed as-is on the backup, as project changes would not be synched across from the Master due to the version mismatch – it was only a couple patch versions difference.
2 Likes
Thanks so much to everyone who took the time to respond. I put together a plan and ran some tests while keeping an eye out for some of the potential holes mentioned here. Luckily the upgrade tests was a success without any issues. I expect the production upgrades to also go without a hitch.
3 Likes