216 days to the end of Maximo 7.6.1.x Dual Support · IBM source · Start an assessment

MXH · Maximo upgrade assessment

Your Maximo upgrade is a diff. mxh runs your customisations against every release and tells you which lines of that diff are yours.

Evidence-driven Maximo upgrade intelligence across versions — connecting IBM product changes to what they mean for your Maximo.

What the sample found

99 findings from 4 exported objects and 3 source files · 7.6.1.3 → 9.2.

1 BLOCKING · 90 REVIEW · 8 ENVIRONMENT · 99 findings, from 4 assessed objects and 3 scanned source files.

Where to start

What it does

You send an export of your data dictionary, your customisation source and your Application Designer screens. MXH compares them against the release you are moving to — IBM's own upgrade scripts, the target's compiled API, the target's screen definitions and the target data dictionary — and returns every place your system and that release disagree. Each disagreement is graded, attributed to an owner, and carries the test that closes it.

It also compares the configuration IBM ships on top of the dictionary — reports, KPIs, cron tasks, escalations, workflow definitions, security options, applications, system properties, integration objects — and flags the ones your code names. It follows a screen field or a script variable through a relationship to the object at the far end. And it checks what fires each automation script, not only what the script does: a script whose code has not changed a character still breaks when the column its trigger binds to is gone, and no scan of the source can see that.

It reads 7.5.0, 7.6.1.1, 9.0, 9.1, 9.2: 1,161–1,866 objects per release, and 129,079 attributes counted across those 5 releases together (not one release), taken from the packs the product ships and tests against rather than from a document about them.

More than one add-on, composed into one baseline

Sites rarely run a single add-on. MXH composes several into one baseline rather than analyzing base Maximo in isolation, which misses the conflicts between add-ons that only surface once they are combined — so the starting point of the comparison is the system you actually run, not a guess.

Where two add-ons put the same column on the same object, the report says which definition applies and why. Where install order decided it and no IBM artefact records which one won, it says that instead of picking — you read that one off the system, and the report names the query. The same applies to the implementing class on a shared object: no add-on's install script declares one, so a composed profile marks it unknown rather than inventing it.

Proving it closed, after the upgrade

Every finding already carries the test that closes it. Run the assessment again once you have moved and each one comes back closed, still open, or not checked — against the same run identity, so the second report is about the same system and the same claim.

Not checked is a real answer and it is used. Some closure tests are actions on a running Maximo — which definition install order left behind, what a value now means to code with a new type under it — and no reading of an export can perform them. A finding that vanished because nobody sent that evidence the second time is never reported as fixed.

Check our evidence against IBM's, yourself

The API facts every Java finding rests on are read from IBM's own compiled classes, and that set is re-checked against IBM's shipped release on demand. Each check writes a dated receipt saying what was checked and whether anything differed.

Run against every MAS release MXH assesses to, each with a dated receipt: 9.0 (11,997 classes, 73,861 members), 9.1 (12,040 and 74,275), 9.2 (12,651 and 79,377), no difference on any of them. It is a check that can fail, and your own engineer can run it.

The code itself is held to the same standard. On 26 September 2026 the whole MXH test suite ran with IBM's own classes and libraries in place of MXH's compile-time stand-ins, for every release MXH ships, 7.5.0 through 9.2: 373 tests, no failures, on every one of them.

The principle

For a full audit of your Maximo, you send your data dictionary, your customisation source and your screens. For a Business Partner or System Integrator sizing a prospective client, you only need their current release and their installed add-ons — the standard library already carries 129,079 base attributes across 5 releases and 18 add-ons, so a real bound on the project exists before a single line of the client's code is on the table: 10 moves pre-computed, 129,079 base attributes indexed across 5 releases, 18 industry solutions, 6 evidence classes.

For Business Partners and System Integrators: you can size a client's upgrade from three things they will tell you on a call — their current release, their target, and the add-ons they run. The standard library returns real, graded blocking and review counts from those alone, so a pre-sales estimate rests on measured numbers before anyone signs anything.

Every finding is graded

NOT ASSESSED isn't a grade. It marks what a run didn't check, and it's never counted among the findings. Stated on every report, so a clean result's meaning is bounded.

Every report names its own boundary, in the report itself. That is what makes a clean result worth something: you can see precisely what was checked, and take the all-clear at face value.

What a move raises, before you send anything

MXH can assess every release-to-release move from its own dictionaries, with no customer data involved at all — 10 moves, plus 9 assessed from IBM's upgrade scripts alone for releases no image ships a dictionary for. 71 script-stated changes. The same list direct, via 9.0 or via 9.1.

7.6.1.3 → 9.2. Distinct changes, combined across each route. Delivery effort, testing, downtime and supported-route prerequisites are assessed separately.

What IBM's own upgrade scripts state on this move, counted as distinct findings and as a union across the legs rather than a sum. Every leg is scripts only, so the legs and the direct move are the same kind of evidence (A1). A scripts-only finding is graded for review until the customer's own code, screen or configuration is found to name it, which is why this row counts what is stated rather than what is blocking. It counts which changes a route raises, not the effort to deliver them: a change met in two stages can need building, deploying and verifying in both. Risk, downtime windows, rollback safety and testing effort are assessed separately.

These are base-release numbers. Yours differ, because yours include your customisations — which is the entire point of running it on your own system.

Know a client's current release? This is their real number

An RFP names the client's Maximo release and the target they want. That pair alone — before a single line of their code or an installed solution is on the table — already has a real, graded answer: every move between the six releases mxh ships is computed here, with no customer data at all.

Once you know which industry solutions they run, fold those in with --solutions and the same move gets sharper. Send their actual dictionary, code and screens and it becomes the number that names their own files and lines.

If the client is on classic Maximo, start here instead

IBM lets you move to Maximo Manage from Maximo Asset Management 7.6.0.10, 7.6.1.2 or 7.6.1.3, and from IBM Control Desk 7.6.1.5 with Maximo Asset Management 7.6.1.3 for Maximo IT. Those are the levels a real classic client is on when they start, and no Manage image ships a dictionary for any of them, so each is priced from IBM's upgrade scripts alone. Every finding below is script-stated: IBM's own script says the column is gone.

A dictionary comparison is absent from these numbers rather than empty, which is why they sit apart from the table above. Source: IBM Docs, Upgrade checklist.

The releases it reads

18 industry solutions, and what each one really adds

Install one on top of Maximo and it is not a plugin sitting beside your data — it changes your dictionary. New tables, and new columns on tables you already have. mxh reads all 18 that IBM ships, so a customisation reading one of these columns is never mistaken for a customisation reading a table that does not exist.

Two names, one dictionary: hse and oilandgas ship an identical set of tables and columns, marked above rather than counted as two separate things. These are the current release's numbers — a solution is one IBM snapshot, not a version history, so this states what it adds, not how it has changed over time.

"On tables you already have" is where a solution's columns can collide with your own customisations — the ones you'd never think to check, because the solution barely does anything. 5 of the 18 (envizi, oracleadapter, sapadapter, tririga, workday) bring no table of their own at all — every attribute they add is on shared ground. Combined, that's 104 attributes, 0.7% of the total footprint here: small enough to be the one nobody checks.