Why move from Java customisations to Automation Scripts?

Java extensions from the 7.x era are expensive to test and are revalidated at every upgrade for as long as they exist. Automation Scripts are the supported way to extend Maximo, they are visible inside the application, and they carry forward far better. The saving is in what you stop carrying, not in the rewrite itself.

Do you rewrite everything as Automation Scripts?

No. Every item gets one of the four verdicts above, decided on evidence: what consumes the output, how often the records it touches change, and which role can still explain the rule. A meaningful share of a long-running inventory is serving a process that has since changed.

What happens when nobody knows what a customisation was for?

That is the normal case rather than the exception. We establish what the code does, where it is invoked from and what consumes its output, then look for evidence of use, then ask the people who do the work. Where intent cannot be recovered we do not guess: it becomes a decision, taken by a named owner with the evidence in front of them, and recorded as a decision.

How do you prove behaviour was preserved?

By comparing outputs. Old and new implementations run over the same extract of live records in a lower environment and the results are compared row by row. Where the two disagree, the disagreement is usually informative: it tends to show behaviour the original code produced by accident, which is then a decision for the business.

Should we modernise before an upgrade or after it?

Assess before, deliver either side. The assessment has to come first, because which items travel is an upgrade decision, and revalidating code you were going to retire is the most avoidable cost in the programme. See Maximo to MAS upgrade and Maximo 7.6 Extended Support.

How long does an assessment take, and what does it produce?

A fixed-scope assessment produces a countable inventory: every Java extension, Automation Script, extension point and bespoke report, with its invocation points, its consumers, its last change date and a proposed verdict with an effort class. Duration follows the size of the inventory, and the deliverable is the register the delivery waves are then planned from.

How is the work delivered once the verdicts are agreed?

In waves, through the same controlled promotion route as any other change, with MaxIron Change Control holding the production gate and MaxIron Pipelines carrying the build. Each wave leaves behind the rule, the owner and the comparison evidence, which is what outlives the people who ran it.

Does modernisation reduce our licence cost?

No. It changes the cost of owning and upgrading your extensions, not what you pay IBM. Licence and AppPoint questions are a separate exercise, covered on MAS AppPoints and licensing.

Customisation modernisation

Every custom item leaves with one verdict and a name against it.

Enterprise Maximo estates carry Java extensions written across a decade, mostly by people who have moved on. Establishing what each item was for is the work that takes judgement, because that decides whether it is retired, met through configuration, or rewritten as an Automation Script. Below is one item, taken the whole way.

Get a modernisation assessment See MAS upgrade services

The artefact

One item from an ordinary inventory, field by field

Written seven years ago, still running, and doing two jobs that deserved different answers.

ASSET_PRIORITY_CALC, Java extension, 412 lines

5 of 6 fields changed

Field	Before	After	Set by
WHAT_IT_DOES	Derives a maintenance priority from criticality and a condition field, writes it to a custom attribute, then emails a distribution list whenever the value changes.	Derives the same priority from the same two fields and writes it to the same attribute. The email path is gone.	Planners confirmed the rule. The control room team behind the distribution list was reorganised in 2019.
WHERE_IT_LIVES	A Java class on the asset object, deployed in the EAR, readable by whoever can reach the source.	An Automation Script against a supported extension point, visible in the application to any Maximo administrator.	MaxIron developer, reviewed by your platform lead.
OWNER	None recorded. The author left in 2018 and the supplier contract ended in 2021.	A named reliability engineer, recorded against the item on the register.	Confirmed at the decision session, with the date.
CONSUMERS	Two BIRT reports and one start centre KPI read the derived attribute. Nothing reads the email.	The same two reports and the same KPI, verified against the rebuilt environment.	Traced from the object structure and the report definitions. Unchanged by design.
EMPTY_CONDITION	Records with no condition value were handled by accident rather than by design.	An empty condition falls to the default priority, decided by the planners and written down for the first time.	Planning supervisor, at the comparison review.
COST_TO_CARRY	Revalidated and regression tested at three upgrades since 2018, plus one incident investigation.	One readable script on the regression pack. The email path is off it entirely.	Register row, closed with a date.

Illustrative and composite: the shape of an item a MaxIron assessment produces.

How the verdict was reached

Seven steps from the inventory line to the signed decision

The same seven run on every item. Step two is where the programme is won or lost: what the code does can be read, and what it was for has to be traced.

ASSET_PRIORITY_CALC, assessment to proof

Inventory scan: A Java class on the asset object, 412 lines, last changed seven years ago, with no entry in the customisation register your team keeps.
MaxIron developer: Traces the invocation points and the consumers. Two BIRT reports and a start centre KPI read the derived attribute. Nothing reads the email.
Planning supervisor: Uses the derived priority every day and states the rule more clearly than the code does. The distribution list belonged to a team reorganised in 2019.
The verdict, split in two: Rewrite the derivation as an Automation Script. Retire the email, because the process it served stopped existing before anyone currently on the account arrived.
Written to the register: Item, verdict, the reliability engineer who signed it, and the date. Deferred items are marked as deferred rather than quietly carried.
Comparison run: Both versions run over the same extract of live asset records in a lower environment. Two mismatches, both on records with an empty condition field.
What exists afterwards: One script, one retirement, and a note holding the rule, its owner and the two edge cases. One item to revalidate at the next upgrade instead of two.

Legend

Signal: Found in the inventory or produced by a run.
Person: Who looked, and who decided. Every verdict carries a name.
Maximo: What was written into the estate or onto the register.

The register vocabulary

Every item ends on one of four verdicts

A single customisation often attracts more than one, because a single customisation often does more than one job. Splitting it is usually the first useful step.

Retire: The requirement is gone: the process changed, the team reorganised, the report stopped being produced. This is the one verdict that lowers the upgrade bill permanently, and on estates with a decade of history it is the commonest.; Often read as deleting code nobody has looked at. Retirement needs evidence that no live consumer reads the output.
Move to configuration: The behaviour is a rule about who may do what, when, and under which conditions. That belongs on the configuration route, where an administrator owns it and the supported upgrade path carries it forward without revalidation.
Rewrite as an Automation Script: There is genuine conditional logic here. Automation Scripts have been part of Maximo since Maximo 7.5, they sit inside the application where they can be found, and they are the supported home for a rule of this kind.; Often read as a like-for-like port. The rule is restated, reviewed and given an owner on the way through.
Keep, deliberately: Some code does a job nothing else should do, and it works. It stays, with a named owner, a written statement of what it is for, and a place on the regression pack.; Often read as inheriting it. Keeping something on purpose carries an owner and a review date.

Name the one extension that gets flagged as a risk at every upgrade. We will run these seven steps on it and come back with a verdict and the evidence behind it, before you commit across the inventory.

Assess one item →

Boundaries

Three constraints on a modernisation programme

Each is worth settling now rather than in the middle of a wave.

Recovered intent has limits, and the register says where

Some items have no living witness, no consumer we can find, and no evidence of use either way. Those become an explicit decision, taken by a named owner with the evidence in front of them, so the next team inherits a judgement rather than a mystery.

Some behaviour stays as written code

Automation Scripts are the right home for most rules, and some items are best left exactly where they are. We rewrite where it reduces what you carry, and we name the items that fall outside that. Anything reaching another system belongs in Maximo integrations.

Proof rests on the evidence available

Where automated tests exist we use them. Otherwise we build comparison evidence from live records and name which cases were exercised. Where the old behaviour turns out to have been wrong, that is a decision for the owner rather than a defect to reproduce faithfully.

Usually assessed alongside

Capabilities that decide what should be code at all

Maximo configuration → Maximo to MAS upgrade → Maximo integrations → Database vendor conversion → Maximo 7.6 Extended Support → MaxIron Upgrade Factory → MaxIron Change Control → Service transition case study →

Customisation modernisation, frequently asked questions

Why move from Java customisations to Automation Scripts?: Java extensions from the 7.x era are expensive to test and are revalidated at every upgrade for as long as they exist. Automation Scripts are the supported way to extend Maximo, they are visible inside the application, and they carry forward far better. The saving is in what you stop carrying, not in the rewrite itself.
Do you rewrite everything as Automation Scripts?: No. Every item gets one of the four verdicts above, decided on evidence: what consumes the output, how often the records it touches change, and which role can still explain the rule. A meaningful share of a long-running inventory is serving a process that has since changed.
What happens when nobody knows what a customisation was for?: That is the normal case rather than the exception. We establish what the code does, where it is invoked from and what consumes its output, then look for evidence of use, then ask the people who do the work. Where intent cannot be recovered we do not guess: it becomes a decision, taken by a named owner with the evidence in front of them, and recorded as a decision.
How do you prove behaviour was preserved?: By comparing outputs. Old and new implementations run over the same extract of live records in a lower environment and the results are compared row by row. Where the two disagree, the disagreement is usually informative: it tends to show behaviour the original code produced by accident, which is then a decision for the business.
Should we modernise before an upgrade or after it?: Assess before, deliver either side. The assessment has to come first, because which items travel is an upgrade decision, and revalidating code you were going to retire is the most avoidable cost in the programme. See Maximo to MAS upgrade and Maximo 7.6 Extended Support.
How long does an assessment take, and what does it produce?: A fixed-scope assessment produces a countable inventory: every Java extension, Automation Script, extension point and bespoke report, with its invocation points, its consumers, its last change date and a proposed verdict with an effort class. Duration follows the size of the inventory, and the deliverable is the register the delivery waves are then planned from.
How is the work delivered once the verdicts are agreed?: In waves, through the same controlled promotion route as any other change, with MaxIron Change Control holding the production gate and MaxIron Pipelines carrying the build. Each wave leaves behind the rule, the owner and the comparison evidence, which is what outlives the people who ran it.
Does modernisation reduce our licence cost?: No. It changes the cost of owning and upgrading your extensions, not what you pay IBM. Licence and AppPoint questions are a separate exercise, covered on MAS AppPoints and licensing.

Bring the customisation nobody wants to touch.

Send a rough count of what is live and the one extension nobody can fully explain. We trace what it does, what consumes its output and which role can confirm the rule, then return the verdict with the evidence behind it. That is the assessment run on one item, before you commit to it across the inventory.

Bring this to the first call

A rough count of custom classes, Automation Scripts and bespoke reports live in production
The one extension that gets flagged as a risk at every upgrade
Your last upgrade assessment or regression pack, if one exists
The names of the roles that would have to confirm what each rule is for

Get a modernisation assessment See Maximo configuration