Ignition Redundant Upgrade: Why Is the Project Incompatible?

Why don't the usual upgrade orders work?

Two upgrade orders for an Ignition redundant pair show up in published guidance, and both cause problems.

Upgrade the Master first while it is active. This was the older recommendation. Taking the active Master down forces an unplanned failover, and clients move to a Backup that is still on the old version. Clients stay up, but you have given up control of when the switchover happens. Standard practice is to control the failover yourself, not let a shutdown trigger it.

Upgrade the Backup first, then move clients to it. This is the newer knowledge-base approach. On a 7.7.3 to 7.7.4 upgrade it failed. Once the Backup came back on the new version, its project state showed Incompatible and clients would not transfer. A second site upgrading 7.7.2 to 7.7.4 started with the Backup and also ran into problems.

Looking for an override setting. No setting lets clients fail over to a node whose project state is Incompatible. The block is intentional. Relaunching clients, retrying the transfer, or restarting the Backup gateway does not clear it, because the version mismatch between the nodes is still there. The upgrade order is the problem, and no configuration change will fix it.

What is actually blocking the failover?

Follow the chain. The Master holds the project and configuration. Redundancy synchronization pushes that configuration to the Backup. Clients check that the node they are moving to can serve the project they are running.

If the Backup runs a newer version than the Master, the Backup receives project data from an older authority. It cannot treat that data as a valid match for its own version, so it reports the project state as Incompatible. Clients read that state and refuse to switch. The final element here is the client session, and it sees a gateway it is not allowed to use.

Reverse the version order and the chain works. When the authoritative node (the Master) is newer, it controls the configuration, and clients reconnecting to it pick up the new version. A briefly older Backup does not strand anyone as long as it is not carrying the clients during that window.

The fix is therefore about sequence. The node that clients are using and the node that holds project authority must never be on different versions in the wrong direction while clients depend on the older one.

Which signals tell you where the pair stands?

Check the Gateway Status page on both nodes before touching anything. The table lists what to read and what a wrong value looks like.

Record all five signals before the upgrade. Afterward you need a known-good baseline to compare against.

What upgrade order keeps clients running?

This sequence worked on a 7.7.2 to 7.7.4 upgrade. It gives you a controlled failover and keeps the newer node in the authority role whenever clients depend on it.

1. Take a gateway backup of the Master before starting. This is standard practice, and it is your rollback path.
2. Confirm both nodes are connected in redundancy, on the same version, and that the Backup project state is not Incompatible.
3. Force a failover to the Backup using the link on the Status page. Watch clients move to the Backup, which is still on the old version, so no compatibility problem exists.
4. With the Backup active and carrying clients, upgrade the Master.
5. Bring the Master back online on the new version. Let it take control. Check the redundancy settings to see whether the Master reclaims control automatically or needs manual recovery. If recovery is manual, trigger it yourself.
6. Confirm clients have moved to the upgraded Master and are running normally.
7. Upgrade the Backup.
8. Let the Backup reconnect. The Master, now on the matching version, synchronizes the project to it.

Complete one step and confirm it on the Status page before starting the next. Do not start the Backup upgrade until clients are confirmed on the Master.

How do you verify the pair is healthy afterward?

1. Compare the gateway versions on both Status pages. They must match exactly.
2. Confirm the Master is active and the Backup is in its standby role, with the redundancy link connected.
3. Confirm the Backup project state is no longer Incompatible.
4. Run a controlled test failover to the Backup and confirm clients transfer. Then return control to the Master.
5. Compare against the baseline you recorded earlier. Any signal that differs needs an explanation before you close the work.

The test failover in step 4 is the only real proof. A pair that looks healthy on the Status page but has not been failed over is not verified.

Which pitfalls recur on redundant gateway upgrades?

• Conflicting published guidance. Forum-era advice said Master first. A later knowledge-base article said Backup first. Field results on 7.7.x supported neither exactly, and the forced-failover sequence above is what worked. Confirm the order with Inductive Automation technical support for your specific source and target versions before a production upgrade.
• Master recovery left on manual. The upgraded Master comes back but does not take control. Clients stay on the old-version Backup, and upgrading the Backup at that point drops them.
• Skipping the redundancy link check. If the nodes were not synchronized before the upgrade, the Backup can show project problems unrelated to version. Fix synchronization first.
• Retrying failover against an Incompatible Backup. Repeated transfer attempts will not succeed. Restore version order by upgrading the other node in the correct sequence.
• Treating a version skip as a patch. Upgrades that span several releases (7.7.2 to 7.7.4, for example) carry more risk than a single patch step. Budget a maintenance window accordingly.

FAQ