If you still run Niagara AX, you already know the migration to N4 is coming — AX is legacy, and the industry has moved on. What is less clear from the outside is what the migration actually involves. It is not a version-update button. It is a project, and treating it like one is the difference between a smooth cutover and a building full of broken graphics. Here is an honest look at the work.
Why Move at All
N4 is the current Niagara generation and where all ongoing development, security updates, and driver support live. Staying on AX means running an increasingly unsupported platform on aging Java, with a shrinking pool of compatible tools and people. The migration is less about new features and more about staying on a supported, securable foundation — which, for building infrastructure that runs for a decade or more, matters.
What the Migration Touches
A station migration is not one task — it is several, and each has its own failure modes:
- The station itself. AX stations are converted to N4 through a defined process, but conversion is where incompatibilities surface — deprecated components, changed behaviors, and modules that have no direct N4 equivalent.
- Graphics. This is usually the biggest surprise. Older AX graphics built on the legacy Px/UX approach often need rework to render and behave correctly in N4’s HTML5 environment. Budget for it explicitly.
- Drivers and integrations. Every protocol integration — BACnet, Modbus, LonWorks — needs to be validated on N4. Most carry over; the ones that do not are better found in testing than on cutover day.
- Hardware. Some older JACE controllers cannot run N4 and must be replaced. Confirm which of your devices are N4-capable before you plan anything else.
- Scripting. Legacy AX scripting and custom logic need review; behavior does not always transfer one-to-one.
The Approach That Works
The migrations that go badly are the ones done in place, all at once, with no way back. The ones that go well share a pattern: inventory everything first (stations, drivers, graphics, controller models and their N4 capability), convert and validate in a test environment before touching production, and cut over in controlled stages with the old system recoverable until the new one is proven. Graphics rework is planned as its own workstream, not discovered mid-project.
Above all, the migrated system is verified point by point — that every input reads correctly, every command works, every schedule and alarm behaves — before the building depends on it. A migration that “looks done” but was never systematically checked is how a comfort complaint becomes a 2 a.m. call.
Plan It Before You Are Forced To
The worst time to migrate is under emergency — a failed controller or a security requirement forcing your hand. Planned, staged, and tested, an AX-to-N4 migration is routine. Rushed, it is a risk to building operations. If you are on AX, the useful move now is an assessment: what you have, what is N4-capable, and what the graphics rework really costs.
SoftwarePile plans and executes Niagara AX-to-N4 migrations the staged way — inventory, test conversion, graphics rework, and verified cutover. Tell us what you are running today and we will assess the path to N4.
AX 3.8 Is the Only Supported Starting Point
The migration tool reads AX 3.8 stations. Anything still on 3.5, 3.6 or 3.7 gets an AX-to-AX upgrade first, and that upgrade is its own piece of work, because every module loaded in the station has to have a 3.8 build available, third-party modules included. This is where migrations stall more often than at the N4 step itself: a vendor module that was fine for years and whose vendor never shipped a 3.8 release. The check is mechanical: list the modules in the station with the version of each, then find a 3.8 build for every one of them.
Licensing is the second gate. A Niagara license is issued against a host ID and also carries a version and a brand. AX licenses do not run N4 hosts, and on OEM-branded hardware the N4 license and the matching module set come from that OEM rather than from a generic pool. A controller that gets replaced during the project arrives with a different host ID, so its license is a new file, not a copied one.
History, Alarms and Accounts Convert on Different Terms
Conversion moves the station's logic, but the data attached to that logic and the accounts that reach it each convert on their own terms. Every one of these is worth an explicit decision before the tool runs rather than a discovery afterward.
- History data. Bringing histories across is a decision, not a default, and it is usually the longest part of the run. History records consume flash on the controller, so a station that was already tight on space in AX does not get roomier in N4. The common answer is to archive to a Supervisor or an external database and keep local retention short.
- Alarm records and routing. The alarm database converts, but AX alarm classes, recipients and console wiring land on N4's equivalents, and the routing has to be walked rather than assumed. An alarm that reaches nobody looks identical, from the operator's side, to one that never triggered.
- Users and permissions. AX's user list with category-based permissions becomes N4's separate UserService, RoleService and AuthenticationService. Categories do not turn into roles by themselves; someone maps them. Passwords do not come across at all, so every account is reissued under N4's password rules.
- Schedules and their links. Schedule components convert, but schedules shared between stations through Niagara Network imports and exports point at station names and handles that change during a staged migration. The import side is where they break, and it breaks quietly.
Custom Modules, Program Objects and Custom UI
Anything compiled against the AX API needs a rebuild against the N4 SDK, not a recompile of the same project. The build tooling changed, and from Niagara 4.9 onward modules carry code signing, so a rebuilt module that is not signed is treated as untrusted by current releases. A module whose source has been lost is not a rebuild problem, it is a replacement problem.
Program objects hold Java source that is compiled on the station. AX ran on a Java 6 era runtime and N4 runs on Java 8, so a program object that reached into an API which was removed or relocated fails to compile after conversion, and the symptom is a fault on the object once the station starts rather than a line in the conversion output. For these, the compile message on the object is the diagnostic, not the migration report.
Custom user interface work is the least portable layer. Px views built on stock widgets generally render, but views built on custom widgets or on hand-written BajaScript were written against an object model that N4 replaced; the N4 side is BajaScript 2 and the HTML5 Px environment, and JavaScript written against the old model does not carry.
Underneath all three sits one question: does the vendor of each third-party module ship an N4 build at all. That question belongs in the inventory phase, ahead of the driver validation testing, because the answer can change the shape of the project.
Running AX and N4 Side by Side During the Transition
An N4 Supervisor can sit on the same Niagara Network as AX 3.8 stations, which is what makes a staged migration possible in the first place. The usual order is head end first, then controllers in batches, because the Supervisor can talk down to AX 3.8 stations while the reverse does not work: an AX Supervisor cannot supervise N4 stations. The general rule holds throughout, in that the Supervisor runs at the same Niagara version as the stations under it or a later one, never an earlier one.
Two things need attention during the mixed period. The first is Fox itself: N4 defaults to TLS-only Fox, so reaching an AX 3.8 station means either running TLS on the AX side or relaxing the N4 side for the duration, which is a deliberate decision and one to undo when the last AX station is gone. The second is licensing: through the overlap you are carrying AX and N4 licenses at the same time, and the Supervisor license has to cover the number of stations connected to it, counted across both generations.
Ports, Certificates and Passwords All Change at Cutover
N4's security model is not the AX one with a checkbox added. The practical effect on cutover day is that everything holding a stored connection to the station gets it wrong at the same moment, which is why the connection inventory belongs in the plan next to the point list.
- Ports move. Fox goes from 1911 to 4911 for the TLS version, web from 80 to 443, and the platform connection from 3011 to 5011. Firewall rules, VPN access lists and monitoring checks written against the AX numbers do not fail loudly; they simply stop reaching anything.
- Certificates become load bearing. Each host presents a certificate, self-signed by default, and Workbench and browsers object until the signer is trusted on the client side or a CA-signed certificate is installed in the host's key store. Station-to-station Fox links fail the same way, so the trust stores on both ends of a Niagara Network connection are now part of commissioning.
- Platform credentials are separate from station users. The platform daemon keeps its own accounts, and losing them on a controller is a recovery procedure at the hardware level, not a password reset from Workbench.
- Field-side protocols are unaffected by this. BACnet/IP still runs on UDP 47808 and Modbus TCP on 502, so the port and certificate changes are not what breaks equipment communication.
Frequently Asked Questions
Does every JACE have to be replaced?
No, and the part usually missed is that N4-capable is not the same as current-N4-capable. Some models will run N4 but are capped at an early N4 release by their memory, which means they cannot sit on the Niagara version the rest of the site standardizes on. Check the supported Niagara version for each model, not only whether N4 runs on it at all. A site that standardizes on a current release will replace those units eventually, and knowing which ones they are up front puts that on a schedule of your choosing.
Do we have to be on AX 3.8 before migrating?
Yes, and the AX-to-AX upgrade that gets you there is a project step in its own right. The starting point section above covers what it depends on and where it commonly stalls.
What happens to trend histories and alarms?
They can be brought across, but that is a choice with a storage cost rather than something the conversion does for free, and the section above covers the tradeoff. Make the call before the conversion runs, since revisiting it afterward means repeating the longest part of the job.
What does a test conversion actually produce?
A converted N4 station and a migration log, and early on the log is the more useful of the two. It lists what could not be converted, component by component, which turns a general worry about incompatibilities into a finite list you can work through. That is the reason to run a test conversion while the plan is still being written rather than as the first step of executing it.
What do you need from us before the work can be scoped?
Station backups, plus a platform summary for each host: model, Niagara version, and the modules loaded. Beyond that inventory, two decisions belong to you rather than to the migration itself, namely how much history retention you actually need going forward, and which graphics get rebuilt versus retired. Sites commonly carry Px pages for equipment that no longer exists, and rebuilding those in N4 is effort spent on screens nobody opens.