Service
Niagara 5 readiness and migration
Niagara 5 changes three things that break modules: a new Java runtime, 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. Nothing stops working in 2026; the reason to start now is that the inventory is the input to next year's capital plan, and controller replacement has a lead time rather than a switch.
- Java 8 → 25
- Mandatory signing
- JACE-8000 → 9000
- Module inventory
- Porting
The scan is free
Before anything gets quoted there is a step that costs nothing and answers the only question that matters first: is there a problem here at all. For most estates the answer turns out to be no, and finding that out should not cost anybody a purchase order.
Send any one of three things
A listing of the station's modules/ folder — a directory
listing, a text file, even a screenshot; it does not need to be tidy. Or the
jars themselves, which gives a deeper answer because the bytecode can be read
rather than inferred from filenames. Or a station backup, and the module set
is read out of it. One station or fifty.
What comes back
A table, one row per module: findings by severity, the class-file versions inside the jar, the signing state, and a plain one-line verdict. Written to be read by whoever has to make the decision, not only by whoever wrote the module.
What it costs
Nothing, and it obliges nothing. No quote is attached to it, and there is no follow-up unless you ask for one. If the honest answer is that your modules are fine, that is the answer you get — and it is the most common one.
| Column in the table | What it tells you |
|---|---|
| Findings by severity | Split three ways: calls that throw on the new runtime, calls that still run but whose meaning changed silently, and things that work but are on notice. The middle group is the one worth reading twice — a module that installs, starts, and quietly does the wrong thing is a harder problem than one that refuses to load. |
| Class-file version | The oldest bytecode in the jar, including inside the libraries it bundles. Very old bytecode still loads on a modern JVM; what it cannot do is be recompiled by any current toolchain. So this column flags a dependency nobody can fix, rather than a module that will not start. |
| Signing state | Signed or not, by what, and whether that certificate is trusted by the hosts the module has to load on. Signing becomes mandatory, so this is a separate question from whether the code survives — a module can pass on code and fail here. |
| Verdict | One line, in plain English. Likely fine as it stands; needs its bundled libraries bumped and a rebuild; needs source changes; needs the original vendor; or needs replacing because the vendor is not coming back. |
What the scan is, said precisely. It reads a module's bytecode and reports what a real Java 25 JDK does with it. That makes it static analysis against Java 25, not a test on a Niagara 5 build — no Niagara 5 build exists to test against yet, and a readiness claim that does not draw that distinction is claiming more than it can show. A module that scans clean can still need work against a new SDK. This is the cheapest way to find the modules that are definitely a problem; it is not a certificate of readiness, and it is not sold as one.
What actually changes
| Change | Consequence for an existing estate |
|---|---|
| Java 8 → Java 25 | Tridium's current FAQ names Java 25; earlier partner material said 21. Either
way, 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 the new runtime, 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.
If the catalogue is yours
Module vendors have the hardest version of this problem: not one module to port, but every module, to a fixed date, with customers already asking.
Priced per module
So it can be staged rather than committed to as one number. Start with the two most at risk; the rest follow once the pattern is proven on those.
Your name on it
Your module name, your vendor string, your certificate. The readiness statement is written for you to publish to your own customers.
No customer contact
A subcontract stays a subcontract. We do not appear in front of your customers, and an NDA before the first technical call is signed rather than negotiated.
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 scan | Free, and the first step. A per-module table: findings by severity, class-file version, signing state, and a plain verdict. The one deliverable on this page with no price attached. |
| 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: recompiled for the new runtime, bundled libraries bumped, re-signed, regression-tested, with a readiness statement that says what was analysed and what was tested. |
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 in bajaux and BajaScript: HTML5 BMS dashboards, HVAC plant views, navigation and charts, bound to live station ORDs and BQL.
PX graphics
Niagara PX graphics as a reusable template set: standard HVAC plant sheets, relative-ORD binding, navigation hierarchy and a written 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
What happens to third-party modules moving from N4 to N5
A module with no Niagara 5 build can stop the migrator outright, and one that has a build can still fail to load. What breaks, and why.
- Migration
- Estate management
- Module development
JACE-8000 to JACE-9000: what the licence transfer does and does not do
The JACE 8000 to 9000 licence transfer, step by step: what it requires, what it does not include, and which parts cannot be undone.
- JACE
- Migration
- Licensing
What Java 25 does to Niagara's module permission model
Niagara's module permission model is built on Java's Security Manager. On a Java 25 JVM it cannot be installed, so the checks stop happening.
- Module development
- Station security
- Migration
What a static Niagara 5 module scan actually finds
Reading a module's bytecode against Java 25 gives a per-module answer. What it finds, what it cannot tell you, and the false alarms it avoids.
- Migration
- Module development
- Estate management
What actually blocks an AX to N4 migration
A station cannot migrate until every module it uses has been refactored for Niagara 4 — and licences, users and permissions all change shape on the way.
- Migration
- Estate management
- Module development
Next step
Send a module list. The scan comes back free.
A directory listing of the modules folder is enough — the jars or a station backup work just as well. What comes back is a table, one row per module, with a plain verdict: no charge, and nothing attached to it. Not having a list is the normal case and is most of the reason the audit exists, so saying so is a perfectly good way to start.