AXScripting / AX Groovy (legacy scripting in Niagara AX)

Niagara AX is still running buildings – and its scripting is still holding them together. AXScripting and the Groovy-based logic in legacy AX stations were written years ago by people who have often moved on. Software Pile maintains, repairs, and eventually migrates that code so the building keeps running while you plan its future.

Legacy AX Work We Handle

  • Reading, documenting, and repairing existing AXScripting and Groovy logic nobody on staff understands anymore
  • Keeping AX stations serviceable: fixing broken sequences, adding points, and adjusting logic without a full rebuild
  • Assessing what the scripts actually do before an AX-to-N4 migration, so nothing is lost in translation
  • Reimplementing legacy script logic cleanly in N4 when the time comes

The Migration Question

AX is end-of-life, and everyone knows it – but “rip it all out” is rarely the right first move. We keep AX stations healthy today and build a migration plan that moves logic to N4 on your schedule, with the scripts understood and documented before they are touched.

Tell us about your AX stations – version, scope, and whether you are maintaining or migrating. We handle both.

What Was AxScripting?

AxScripting brought scripting — commonly Groovy — into Niagara AX stations, letting engineers write logic in script form rather than assembling it entirely on the wiresheet. It was useful for calculations, data manipulation and integration behaviour that would have been awkward as blocks.

It belongs to the AX generation. If you are running scripts in AX today, they are one of the specific things that needs an explicit decision during an AX to N4 migration — they do not simply carry across.

What Happens to AX Scripts in an N4 Migration?

Each script needs a decision, and the decision is rarely automatic:

  • Reimplement as a Niagara module. Logic that matters and will persist is usually better expressed as a proper component built on the Baja API — version-controlled, signed, testable and visible to engineers.
  • Rebuild on the wiresheet. Some scripts exist only because a block did not exist at the time. In N4 there may now be a native way.
  • Retire it. A meaningful share of legacy scripts serve equipment that is gone or a report nobody reads. Migrating them is pure cost.
  • Replace with tagging and query. Scripts that exist to work around inconsistent naming are often better solved by tagging and BQL.

Why Legacy Scripts Are a Migration Risk

Scripts are the part of a station most likely to be undocumented, written by someone no longer available, and quietly load-bearing. They frequently encode business rules — a billing calculation, a compliance threshold, an override for one difficult tenant — that exist nowhere else.

Inventory them before the migration, not during. For each: what it does, what it touches, who depends on the output, and whether anyone would notice if it stopped. That last question retires more scripts than any technical analysis.

Should You Use Scripting in N4?

Where a genuine scripting requirement exists, evaluate it against the alternative of a compiled module. Scripts are quick to write and easy to change, which is their appeal and their risk: they are also easy to change without review, hard to version, and easy to lose track of.

For anything durable or business-critical, a signed, version-controlled module is the safer home. Reserve scripting for genuinely local, low-consequence behaviour — and write down what it does.

Related services: AX to N4 migration services · custom module development.