Niagara AX is legacy. Ongoing development, security updates and driver support are all on N4, and the pool of people and tools that still work comfortably with AX keeps shrinking. Migration is not optional indefinitely — the only real question is whether it happens on your schedule or during an emergency.
We plan and deliver AX-to-N4 migrations as staged projects with a way back at every step, not as a weekend conversion.
What a Migration Actually Involves
- Station and module inventory — exactly what is installed, before anyone commits to a date.
- JACE hardware assessment — some controllers cannot run N4 and must be replaced. Better known at week one than week six.
- Driver and integration validation — every BACnet, Modbus and LonWorks integration confirmed on N4.
- Graphics rework — usually the biggest surprise. Legacy Px graphics often need rebuilding for N4’s HTML5 environment; we scope it explicitly rather than discovering it mid-project.
- Scripting and custom logic review — legacy AX scripting does not always transfer one-to-one.
- Staged cutover — converted and validated in a test environment before production is touched, with the old system recoverable until the new one is proven.
- Point-by-point verification — every input reads, every command works, every schedule and alarm behaves.
Why the Verification Half Matters Most
A migration that looks finished but was never systematically checked is how a comfort complaint becomes a 2am call. We verify the migrated system against the original before anyone depends on it, and we tell you what we found rather than reporting a clean sweep by default.
The reasoning is set out at length in our article on what an AX-to-N4 migration actually involves. The tooling we are building to accelerate the assessment stage is described under solutions in development.
Tell us what you are running today — Niagara version, station count and controller models — and we will assess the path to N4 and what it realistically costs.
Related services
- Niagara Framework Development — Back to the full Niagara Framework development overview.
Whether This Is a Conversion or a Rebuild
The distance between an AX station and its N4 equivalent is not the same at every site, and that distance decides what kind of project this is. Where the station was built from stock drivers, the logic lives in wire sheets, the graphics were assembled from standard widgets, and the hosts can carry N4, the station converts largely intact and the effort concentrates in graphics and verification. That describes many of the systems we are asked about. It does not describe all of them.
The distance widens with everything in the station that was custom. Program objects carrying real sequence logic, Px pages built with hand-written bindings, and third-party modules all move work out of conversion and into rebuilding. Past a certain point the honest description changes: this is not a migration of an existing system, it is a new system that reuses the field wiring and the devices, and it is better scoped and priced that way at the start than discovered in the middle.
There are also sites where converting now is the wrong order of operations. If the controllers are due for replacement inside the same capital cycle, if a controls replacement is already scheduled, or if the point list has drifted far enough from the building that a real share of what converts describes equipment that is gone, then the conversion is spending effort on a station that is about to be superseded. Cleaning up a station is a separate decision from moving it to N4, and doing the cleanup first means the verification only has to cover points that still exist.
What the Work Depends On From Your Side
Most of the assessment stage is asking for things that already exist somewhere on your side. The items below are the ones that have to be chased down when they are missing, and chasing them is slower than the conversion work itself, because they usually sit with a person or a company rather than in a file.
- A current platform backup of every host, taken before anything is touched. A copy of a station folder pulled off a file share is not the same thing, and the difference only shows up at the moment a restore is needed.
- An AX release the conversion tooling accepts. A site below that line has to be stepped up within AX first, which is its own change with its own verification, and it belongs in the plan rather than at the front of the conversion week.
- Working platform and station credentials for every host, including the ones nobody has logged into since commissioning. A JACE whose platform password is unknown is a site visit and a rebuild of that host, not a conversion.
- Clarity on who holds the licensing. Licensing follows the host ID and the brand of the host, so a replaced controller means new licensing rather than a file moved across. Where a distributor or the original integrator administers it, that relationship has to be live before a schedule means anything.
- Someone who can say what the logic is supposed to do. Program objects and legacy AX scripting can be read, but intent cannot always be recovered from the code, and a sequence that was quietly wrong under AX will be quietly wrong under N4 unless somebody names it.
- Any third-party or OEM module compiled against the AX API has to be rebuilt for N4 by whoever wrote it. Where the vendor is gone or no N4 build exists, the integration has to be replaced rather than migrated, which makes it a scope decision rather than a technical one.
- A decision about which graphics still matter. Pages get built and abandoned, and carrying an abandoned page forward costs the same as carrying one people open every morning.
- What the operators actually use to look at the system. Wall displays running at fixed resolutions and layouts sized for the old Workbench window are the two that get discovered late.
Replaced Hardware Sets the Shape of the Schedule
When the hardware assessment says a host has to be replaced, the software half of the project is not the part that changes most. What leaves the wall with that controller is more than the station: the licensing tied to it, the network address and any firewall rules written against that address, the driver commissioning underneath it, and in some cases the IO modules and the mounting.
That turns a line on a software project into a procurement and field-labor item, with lead times and an electrician's calendar attached, and it is the part of the plan least able to absorb a late discovery. It also reshapes the phasing, because a host being replaced cannot be converted in place; it has to be treated as a new commissioning that happens to inherit an existing point list. That is the entire argument for doing the hardware assessment before dates are promised.
Frequently Asked Questions
What does the migration actually convert, and what does it leave alone?
It converts the station database, the modules it depends on, the graphics and the logic from the AX runtime to N4, and it moves each host onto N4 platform software. The work is done in Niagara 4 Workbench against a copy of your station rather than against the running one. What it does not do is change your control strategy: a sequence that was wrong under AX arrives wrong under N4, and a point that was never commissioned properly stays that way. Rewriting sequences is separate work and is named separately rather than folded into a conversion line.
Do our BACnet, Modbus and LonWorks devices have to be touched?
The field devices themselves are not converted. They keep speaking their own protocols, and what gets validated is the station's driver connection to them: that the N4 driver discovers and addresses the same devices, that points map to the same objects, and that writes land where they used to. Device firmware and field wiring sit outside the migration unless the assessment turns up something already broken, in which case you hear about it rather than having it quietly absorbed into the conversion.
What happens if we cannot produce one of the things the conversion needs?
The order of the work does not change; the schedule does. Missing items are almost always waiting on a person or a company rather than on engineering, which means they run on someone else's response time and not on ours. That is why they are started at assessment instead of at cutover, when a two-week wait on a license reissue lands on top of a booked outage window. If an item cannot be produced at all, it becomes a scope decision and is put in front of you rather than worked around silently.
Can this be done in stages, or does the whole site move at once?
Staged wherever the topology allows it, host by host rather than site-wide, so the blast radius of any one step stays small and a new problem is traceable to the thing that just changed. Ordering runs from the hosts with the fewest dependencies toward the ones everything else leans on, with the Supervisor's position in that sequence set by whether a mixed AX and N4 network is workable for the releases in play. A site where every controller hangs off a single host has no stages available, and that is worth establishing early, because it changes the shape of the cutover rather than just its length.
What does N4 run on, and what changes for the people who use the system?
Stations run on JACEs that support N4, and the Supervisor runs on a server rather than on a controller, with operating system and Java requirements set by the Niagara release rather than by us, so an existing Supervisor machine may or may not qualify and gets checked during the hardware assessment. The larger change is on the operator side: N4 serves its interface over HTML5, so workstations reach the system through an ordinary browser session instead of the old client plugin. That takes the plugin out of the workstation build, and what replaces it as a question is which browsers and which displays your operators are actually using.
How does N4 connect to the other systems we already run?
Through the same kinds of interfaces the station offers today, but every one of those connections has to be re-pointed and re-tested rather than assumed to survive the move. Anything consuming data from the station is a separate integration with its own credentials and its own address: an oBIX client, a supervisory BACnet/IP system, a dashboard, an energy or analytics platform pulling histories. The item that catches people is that N4 defaults to encrypted connections, so a client that was polling over an unencrypted port needs either TLS support on its own side or an explicit decision about that connection, along with whatever firewall change follows from it.
Who has access to our system during the work, and where does our data sit?
Most of the work happens against a copy of the station on our side rather than on your live system. Access is typically whatever you grant over your own remote access method, on accounts you create and can disable, and we do not typically need ownership of your licensing or your platform accounts. Your stations, histories, graphics and licensing stay on your hardware; what we hold is the working copy and the assessment notes, and anything a particular engagement needs beyond that is named before work starts rather than requested midway.
You mention tooling for the assessment stage. Can we use it?
No. That tooling is in development, it is not something that can be bought or deployed, and no part of the migration service depends on it. It is designed to shorten the inventory work by reading a station backup offline and listing what is installed, instead of someone opening each host and writing it down. Until it exists, the assessment is done by hand, which is how it is being done today.