Start with lifecycle, not feature excitement
Inductive Automation lists Ignition 8.3 as an LTS release with active support through September 2030, while 8.1 active support ends in September 2027. That gives industrial teams a planning window, but it does not remove the need for disciplined migration testing.
The upgrade decision should be driven by lifecycle, risk and operational value. Features such as Event Streams, new drivers, historian improvements and the newer deployment model can be valuable, but the first question is whether the existing application can be reproduced and validated safely on the new release.
- Document current Gateway and module versions
- Capture license and certificate dependencies
- Agree production acceptance criteria before testing
- Define the rollback trigger and decision owner
Build a dependency inventory before touching a Gateway
The upgrade surface is larger than the core Ignition version. Third-party modules, JDBC drivers, device drivers, scripts, external libraries, authentication providers, certificates, Gateway Network links and database dependencies can all change the risk profile.
Ignition 8.3 documentation specifically calls out third-party module due diligence and Java compatibility. A readiness review should therefore create a dependency matrix with owner, current version, target version, compatibility status and evidence source for every non-core component.
- Core and third-party modules
- JDBC drivers and database versions
- OPC/device drivers
- External Python/Jython dependencies
- Identity providers and certificates
- Gateway Network and remote tag providers
Test behavior, not only whether pages open
A successful login and a few healthy screens are not enough. The test plan should exercise the behavior that production depends on: tag quality, alarms, historian writes and queries, Perspective session behavior, scripts, report generation, redundancy, store-and-forward, database failover and integration endpoints.
For each critical workflow, capture a before-and-after baseline. That turns the upgrade from a subjective visual check into an evidence-based comparison.
- Alarm activation and acknowledgement
- Historian write/read equivalence
- Perspective navigation and session reconnects
- Critical script execution time
- Database failover and store-and-forward recovery
- Redundancy failover and resynchronization
Treat project structure and deployment practices as part of the migration
Ignition 8.3 expands the platform in areas such as filesystem/project resources and Event Streams. Even when the immediate objective is a like-for-like upgrade, the migration is a useful point to clean up deployment practices, version control boundaries and environment promotion rules.
Do not combine every modernization idea into the same production cutover. Separate required compatibility remediation from optional refactoring so that rollback remains understandable.
- DEV, TEST and PROD version alignment
- Source-control ownership and generated files
- Environment-specific configuration separation
- Release notes and change approval
- One-click or documented rollback path
Make the go-live decision from evidence
The final readiness report should be short enough for operations, controls and IT leaders to use. A score is useful only if it is backed by explicit evidence and unresolved risks.
A practical outcome is a red/amber/green matrix covering compatibility, application behavior, infrastructure, security, redundancy, performance and rollback. Production moves only when the agreed red items are closed and amber items have accepted owners and mitigations.
- Compatibility matrix complete
- Critical workflows passed
- Performance within agreed tolerance
- Backups and restore tested
- Rollback rehearsal completed
- Named owners for remaining risks
Primary sources used for this perspective
- Ignition Long-Term Support
- Ignition 8.1 to 8.3 Upgrade Guide
- Installing or Upgrading a Module
- Inductive Automation - Why Right Now Is the Best Time To Switch From Ignition 8.1 to 8.3
Product names and trademarks belong to their respective owners. Delfers engineering perspectives are intended as architecture guidance; outcomes depend on site conditions, system design and implementation.