MXH · For whoever runs the project

Your scope, your route and your definition of done, all from the system itself.

You get a scope read straight out of your Maximo, measured numbers for whether to go in one hop or two, and a fix list where every item carries a test someone else can check. No interviews, no guessing, no "done" that means somebody said so.

Scope from what is actually there

Every item names the object, field, class or control it came from, and the file and line in your code that touches it. Nobody has to remember what got customised in 2014. It is either in the export or you told us you could not send it, and both show up on the report.

The list arrives already split by who fixes it. In the published example, 99 items break down as 84 for the customisation developer, 8 for the database / migration, 7 for the application designer / configuration. That is your work breakdown, before you write one.

Direct or in steps

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.

So go in steps if you need a shorter outage, a rollback point, or more testing time. Those are good reasons. The list stays the same either way, and a change met in two stages can need building, deploying and checking in both.

Knowing when something is actually finished

Each item comes with a test, not a status field. "The customisation compiles against the new version with no missing imports." "A record can be created through every route on the new version." Someone who did not do the work can check it.

Re-run it against the fixed system, using the first report as the comparison, and you get four piles: fixed, changed, still open, and new. The original is kept. An item cannot vanish between reports, and a fix that broke something else turns up as new rather than as silence.

The count is yours, the estimate is your team's

The report counts the exact places that need changing, so your team can size it against what they know about your environments and change windows. We do not invent a day figure, because a number we made up is one you would get held to.

It also lists anything it did not look at, so a quiet section actually means something.

Send the right person to the right page