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.