Niagara AX to N4 is not an upgrade you run and walk away from. The station converts, but the parts around it — third-party modules, graphics, hardware, integrations and user accounts — each have their own answer, and those answers determine whether the project takes a weekend or a season. Here is how to scope one honestly before committing to a date.
Step 1: Inventory Before Estimating
Nothing sensible can be said about effort until you know what is actually deployed. That means, per station:
- Exact Niagara AX version and build, plus every installed module and its version.
- Hardware model and resource limits — older JACE hardware may not run N4 at all, which turns part of the project into a hardware replacement.
- Every third-party and vendor-specific module, with its N4 availability confirmed by the vendor rather than assumed.
- Point counts and licence limits, which change how N4 licensing is sized.
- Graphics: how many Px pages, how much custom Hx, and how much depends on browser plugins that no longer exist.
- Integrations out of the station — reporting databases, third-party front ends, oBIX or API consumers.
The inventory is where most surprises live. A station that looks routine often carries one unsupported module that dictates the whole approach.
Step 2: The Four Things That Usually Cost the Most
Unsupported modules
A module with no N4 equivalent leaves three options: replace it with a supported alternative and accept behaviour changes, rebuild the functionality as a custom N4 module, or keep that station on AX for now. This decision drives the schedule more than any other.
Graphics rework
Older AX graphics frequently depend on browser technology that modern browsers no longer run. Converted pages may open but behave differently, and anything built for a plugin-based client needs rebuilding for HTML5. Budget graphics as its own workstream, not a rounding error on the station conversion.
Hardware
Where controllers cannot run N4, migration becomes a replacement project with field work, re-addressing and re-commissioning. Finding this in the inventory is inconvenient; finding it during a cutover weekend is much worse.
Users, permissions and history
N4 handles security and roles differently. Accounts and permission structures generally need reviewing rather than copying, and history migration deserves an explicit decision: bring everything, bring a window, or archive and start clean.
Step 3: Sequence for Reversibility
Convert a copy of the station in a lab first — never the live station as a first attempt. Verify the conversion, fix what breaks, and document the exact steps. Then pilot on one real site, ideally the least critical, and only then roll out. Keep the AX station recoverable at every stage, with a tested backup and a documented rollback, until the N4 station has run through a full operational cycle including alarms, schedules and reports.
What Good Looks Like at the End
- Every point that existed before is still reading, and history is continuous or its gap is documented and agreed.
- Alarms route to the right people, and schedules survived the conversion intact.
- Graphics work in current browsers on the devices operators actually use.
- Integrations still receive data, and anyone consuming the old interfaces has been migrated deliberately rather than discovering the change.
- The customer holds current backups, documentation and the licensing detail they need to be independent of any one contractor.
The Short Version
The station conversion is the predictable part. Modules, graphics and hardware are where the schedule is decided, and all three are knowable in advance from a proper inventory. Any migration plan that has not enumerated the modules is a guess.
Related service: Niagara AX to N4 migration services
Version Baselines and What Talks to What Mid-Migration
The migration path assumes a specific AX starting point. Supported source versions have narrowed across successive N4 releases, so a station on an older AX build is usually stepped up within AX first, and that AX to AX step is its own small project with its own module compatibility check. Confirm the accepted source versions against the migration documentation for the N4 release you are targeting, not against what worked on a previous job.
A NiagaraNetwork spanning both versions is normal during a rollout, and the compatibility runs one way. An N4 Supervisor can carry AX 3.8 subordinate stations within the limits the release documents; an AX Supervisor cannot carry N4 stations at all. Within the live rollout, once the lab conversion and the pilot are behind you, that asymmetry sets the order: the Supervisor has to move before the stations under it, or each converted JACE drops out of the Supervisor's network as it comes back up.
Both Workbench versions live on the engineering workstation for the duration. They install into separate directories with separate user home folders, so an AX station still being engineered and an N4 station being commissioned do not collide. Which N4 Workbench build performs the conversion matters too, because the station it produces targets that build; converting on one release and deploying on another adds a variable you do not need while you are still fixing real breakage.
Reading What the Conversion Actually Reports
The migration log is the authoritative module inventory. It enumerates every module the station actually references, including the ones pulled in indirectly by a component nobody remembers adding, and it is more reliable than a list compiled from the host's modules directory or from what the engineering team remembers installing.
The log separates three cases that usually get treated as one: a module with a direct N4 counterpart, a module whose counterpart exists at a different version, and a module with nothing on the other side. Components whose types cannot be resolved come through as tombstones that keep the original type name and property values, so the station still opens and the gaps sit visibly in the tree instead of disappearing. Counting tombstones by type turns the log into a repair list ordered by how much of the station each missing module actually touches.
Custom modules are their own case. An AX module is not an N4 module with a new name; it has to be recompiled against the N4 API and split into the parts N4 expects, with runtime code in the rt part, browser code in the ux part and Workbench views in the wb part. A driver ported as runtime only will poll and produce data while leaving nothing in Workbench to configure it with, which presents as a broken driver and is an incomplete port. Later N4 releases also require modules to be digitally signed, so an unsigned in-house jar that loaded on an earlier build is refused on a newer one.
Whatever the case, each unresolved or uncertain entry needs a record of its own before anyone can scope it:
- Per module: the vendor, the N4 module name if one exists, its version, and whether it ships with the framework or has to be obtained separately.
- Per module with no counterpart: which components use it and how many, which Px pages reference those components, and what the station does if that function is simply absent.
- Per module that resolves at a different version: what changed in between, because a module that maps cleanly can still shift defaults such as poll rates, unit handling or alarm behavior.
Licensing Is Per Host and Nothing Is Inherited
An N4 license is issued against the host ID of the machine or controller that runs the station, and it is a new license rather than an AX license with a flag changed. Each host needs its own N4 license file and the matching certificate in place before the converted station will start. Controllers report their host ID from the platform; a Supervisor's host ID comes from the machine underneath it, so moving a Supervisor to a new server or a new virtual machine as part of the project makes it a new host that has to be licensed again.
The date on the license is the second thing that stops a station. A Niagara license carries a software maintenance expiration, and the build you install has to have been released before that date. A host that runs one N4 build and refuses a later one is usually reporting that date rather than a missing feature, and the place to check is the license, not the platform.
A license is a list of feature entries, not a single number, and the entries do not follow the station across by inheritance. Every driver and protocol in use is its own entry, and an N4 license contains only the entries someone asked for when it was generated. A station missing an entry generally starts anyway: the driver loads into a fault state and its points stop updating, which looks like a network problem and is not one.
What the Security Model Change Does to Accounts and Integrations
In N4, permissions attach to roles and roles attach to users. The AX arrangement, where a user carried its permissions directly, has no equivalent, so every account has to land in a role on the way across. An approach that gives each distinct AX permission set its own role produces a station that works and a permission model nobody can maintain, and consolidating those into a small number of real roles is far easier before cutover than after. Passwords do not travel either, so every account needs a new credential issued through whatever process the site already uses.
The accounts that matter most here are usually not people. Reporting databases, third-party front ends and oBIX consumers all authenticate as station users, and those users need roles like any other. N4 does not use HTTP Basic authentication by default, so a client sending basic credentials is rejected until a basic scheme is configured and assigned to that specific user. That single setting is a common cause of an integration that stops working the morning after cutover while the station itself looks healthy.
Transport defaults moved as well, and it is the ports that differ, not only the policy:
- Fox uses 1911 in plaintext and Foxs uses 4911 over TLS. N4 stations are normally set to accept the TLS port only, so a peer station or tool pinned to 1911 does not connect at all.
- Platform connections follow the same split: 3011 plaintext, 5011 over TLS.
- HTTP on 80 and HTTPS on 443 behave the same way. An integration with http:// hard-coded against the station's oBIX or web endpoint fails closed once plaintext HTTP is disabled.
- Each host generates a self-signed certificate. Clients that validate certificates need that certificate in their trust store, or a signed certificate installed on the station, and this is the step most often discovered last.
When Rebuilding Beats Converting
Conversion is the default because it is mechanical and repeatable, but it is not the only route. Rebuilding means engineering a new N4 station from scratch against the same field devices and the same point list, with nothing carried over from the AX database. The choice is per station rather than per site: a site can reasonably convert most of its JACEs and rebuild the rest, as long as the reasoning is written down per station.
The test is what proportion of the station survives conversion untouched. A station built from standard framework components, with drivers that all have N4 counterparts and graphics assembled from stock widgets, converts and leaves a punch list. A station whose logic depends on a module with nothing on the other side, whose graphics were drawn for a client that no longer exists, and whose custom driver has nobody behind it is being re-engineered whatever the process is called.
Rebuilding has its own bill. It gains nothing from the tool's mechanical accuracy, so point naming drifts unless the AX point list is exported and used as the source, and the commissioning effort returns in full on every station that takes this route. On the rebuild path, histories do not come across, so archiving or exporting them before the AX station is retired is the only option left open. Rebuilding is the better call when several of these hold at once:
- The control logic already needs revising for reasons that have nothing to do with the migration.
- The graphics are being redrawn for current browsers anyway.
- Point naming and folder structure are inconsistent enough that reports and BQL queries are already unreliable.
- The custom modules in use have no vendor behind them and no source to port.
- The station has accumulated years of disabled, orphaned and duplicated components that a conversion would carry forward faithfully.
Frequently Asked Questions
Is this the same thing as upgrading Workbench or updating a controller's platform?
No. Upgrading Workbench on an engineering PC and updating a controller's platform software are host-level operations that leave the station database alone. The migration converts the station itself, together with the modules it depends on, its graphics, its accounts and everything pointing at it from outside. The host-level work is a prerequisite for the migration, not a substitute for it.
What exactly should the copy of the station be?
A station backup taken from the platform, or a full copy of the station folder made with the station stopped. Copying a running station's folder gives you a database captured mid-write, and a conversion that fails on it tells you nothing about the real station. Take the modules directory from the same host at the same time, including any vendor jars that are not part of a standard install, because the conversion resolves against what was actually deployed rather than what should have been.
Does anything on the field side of the controller have to change?
Usually not. BACnet, Modbus and LonWorks integrations keep their addressing and their wiring because the protocols themselves are unchanged; what changes is the driver module above them, its license entry, and anything consuming the station's own interfaces. That holds only while the controller stays in place. A controller being physically replaced changes the answer entirely.
What does the owner have to decide, as opposed to the integrator?
Four things that are not the integrator's call to make alone: the credential policy for the new accounts and who gets which role, whether each integration cuts over with its station or runs in parallel for a period, whether hardware that still runs but is near end of life gets replaced now or later, and which operator workstations and browsers have to be supported. The last one drives graphics work more than any other single input, because it sets what the graphics have to run on. These are worth settling before the pilot, since each one changes what the pilot is supposed to prove.
A page renders in Workbench but not in a browser. What does that mean?
It means the widget exists as Workbench code and has no browser implementation in the module that supplies it. N4 renders graphics in the browser from the ux side of a module, so a widget with only a Workbench part appears in Workbench and leaves a gap in the browser. If the same page fails in both places, the problem is one level down: the module did not resolve at all, and the components on the page are tombstones.
Do alarms and their recipients survive the conversion?
Alarm classes and the links between them and their recipients convert with the rest of the station. What does not convert is anything holding a credential, including the account used to send alarm email, so routing can look correct in the tree while nothing actually leaves the station. Force a real alarm on each class after cutover rather than inspecting the configuration, because a silent email failure and a correctly quiet system look identical from the station side.
Is there a case for leaving a station on AX?
Yes. A station that is functionally complete, has no pending integration work and runs on hardware that is not near end of life can stay where it is for a while, and the budget goes to the stations that are actually blocked. What is worth being explicit about is that the cost of staying rises on its own: browsers keep dropping what older graphics need, replacement parts for AX-only hardware get harder to source, and any new integration has to be built against the older API. The decision is how long, not whether.