A pattern has settled into the IBM Maximo upgrade market. A programme is scoped as a technical upgrade, often from Maximo 7.6.1 to MAS Manage. The business case is written around a version step, a platform refresh, and a managed roll forward of existing configuration. Eighteen months later the same programme is, in substance, a re-implementation: new screens, revisited workflows, rebuilt integrations, retrained users, a fresh look at master data. The leadership team is asking why the upgrade became a transformation.
This is not a story of poor execution. It is a structural property of where Maximo upgrades sit today. The technical surface area between 7.6.1 and MAS Manage is not the same surface area an EAM upgrade used to cross. Treating it as an upgrade in the way the previous decade understood that word is what produces the drift. The honest framing is to plan for re-implementation behaviour from day one, then decide which parts of the estate genuinely justify being lifted forward.
The drift pattern
The drift can be described in stages.
The programme is funded as an upgrade. The Maximo 7.6.1 estate is in extended support, the dual entitlement window for MAS is closing in April 2027, and the obvious story for the steering committee is a version step. Scope is written around the licence trade-up, the move to OpenShift, and a like-for-like roll forward of Manage configuration. Integrations are assumed to be re-pointed rather than rebuilt.
Discovery starts and the story becomes longer. The 7.6.1 estate has years of accumulated configuration, much of it undocumented. Several integrations are point to point and have drifted from any published specification. The mobile footprint is a mix of supported and bespoke. Automation scripts encode decisions nobody remembers making. Custom applications carry business logic that was never written down. Master data has known quality issues the business has learned to work around in the screens.
Design starts and the story shortens again. Bringing the bespoke applications forward as is would leave the estate in the same state on a new platform. The custom mobile build will not survive the move to the supported MAS Manage mobile pattern without rework. Integration drift is cheaper to rebuild than to reverse engineer. The Graphite UI, available since 7.6.1 and now the strategic UI in MAS, forces a screen-by-screen review anyway. By the time the design authority signs off, the programme is doing the work of a re-implementation while still using the language of an upgrade.
That language costs the programme governance. The board is reviewing an upgrade tracker. The team is delivering a re-implementation. The two are not the same kind of risk.
What changed under the upgrade
It is worth being precise about why the technical surface area is now what it is.
The platform changed shape. Classic Maximo through 7.6.x ran on traditional application servers such as WebSphere. MAS runs on Red Hat OpenShift. That is a different operating posture: clusters, namespaces, operators, ingress, certificates, storage classes, and an upgrade cadence driven by the operator pattern. The infrastructure work is real even on a managed cloud, and the handoff to the team that will run the platform on day 401 is materially different from classic Maximo.
The suite, not the application, is the unit of decision. Maximo Manage is now one product inside MAS, alongside Health, Monitor, Predict, Assist, and Visual Inspection. Even programmes that only intend to deploy Manage on day one are buying into the suite licensing and platform pattern. Architecture decisions on identity, integration, observability, and data flow have to anticipate the rest of the suite, or the estate is stranded at the next decision point.
The UI question is overdue. The Graphite UI based on the Carbon Design System was introduced in Maximo 7.6.1, around 2019, and is the strategic UI in MAS. Classic JSP screens still render in MAS Manage but are in maintenance mode. Most 7.6.1 estates carried Classic forward without revisiting screen design. The move to MAS forces that review, because role-based start centres, application designs, and conditional UI sit on top of the same Application Designer that has been in the product since Maximo 6, with a different visual contract.
Integrations have drifted. Integration Framework objects, publish channels, enterprise services, and invocation channels written years ago against an ERP, a historian, or a finance system have accumulated quiet workarounds. The counterpart endpoint has often been upgraded, sometimes more than once. Reusing those integrations as is when the platform around them changes is a known route to surprise.
Master data has not stood still. Asset hierarchies, locations, classifications, failure codes, and meters have been edited by hundreds of users over years. A successful MAS estate, especially with Health, Monitor, or Predict on the roadmap, asks tighter questions of that data than 7.6.1 did. The data work an upgrade pretends to defer is the same work an APM business case will need later, and it is cheaper to do once.
What carries forward, and what does not
A useful design discipline on a MAS programme is to sort the estate into four buckets early and write the plan against them. The pattern recurs across the managed Maximo estates the team supports.
- Lift. Well documented, stable, used as designed, not implicated in the data work. Domains, application configuration that is genuinely fit, supported automation scripts, integration objects that match a current endpoint contract. The smallest bucket in most estates.
- Lift and clean. Fundamentally sound but carrying debt: PMs that flood the queue, job plans with duplicated tasks, classifications that have drifted. Rebuilt against current intent, because the new platform deserves the cleaner version. The argument is set out in the piece on Maximo PM design that does not flood the work order queue.
- Redesign. Anything that has to be revisited because the platform now expects something different. Mobile, start centre design under Graphite, role-based security, integrations where the counterpart has changed, master data structures that AI and APM modules will consume. The bucket that turns the programme into a re-implementation.
- Retire. Configuration added for a reason that no longer applies, custom applications that are quietly unused, scripts that solved a problem long since solved by the product. Most 7.6.1 estates have more here than the sponsor expects.
Sized honestly, the four buckets give the steering committee a picture that matches the work the team is doing. A larger Lift bucket means a faster, cheaper programme that inherits more debt. A larger Redesign bucket means a slower, dearer programme that exits in a stronger position. What is not defensible is pretending Redesign does not exist.
Naming it correctly changes the programme
The argument is not that every Maximo customer should commit to a full re-implementation. Plenty of 7.6.1 estates have enough discipline, documentation, and alignment with the supported MAS Manage patterns that a tighter upgrade is the right call. The argument is that naming the work correctly changes how it is governed.
A programme called an upgrade is reviewed against schedule and cost variance. A programme called a re-implementation is reviewed against benefits realisation, organisational change, and target operating model. The latter is the conversation most MAS programmes need from the start. The benefits a sponsor expects from MAS, suite-wide AI capabilities, condition-based maintenance, asset health visibility, depend on data and process work that an upgrade frame does not naturally fund.
Operators that frame the move honestly make a small set of decisions early that pay back later. They invest in the data work before cutover. They retire what they can defend retiring. They choose supported patterns for mobile, integrations, and reporting rather than carrying bespoke ones forward. They size the change effort against a re-implementation curve. The estate that lands at the end is one a managed service can run cleanly, and one the rest of the suite can be added to without a second programme.
The pattern is not a failure mode. It is the shape of the work. Programmes that name it as such finish in better health than programmes that fight the framing until cutover.