Service
Niagara 5 readiness and migration
Niagara 5 changes three things that break modules: Java 21, mandatory signatures with no grace period, and hardware — it does not run on a JACE-8000 at all. The first useful step is finding out which of your modules actually survive.
- Java 8 → 21
- Mandatory signing
- JACE-8000 → 9000
- Module inventory
- Porting
What actually changes
| Change | Consequence for an existing estate |
|---|---|
| Java 8 → Java 21 | Modules must be recompiled. Anything depending on SecurityManager, on
removed internal APIs, or on a library that itself stopped at Java 8, needs source
changes rather than a rebuild. |
| Signing is mandatory | A valid signature becomes a hard requirement with no grace period. An unsigned module, or one whose vendor has disappeared and cannot re-sign it, will not load. This is the change most likely to strand a site. |
| JACE-8000 cannot run it | Migration at the edge is a controller swap at every node, not a software upgrade. That makes it a capital project with lead times, not a maintenance window. |
| Themes | The Niagara 4 Zebra and Lucid themes are not carried into Niagara 5. Graphics built against them need review. |
| Niagara 4 keeps running | Niagara 4 reaches end of life in 2028. There is no cliff in 2026 and no need to move an estate at once — but there is a good reason to know now which modules will not make the trip. |
On dates. Niagara 5 is expected to reach general availability around the end of 2026 and Niagara 4 is supported to 2028. Dates published by Tridium around licence transfer are commercial deadlines for a discount, not a point at which anything stops working — worth planning around, not worth panicking about. Confirm current dates with your distributor before committing budget; this page is not the system of record.
Three ways in
Readiness audit
An inventory of every third-party module across the estate, with vendor, version, signature state, stamped version, and a verdict per module: rebuild, port, replace, or abandoned and needs a plan. The document that makes the migration scopeable.
Porting
Taking a module you own — or one whose source you hold — to Java 21, re-signing it, auditing its dependencies, and running a regression pass, with a readiness statement you can hand to a client.
Replacement
When the original vendor is gone and the source is not available, rebuilding the function as a new module rather than waiting for a supplier that is not coming back.
Why the audit comes first. The modules that will hurt are not the ones from vendors who are still trading — those will be rebuilt and sold to you again. They are the one-off modules written for your site years ago by somebody who has moved on, which nobody has thought about since, and which the station will simply decline to load. An estate of any size usually has several, and they are only discoverable by looking.
Deliverables
What you actually receive
Fixed price per deliverable, quoted against a written specification. No hourly billing, and no price before the scope is in writing.
| Deliverable | Detail |
|---|---|
| A module inventory | Every third-party module across the estate, machine-generated rather than remembered. |
| A verdict per module | Rebuild, port, replace or at-risk — with the reasoning, so it can be challenged. |
| A sequencing plan | What has to happen before a controller is swapped, and what can safely wait. |
| Ported modules | Where porting is in scope: Java 21, re-signed, regression-tested, with a readiness statement. |
Also
Other services
Custom modules & drivers
Bespoke Niagara rt, wb and ux modules and drivers written against the Baja API: pure Java, signed, and stamped to install across a mixed estate.
bajaux widgets
Custom Niagara web widgets built with bajaux and BajaScript: HTML5 dashboards, navigation, equipment views and charts, bound to live station ORDs and BQL.
PX graphics
Niagara PX graphics as a reusable template set: standard sheets per plant type, relative-ORD binding, navigation hierarchy and a graphics standard.
Station engineering
Niagara station and controller setup end to end: platform commissioning, TLS, users and roles, BACnet and Modbus, tagging, histories, alarms, backups.
Workbench tooling
Custom Workbench views and tools for repetitive Niagara work: bulk renaming and retagging, station audits, provisioning helpers and module inventories.
Notes
Written up in more detail
The engineering behind this service, in public, with no pitch attached. All notes.
Which Niagara version to stamp a module for
A module's declared dependency version is a floor, not a pin. Build against the newest SDK you have and stamp for the oldest station it has to load on.
- Module development
- Mixed estates
- Build tooling
Next step
Tell us the version, the hardware, and what it has to do.
You will get a written scope and a fixed price against it. If the honest answer is that you do not need us, you will get that instead.