Planning a Maximo 7.6.1.x exit before 30 April 2027

The two dates that fix the target

IBM states that Dual Support for IBM Maximo Application Suite with IBM Maximo Asset Management ends on 30 April 2027. EAM 7.6.1.x will no longer be supported after that date for Subscription Upgrade customers, and for Perpetual Trade-Up customers EAM usage rights expire — continued use would be out of compliance. That is a governance date as much as a technical one.

The target is fixed by two more IBM statements. Effective 30 April 2026, MAS releases 8.10 and 8.11 moved to IBM Extended Support and the lifecycle completed for 8.7, 8.8 and 8.9. And on 23 June 2026 IBM announced that MAS 9.0.x transitions to Extended Support on 1 July 2027 — ten weeks after the classic side stops. Landing on 8.x or 9.0 therefore buys almost nothing. The move is 7.6.1.x to MAS 9.1 or 9.2, and the deadlines page on the Upgrade Desk counts the days from each IBM source.

A re-platform, not a version bump

RMI is not supported in Maximo Manage; REST API is used instead for interactions from custom extensions or external applications in the containerized environment. Every integration or tool that reached Maximo over RMI is a rewrite, not a re-test.

Maximo Manage 9.1 runs on Java 17. IBM recommends recompiling Java customisations with Java 17 and states that migrating Manage from Java 8 to Java 17 requires diagnostics and testing. IBM also states the Java move itself introduces no functional change — that line is about the platform, not about your MBO extensions.

Manual deployment and installation-script deployment of applications are discontinued from MAS 8.10, so the estate is deployed and upgraded through operators. In the Collaborate component 9.1 CouchDB is replaced with MongoDB, and Maximo Optimizer requires MongoDB before deployment. And MAS is licensed in AppPoints, with usage divided into reserved and concurrent and the Suite License Service holding the licence — consumption modelling belongs before the contract.

What IBM says to do before you start

IBM's upgrade checklist for Maximo Manage names five workstreams: version compatibility and upgrade paths; Java version changes and customisation recompilation; OpenShift cluster requirements; database backup and integrity validation; customisation and integration testing. Treat it as the table of contents for the plan.

Before you start the upgrade, IBM says to review your current database settings, disable custom triggers, commit any pending configuration changes, and back up the database and other important system files. Run the Integrity Checker before the upgrade to identify and fix database integrity issues. Understand how authentication, security and SMTP are implemented, and migrate customisations by using customisation archives.

One statement is specific to this move: when upgrading from Maximo Asset Management 7.6.1.3 or earlier to Maximo Manage in MAS 9.1, the cron, mea, report and ui server bundles for Manage are installed. Verify the exact source fix level IBM supports for content migration for your estate — that is a level-dependent question this guide asks rather than answers.

Known traps, each with its record

After the EAM upgrade to Manage, the Integrity Checker has been reported to raise errors — schedule a post-migration run rather than a pre-migration one only. In repair mode it can produce an exception due to auto-commit. After a Maximo version change a new report development environment reflects the updated BIRT version and newer MXReport classes, and some reports failed to show all expected data until re-tested.

User Data Services is deprecated and replaced with IBM Data Reporter Operator starting in MAS 9.0, 8.11.7 and 8.10.10; from 9.0 you must migrate. If you land on 9.2: user synchronization is removed for every application except Maximo Real Estate and Facilities, the User synchronization status page and MASUSERSYNC are gone, and the user and group management APIs deprecated in 9.1 are removed. Anything that provisions or audits users needs the 9.1 APIs and the relational store.

Db2 12 on MAS 9.2 is opt-in, requires a valid Db2 Warehouse licence file, needs a complete backup first, and is irreversible. Plan it as its own change with its own go/no-go.

A twelve-month shape — practitioner interpretation

What follows is how practitioners typically sequence this move; it is interpretation, not an IBM statement. Baseline the estate now: automation scripts by launch point, custom Java with its source, object structures and endpoints, customised presentations and reports, and the exact fix level. That list prices everything. Stand up the MAS platform and the AppPoints model before year end so the licence conversation closes with the budget, not after it.

Use the first quarter of 2027 for the RMI-to-REST rewrites, the Java 17 recompile and test, the UDS-to-DRO move, and a full rehearsal on a production-sized copy with a measured window and one executed rollback. Cut over in March, keep April for the rehearsed fallback, and retire the classic environment before 30 April — for Perpetual Trade-Up customers that retirement is a compliance item, not housekeeping.

Keep it cited on the Upgrade Desk

The Upgrade Desk composes this move from the published record: the break-class findings at 9.0, 9.1 and 9.2, the change log in range, the gotchas for the target line, the curated Change Watch entries, the industry plan, and the verify questions with Ask pre-filled. The checklist page turns it into ticks that export as Markdown with a sources appendix, and the deprecation register lists what was removed or renamed and what IBM says replaces it.

Nothing on those pages asserts an upgrade matrix. Where the answer depends on your level, the page asks the question and Ask answers only from cited records — or says it cannot.