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