Tridium Upgrade: Niagara Version Upgrade and Migration Guide

What a Tridium Upgrade Actually Involves

Tridium is the company behind the Niagara Framework (now part of Honeywell), so "Tridium upgrade" is shorthand for a Niagara version change. In practice it covers four distinct jobs, and they are not equally hard:

• Point upgrade within Niagara 4 — Moving a station from one Niagara 4 build to a later one. Mostly mechanical, but still gated by licensing and module compatibility.
• Niagara AX to Niagara 4 migration — A full generation change, not an in-place version bump. The station has to be converted with a migration tool, and the hardware often cannot make the jump at all.
• Supervisor upgrade — Upgrading the server-side Niagara installation, which usually has to lead the JACEs it manages.
• JACE distribution upgrade — Pushing a new Niagara distribution and platform daemon to the controller itself through the platform Commissioning Wizard.

Niagara AX has reached end of life, which is what drives most upgrade projects today: sites running AX no longer receive cybersecurity patches and are being moved onto Niagara 4, the current production target. Niagara 5 has been announced but is not yet generally available — per Tridium's Niagara 5 FAQ, GA is targeted for Q4 2026 — so it is a roadmap item to plan for, not an upgrade you can perform on a production station today. The path you take depends on what you are running now and whether the existing hardware can host the target version.

The Two Things That Gate Every Upgrade

Before scheduling any upgrade, confirm these two prerequisites. Most failed or stalled upgrades come back to one of them.

1. An active Software Maintenance Agreement (SMA)

Niagara licenses are tied to an SMA (or an Enterprise SMA, the ESMA, for larger portfolios). The rule that catches people: the SMA expiration date must fall on or after the release date of the version you want to run. If your SMA lapsed before the target build shipped, the license will not authorize that build — even though the software installs fine. You renew or extend the SMA first, then upgrade. Tridium gates major transitions behind an active maintenance agreement — including the move from Niagara 4 to Niagara 5 when N5 ships — and some drivers and toolkits require an active SMA to remain eligible for migration.

2. Version compatibility across Workbench, platform, and station

Workbench, the platform daemon on the JACE, and the running station all carry version numbers, and they have to line up. As a general rule you cannot open a station in an older Workbench than the one that built it, so the engineering PC's Workbench should match or lead the target station version. Plan the Supervisor and Workbench upgrades to lead the JACEs they talk to, not trail them.

Pre-Upgrade Checklist

Run this list before the maintenance window opens, not during it.

• Take a full backup. Capture a station backup and a platform-level backup so you can roll back if the upgrade fails partway. Our guide to backing up and restoring a Niagara JACE walks through both methods and what each one actually captures.
• Confirm the hardware can host the target version. Newer Niagara builds need more RAM, more Java heap, and more disk than older ones. An AX JACE running near capacity frequently will not fit the same station once converted to N4. On the JACE-8000, Niagara 4.8 and later need roughly 40 MB more free physical RAM than 4.7, and a controller without that headroom can fail the update. Check free resources before you commit.
• Verify the controller is even upgradable. Older QNX-based AX JACEs cannot run Niagara 4 and require hardware replacement, not a software upgrade. For AX-to-N4 work, the JACE generally needs to be running at least AX 3.8.x and be on hardware compatible with N4. Tridium publishes a migration checker that flags whether an existing AX JACE meets the N4 minimums.
• Inventory your modules and drivers. List every module the station uses, including third-party and legacy drivers. Each one needs a version compatible with the target build. A single module with no equivalent for the new version can block the whole upgrade.
• Note the certificate state. Version changes, IP changes, and platform daemon restarts routinely surface certificate problems. Know what your current certificates look like going in — see fixing Niagara 4 certificate and SSL errors for the failure modes to expect afterward.

Upgrading Within Niagara 4

For a point upgrade where the hardware and licensing already support the target version, the sequence is straightforward:

1. Install the target Workbench version on the engineering PC.
2. Connect to the JACE's platform and run the Commissioning Wizard to install the matching Niagara distribution and platform daemon, along with the module set for that version.
3. Let the controller reboot into the new platform.
4. Open the station. If Niagara prompts to convert it to the new version, allow the conversion, then save.
5. Verify drivers, histories, schedules, and alarm routing came back cleanly, and re-check platform connectivity over Fox and the web interface.

Migrating Niagara AX to Niagara 4

This is the case people underestimate. AX and N4 are different framework generations, so you do not "upgrade" in place — you convert the station with the N4 migration tool, which refactors the AX station into an N4 station. The high-level path:

1. Confirm the JACE meets the N4 minimum requirements (AX 3.8.x or later, N4-capable hardware, sufficient RAM and disk). If it does not, the controller is replaced rather than upgraded.
2. Back up the AX station and export it for migration.
3. Run the migration tool to convert the station to N4, then open and test the converted station offline before touching the live controller.
4. Commission the JACE to the N4 distribution, install the converted station, and re-apply the license under your active SMA.
5. Validate every driver and integration end to end — a converted station can come up with subtle binding or type differences that only show under load.

Common Pitfalls

• Upgrading Workbench but forgetting the SMA. The software installs, the station builds, and then the license refuses the new build because the SMA date predates it. Check the SMA before you schedule the window.
• Upgrading on hardware that is short on resources. A JACE running near its RAM or disk ceiling can fail the update or come back unstable. Confirm headroom first; this is the most common cause of a bricked controller during an upgrade.
• Skipping the backup. Without a station and platform backup, a failed upgrade has no clean rollback. Treat the backup as mandatory, not optional.
• Assuming third-party modules will just work. Legacy or custom modules often have no build for the target version. The station will not run correctly until every module is accounted for.
• Treating AX-to-N4 as a click upgrade. It is a migration with a conversion step and a real chance of hardware replacement. Scope it as a project, not a maintenance task.
• Letting Workbench and station versions drift. Opening a station with mismatched Workbench versions causes connection and conversion errors that look like network faults but are not.

When to Escalate

Bring in your Tridium partner or Honeywell support before, not after, things go wrong in these situations:

• The SMA has lapsed and you need to renew or extend it before the target build will license.
• The migration checker says the existing JACE cannot host the target version — you now have a hardware replacement to plan, not an upgrade.
• The station depends on custom or legacy modules with no equivalent for the new version; the module vendor has to provide a compatible build.
• The site cannot tolerate downtime and you need a staged migration with an offline-tested converted station before cutover.

A Niagara upgrade touches licensing, hardware capacity, and every integration the station carries. The upgrades that go badly are the ones rushed into a production window without checking the SMA, the hardware headroom, and the backup first. Confirm those three, test the converted station offline where you can, and the cutover itself is usually the easy part.

Source Attribution

The guidance in this entry is informed by the following sources:

• Software Maintenance Agreements — Tridium. Defines the SMA/ESMA program and its role in authorizing access to newer Niagara versions and patches.
• Niagara Framework documentation — Tridium. Platform commissioning, station conversion, and Workbench compatibility behavior.
• Niagara AX to N4 Migration Guide — Tridium / Honeywell. Covers the migration tool, the AX 3.8.x prerequisite, N4 hardware resource requirements, and the migration checker for existing AX JACE platforms.
• Niagara 5 / SMA FAQ — Tridium. Documents the requirement for an active maintenance agreement when transitioning from Niagara 4 to Niagara 5.

Version-specific requirements change between Niagara builds. Always confirm current minimums against Tridium's documentation for your exact target version before upgrading. Additional field validation by SiteConduit.