MXH · Documentation

What MXH checks today, and what is next.

Use this page to see what an assessment reads, what every finding contains, how a run is reproduced, which Maximo releases and add-ons are represented, and which capabilities are still on the roadmap. Built and planned work are kept separate throughout.

MXH is not installed in Maximo. It reads an export. Nothing is deployed into your system, no automation script runs in your JVM, and nothing touches production.

BUILT NOW — shipped and working today.

Read your Maximo. Compare it with the target. Return every disagreement.

MXH reads the Maximo setup you send and compares it with the exact release you are moving to. It covers your data setup, your customisation code and your classic Application Designer screens, and hands back every place your system and that target disagree. It reports what the evidence you sent supports, and says what it did not check.

1. Supply: send the data setup, customisation code and screens you want assessed.
2. Compare: run those inputs against the exact Maximo release you are targeting.
3. Act: work from findings that are graded, evidenced, owned and closable.

Three ways to run it. Start with whichever you can send this week.

A full audit is the most thorough, and it is not the only way in. Each mode below produces a real report; the narrower ones simply say so about what they did not receive.

A partial send is a first-class run, not a degraded one. Send what you have now and add the rest to a rerun — the second report is compared against the first, so nothing you already closed gets re-litigated.

Three parts of your system go in.

• Data setup — the structure and configuration supplied for assessment.
• Customisation code — the local code whose assumptions need to survive the target release.
• Screens — classic Application Designer screens checked against what the target accepts.

If you do not send something, or the comparison does not cover it yet, the report says so. A quiet section never stands in for proof that your system is clean.

What to export, and where it comes from.

A competent Maximo admin puts this together in well under a morning. If it is taking a week, the blocker is a policy queue rather than the work.

• The data dictionary — five tables: MAXOBJECT, MAXATTRIBUTE, MAXRELATIONSHIP, SYNONYMDOMAIN and ALNDOMAIN. Read-only SELECTs, one CSV per table with a header row. A REST fetcher ships with the product if you would rather pull it over the API than run a database export, and a lower environment that matches production customisations is the better place to take it from.
• Structure, not records. The export is your schema — object and attribute definitions. No work orders, no assets, no business rows. Worth saying twice, because it is the first thing a security review asks.
• Your customisation code — custom Java, automation scripts, or both. Compiled-only is fine: a JAR is read the same way as source. If what is deployed and what is in source control disagree, say so in the manifest rather than picking one.
• Your screens — the Application Designer presentation XML exports. Classic screens are what the comparison reads today; role-based screens are named as not received.
• A manifest — the release you are on, the target, the add-ons installed, the export date, and anything you are holding back with the reason. A manifest that contradicts itself fails the run rather than quietly producing a report against the wrong baseline.

You do not need to export reports, KPIs, cron tasks, escalations, workflow definitions or security options. MXH already compares the configuration IBM ships across those thirteen kinds, from its own packs, and flags the ones your code names — so an export of them changes nothing in the report.

What it does not reach is configuration held only in your database and never named in the code you send, your own security-group grants, and menu placement. There is no input for those yet, so sending them today changes nothing either. Every report names that boundary rather than leaving it implied.

Every finding carries four separate decisions.

• Severity: will this stop the system, require review, depend on the environment, or sit outside the assessment?
• Confidence: 6 evidence classes keep a certain observation separate from a probable interpretation.
• Owner: the row names who fixes it, so the project does not have to argue about it.
• Closure: a specific, checkable condition proves the item is fixed; a status field by itself does not.

Severity and confidence never collapse into one score. A serious but uncertain finding must not read like a certain failure, and a well-evidenced minor observation must not be inflated into a blocker. Read the evidence classes or inspect the finding shape in the sample assessment.

Send a JAR and it still gets checked.

A customisation you only have as a build artefact is assessed exactly like one you have the source for. Your code is never decompiled, never turned back into source and never executed. No JDK is involved, and nothing is installed on your Maximo.

The answer is the same every time: two runs over the same JAR agree down to the byte.

Where the release knowledge comes from.

Every fact MXH compares against is drawn from material IBM publishes and from the shipped product itself — release documentation, the upgrade scripts that come with a release, and the release's own declared definitions. Each finding cites the specific thing it came from, so you can go and read the source yourself.

What the product carries is facts about those releases: names, types, lengths, signatures, and what a given upgrade script changes. IBM's files, code and documentation text stay with IBM. MXH is not an IBM product and implies no IBM endorsement.

The same inputs produce the same assessment.

Every supplied input is fingerprinted. Repeating an assessment over the same inputs produces byte-identical output rather than a merely similar report. After remediation, compare the new run with the original: every finding is classified as resolved, changed, still outstanding or newly appeared. The earlier record remains visible, so an item cannot quietly disappear between reports.

Coverage is tied to explicit release data.

The current integration package represents 5 Maximo release lines, 10 package-defined release moves and 18 industry add-ons. The baseline can provide graded release-to-release numbers before customer code is supplied, and industry add-ons can be included where their package data is represented. Where a release is not available, the page says so.

Those are the dictionaries. The level you move from is a separate question, and on classic Maximo it is a short list: IBM lets you move to Maximo Manage from Maximo Asset Management 7.6.0.10, 7.6.1.2, 7.6.1.3 only, and from IBM Control Desk 7.6.1.5 with Maximo Asset Management 7.6.1.3 for Maximo IT. No Manage image ships a dictionary for any of them, so each is priced from IBM's upgrade scripts alone — 9 moves, every finding script-stated. The numbers are on the hub, and IBM's own page is the upgrade checklist.

Use the interactive release and add-on explorers for the package-derived detail behind these totals.

A full assessment produces 7 deliverables.

• Executive brief — the decision-ready summary.
• Technical report — every finding, owner, required action and closure condition.
• Evidence appendix — the evidence behind each finding.
• Tracking spreadsheet — findings in a format a delivery team can own.
• Machine-readable findings — the assessment as structured data.
• Plain-text rendering — a stable form for diffing between runs.
• Signed run record — the fingerprinted record of exactly what was checked.

Every report also states what it did not inspect. The absence of findings only has meaning when the assessment boundary is visible.

The same assessment answers a different question for each seat.

• Executive sponsor — should we commit?
• Programme manager — what is in scope?
• Maximo lead — what changes for my users?
• Technical lead — how is this verified?
• Business Partner — how do I scope this before I have access?

The configuration IBM ships is compared, not just the dictionary.

Reports, KPIs, cron tasks, escalations, workflow definitions, security options, applications, system properties, actions, communication templates, integration objects, endpoints and document types. Thirteen kinds, compared line by line, and a difference your own code names becomes a finding.

What is not compared is stated in every report rather than left implied: configuration held only in your database and never named in the code you send, your own security-group grants, and menu placement. Those need your configuration export, the way the dictionary export brings your dictionary in.

What fires an automation script is checked, not just what it does.

Launch points are a declared input. The object and column a launch point fires on, and every variable bound to an attribute, are checked against the target exactly as a plain attribute is.

A script whose code has not changed a character is caught when the column its trigger binds to is gone or has changed shape. No scan of the source can see that.

A baseline composed from several industry add-ons at once.

An assessment folds in as many add-ons as you run, in a declared order, so the starting point is the system you actually run rather than base Maximo plus 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, and names the query you run to read it off the system.

A binding followed through a relationship path.

Screen fields and script variables alike are followed to a real object at any depth, and every finding is graded by which graph answered each hop.

A path your own relationship rows answer is graded like any other binding. A path needing a hop from the shipped graph says so and never blocks. A hop nothing answers is reported unresolved with the hop named, rather than resolved against the wrong object.

Prove it closed, after the upgrade.

Run the assessment again once you have moved and every finding comes back closed, not closed, or could not be checked, with the lines that say what was looked at.

Closed means the finding was looked for again in the evidence it was read off and is not there. A surface nobody supplied is never a closure, so a finding that vanished because nobody sent that evidence the second time is never reported as fixed.

MXH integration package 1ebe50b82a3d281d