An AX-to-N4 migration is a project, not an upgrade — and the part that hurts is rarely the conversion itself. It is discovering, midway through, that a module has no N4 equivalent, that a graphics package needs rebuilding, or that a controller cannot run N4 at all. Nearly all of that is knowable in advance, if anyone has the time to inventory it properly.
Status: product concept, in active development. This is something we are building, not something you can buy today. We publish our roadmap because the engineering thinking behind it is the useful part — and because we would rather show you the design than imply a finished product.
Designed Capabilities
- AX station and module inventory — know exactly what is installed before committing to a date.
- Driver, graphics and history assessment — the three areas that generate surprise effort.
- Unsupported-component identification — surface the blockers first, not last.
- Migration plan and effort model — a defensible estimate instead of a hopeful one.
- ORD and reference conversion — the mechanical work, automated.
- Graphics and configuration transformation — convert what can be converted, flag what cannot.
- N4 deployment packaging — a repeatable, reviewable cutover artifact.
- Post-migration functional validation — prove points read, commands work and alarms behave.
The Validation Half Matters Most
A migration that looks finished but was never systematically checked is how a comfort complaint becomes a 2am call. Automating the verification — every point, every command, every schedule — is what makes a staged migration genuinely safe. The approach is described further in our article on what an AX-to-N4 migration actually involves.
Tell us if this matches a problem you have — early input shapes what we build first, and we will give you an honest view of where it stands.
Related services
- Niagara Migration Services (AX to N4) — Migration work we deliver today, while the accelerator is in development: AX-to-N4 migration services.
What the Assessment Needs Before It Can Say Anything
The inventory and assessment steps are only as good as what they are given, and the design assumes they work from engineering data rather than from a live connection into a running station. That means a current backup of each AX station and Supervisor, the module list actually installed on each platform rather than the one the as-built drawings claim, the Niagara version and build each station is running, and the model and firmware level of every controller. Hardware detail is not optional. Whether a given controller can run N4 at all is the finding most likely to change the shape of the project, and it cannot be inferred from the station file alone.
Licensing is the second input. AX licenses do not carry forward, so the device counts, driver entitlements and point capacities in force today set the floor for what has to be licensed under N4. A station that quietly grew past its original scope through years of added devices surfaces here as a licensing question before it surfaces as an engineering one, which is the right order for it to arrive in.
The third input is human judgment and cannot be automated. Someone who knows the site has to say which parts of the existing station are still in use. Stations accumulate: schedules nobody follows, alarm classes routed to staff who left, graphics for equipment that was removed years ago. An inventory can list all of it and can flag what looks unreferenced, but it cannot decide what matters. That call stays with the customer, because dead engineering carried forward is scope nobody chose to take on.
How the Work Is Sequenced
The order is deliberate: assessment across the whole estate first, then a plan, then conversion and validation station by station. Assessing everything before converting anything is what keeps a blocker found at one JACE from invalidating an estimate already given for the rest. It is also the only point at which the unsupported-component list is cheap to act on, because nothing has been rebuilt around it yet.
Per station, the intended sequence is convert, package, deploy to a target platform, validate, then cut over, with the existing AX station left in place as the reference until validation passes. The packaged deployment artifact matters more here than it looks. If a cutover has to be backed out early on a Monday morning, the difference between a repeatable package and a set of remembered Workbench steps is whether the rollback is a decision or an ordeal.
How long a mixed AX and N4 estate can be allowed to run is a site-specific question, not a general one. It depends on the version pairing between the Supervisor and the stations that have not moved yet, and on what the integrations above the Supervisor expect to talk to. Establishing that early is what decides whether the migration can be spread out or has to be compressed, and it belongs in the assessment rather than in the middle of the work.
What Passes Conversion and Fails in Operation
The failures worth designing against are the quiet ones. A conversion that errors out is visible and gets fixed. The expensive case is engineering that converts cleanly, starts without complaint and is still wrong: an ORD that resolves to a component that was renamed, a PX page that renders with a binding that no longer updates, a BQL query in a report that returns an empty set instead of an error, an alarm class that converted structurally but routes to a recipient definition that no longer exists.
Schedules and histories have their own version of this. Special events and holiday exceptions can survive a conversion in form while losing the behavior somebody actually relied on, and history collection can restart cleanly while the archive it was supposed to continue sits orphaned under an old reference. Nothing in the station reports a problem. The building runs, slightly wrong, until someone notices.
It is also the argument for validating against what the AX station actually did rather than against what the documentation says it should do. A checklist written from design intent will pass a station whose converted behavior differs from the original in ways the design intent never described, because the intent was never that specific. A captured before-state gives the comparison something concrete to be wrong against.
When an Accelerator Is Not the Right Answer
Tooling of this kind earns its place on estates that are large, unfamiliar, or both. Several situations do not fit, and it is worth saying so plainly rather than stretching the idea to cover them.
- A single station with a handful of drivers and graphics that an engineer already knows well. The inventory and effort model exist to make an unfamiliar estate tractable. Where someone can enumerate the work from memory in an afternoon, the assessment step is describing what they already know.
- Sites where the controllers are being replaced rather than migrated. If the hardware is leaving, the useful outputs are a point list and a sequence description for the new system, not a converted station.
- Graphics that are being redesigned to a new standard anyway. Converting a package that is going to be discarded is work with no destination. The inventory and validation work still applies; the graphics transformation does not.
- Stations that depend on custom modules with no N4 build and no available source. Tooling can identify the dependency and name it early, which is worth something. It cannot resolve it. That is a vendor conversation or a decision to re-engineer the function, and no amount of conversion automation shortens either.
- Estates where the real problem is not the migration. If the complaint is that the sequences never worked properly under AX, moving them to N4 preserves the problem in a newer framework. That is engineering scope, and folding it into a migration makes both harder to judge.
Frequently Asked Questions
What is the AX-to-N4 Migration Accelerator, concretely?
It is a planned set of tooling that wraps an AX-to-N4 migration end to end: inventory of what is actually installed, assessment of drivers, graphics and histories, identification of components with no N4 equivalent, an effort model, mechanical ORD and reference conversion, deployment packaging, and automated post-migration validation. It is not a one-click converter and not a replacement for Niagara Workbench, which is still where an engineer does the work tooling cannot do. It is also not a license, a controller upgrade path, or a substitute for the judgment about what should carry forward at all. It is in active development and is not something that can be bought or deployed today.
What would it run on, and what has to already exist?
The design assumes a working Niagara engineering environment on the customer side: Workbench, current station backups, platform credentials held by the customer, and target hardware plus N4 licensing for the stations that are moving. The accelerator is designed to operate on engineering data, meaning station backups, module lists and platform details, rather than to sit in the runtime path of a live building. Nothing in the design removes the N4 licensing or controller hardware requirements set by the framework itself. Since the product is still being built, none of it is installable yet.
How is rollout designed to proceed, in order?
Assessment comes first across every station in scope, producing the inventory, the unsupported-component list and the effort model, before any conversion happens. The migration plan then sets the station order, typically starting with the Supervisor and with a station whose disruption would be easiest to absorb. Each station is then converted, packaged, deployed to a target platform, validated against the behavior of the AX station it replaces, and only then cut over, with the AX station kept available until validation passes. That sequence describes how the product is meant to be used, not a rollout that can be scheduled now.
How would it integrate with the Niagara systems we already run?
Through the artifacts Niagara already uses rather than through a parallel system: station backups in, converted stations and reviewable deployment packages out, in forms Workbench and normal N4 deployment can consume. Third-party integrations under the stations, such as BACnet, Modbus and LonWorks, are treated as part of the driver assessment, since a driver that exists in both AX and N4 can still differ in configuration and behavior. Anything consuming data above the Supervisor, including reporting, analytics or an enterprise front end, is an integration to inventory during assessment, because those consumers tend to break on renamed references rather than on the migration itself.
Where does station data go, and what stays under our control?
The design intent is that station backups, credentials and site data stay with the customer, and that the tooling works against copies the customer provides rather than reaching into live stations on its own. Platform credentials remain the customer's to hold and use, and nothing in the design requires standing access to production controllers. The outputs, meaning the inventory, the assessment, the effort model and the packaged station, are files the customer keeps and can review independently of us. This is stated as design intent for a product under development, not as a description of something already operating.
What do we have to provide, and what do we have to decide?
Provide: current backups for each station and Supervisor, the installed module list per platform, controller models and firmware levels, and current licensing detail. Decide: which existing engineering is still in use and can be dropped, whether graphics are converted or rebuilt to a new standard, which stations move in which order, and what an acceptable cutover window looks like for each building. The first list is a collection exercise. The second is a set of judgments about the site that only the people who run it can make, and it is where the schedule actually lives.
Does any of this apply to a site that is already partly on N4?
Yes, and the design assumes that case rather than treating it as an exception. An estate can easily sit across more than one version: a Supervisor may already be on N4 while JACEs are still on AX, or one building may have moved during a separate project. Assessment is scoped to the whole estate for that reason, since what matters is which version pairings have to coexist and for how long, not a single before and after state. A partial migration can also mask the unsupported-component problem, because the stations that were straightforward to move are the ones likely to have moved already.