MXH · For whoever runs Maximo day to day

See exactly what changes for your users, your screens and your data.

You get a list in the language you actually work in: this field, that screen, this interface. Not versions and class names. Everything below is a real type of item from a real customer report, and each one names who fixes it.

Fields that change size

A field that held thirty characters now holds a hundred. Sounds harmless. It is not, if something pads it, cuts it short, checks its length, or sends it to another system that still expects thirty.

In the published example this was the biggest group by far: 53 of 99 items. Each one names the object and the field, and asks the same question. What in your setup assumes the old size?

Fields that stop being required, or start

This is a data quality problem, not a technical one. If a field stops being required, records start coming in without it, and every report and KPI that counted on it quietly drifts. If a field starts being required, everything that creates that record has to fill it in. Not just the screens your users see, but interfaces, scripts and data loads too.

Fields that are gone

A field you use that does not exist in the new version is a decision for the business, not for whoever runs the migration script. The data goes somewhere or it is accepted as lost. These get flagged and sent to whoever owns the database, not buried in a technical list.

Your screens

We check your Application Designer screens against what the new version will actually accept. A control, setting or field binding it will refuse gets flagged by name. A screen that silently fails to load on go-live morning is the most visible way an upgrade can embarrass you, and it is completely avoidable.

Who fixes what

None of this lands on your desk by default. Each item names its owner, whether that is a developer, whoever works in Application Designer, or the database team, and it names the test that closes it. So the conversation is about order of work, not about whose fault it is.

What it covers

It reads your data dictionary, your customisation code, your screens, and the new version's own code. It compares the configuration IBM ships on top of that too — reports, KPIs, cron tasks, escalations, workflow definitions, security options, applications, system properties, integration objects and more — and flags the ones your code actually 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 just what the script does.

What it does not reach: configuration held only in your database and never named in the code you send, your own security-group grants, and menu placement. Every report says so by name, so a quiet section never reads as a clean one.

Send the right person to the right page