For most of the last twenty years, an enterprise Maximo programme had a recognisable shape. Two or three years of budget, a defined start and end, a business case that landed its benefits on go-live, a steering committee tracking a Gantt, and a systems integrator paid against milestones. That shape survived the move from Maximo 6 to 7, and it survived the 7.5 and 7.6 refresh cycles. It has not survived the move to MAS. The Maximo programme, in the form procurement and finance still recognise, is quietly over. Most steering committees have not been told.
This piece takes a position: the multi-year, benefits-at-the-end Maximo programme is a category error on MAS. The platform now ships change continuously, licenses subscription-first, and rewards persistent product teams over discrete project delivery. Estates that keep procuring, funding, and steering as if none of that had happened are underperforming ones that have quietly switched to product mode.
What changed under the programme
Three IBM decisions, taken over the last two years, have already reshaped what a Maximo programme is.
The release cadence has stabilised on an annual major, with a formal 3+1+3 support lifecycle. Under this model, each major MAS release gets three years of standard support, one year of extended, and a further three of sustained coverage, with a new major roughly every twelve months. That replaces the previous pattern of two or three releases a year and a lot of ambiguity about which version an estate was actually on. MAS 9.2 went GA on 25 June 2026, on schedule.
Between those majors, Maximo Manage runs on a continuous delivery stream. The Feature Channel makes new capability available in non-production instances before it lands in the maintained release, which means an estate that pays attention receives a steady flow of function through the year rather than a single lump every eighteen months. The Feature Channel is not a preview toy: it is where a customer can form a considered view of the next set of changes on their own configuration before those changes reach the maintained release.
The commercial layer has moved with it. SaaS accelerators announced in April 2026 let selected customers take six-month subscription trials of adjacent applications such as Envizi, Inventory Optimization and Renewables without a full procurement cycle. That is a very different buying motion from the perpetual-licence-and-annual-support pattern most Maximo estates were built on.
Add to that the pace at which agentic and AI-led features are landing inside Manage, Health, and the wider suite, and it is clear that the platform is now delivering material change every quarter, not every three years. The programme shape that most boards still recognise was designed around a stack that did not do that.
Where the mismatch bites
The mismatch is visible in four places. Each of them is expensive.
The business case is the wrong shape. Traditional Maximo business cases were written as J-curves: heavy spend for eighteen to twenty-four months, benefits after go-live, payback across the next three to five years. On MAS, capability lands every quarter, and the largest benefits are usually a compound of many smaller changes: a Feature Channel item plugged into a work management flow, a Health score wired into a capital paper, an agentic assist embedded in a start centre. A J-curve business case cannot capture that. It undervalues the platform in year one and over-promises a single-point benefit that is not the way value actually arrives.
The steering committee is watching the wrong artefact. A monthly project board reviewing a Gantt is a governance model for a bounded project. MAS estates have a rolling backlog: version uplifts, Feature Channel adoption decisions, integration updates, security patching, model version changes, tenant configuration. A project board reads that backlog as scope creep. It is not. It is the operating model.
Procurement is buying the wrong deliverable. Most Maximo statements of work still describe a discrete implementation with fixed milestones and a warranty period. That worked when the destination was a stable configured Maximo 7.6 estate on WebSphere. It does not describe an operator’s actual need, which is a partner who curates the platform continuously against a moving base. Estates procured that way end up either overpaying for change requests or letting the platform drift, because the delivery contract has nothing to say about the ten items IBM published last quarter.
Benefits realisation is quiet on the wrong axis. Programme business cases usually measure benefits against pre-implementation baselines: work order throughput, PM compliance, unplanned downtime, mobile adoption. Those measures still matter, but on a continuously delivered platform, the more interesting question is whether the estate is absorbing new capability at the rate the licence entitles. An estate on MAS 9.0 that has not adopted anything from the 9.1 or 9.2 stream is paying for a platform it is not using. No traditional benefits tracker captures that.
What product mode looks like on Maximo
The alternative is not novel. It is the operating model that other enterprise platforms, notably ERP and CRM, have already converged on. Applied to Maximo, it has a few defining features.
- A persistent product team, not a project team. A named product owner for MAS, a small standing platform team, and defined access to functional and integration specialists. Reforming the team every eighteen months for the next initiative is more expensive, not less.
- A rolling roadmap replacing a scoped scope-of-work. Twelve to eighteen months of intent, refreshed quarterly, aligned to the MAS release calendar and the Feature Channel stream. IBM’s own publication of that calendar makes this easier now than it was two years ago.
- A design authority that governs Feature Channel decisions. Every Feature Channel item is a real design choice: adopt now, adopt at GA, adopt later, or decline. That choice belongs on a live register with the same weight as an Application Designer change or an integration contract change.
- A standing budget envelope, not a series of project cases. The organisations that get this right treat MAS as opex-first: a subscription platform with an annual envelope for change, sized against the roadmap, reviewed with finance quarterly. That is a different conversation from the one that starts with a five-page paper each time something new is needed.
- Benefits captured on a quarterly cadence. Small, defensible, evidenced against the actual change that landed. Regulators are already asking for this shape of evidence in sectors such as UK electricity transmission under RIIO-3. It is more credible than a single year-end review, and it produces better inputs to the capital cycle.
None of that requires new tooling. It requires the sponsor to redraw the governance around what MAS has already become, rather than around what an on-premise Maximo 7.6 programme used to be.
The position to take
The platform is no longer a project. Buying MAS on a project-shaped contract, governing it in a project-shaped steering committee, and reporting it in a project-shaped benefits case leaves visible value on the table, because the platform ships change faster than a project cadence can absorb. It also leaves audit exposure on the table, because the change register drifts out of sync with the record of what has actually shipped into production.
The organisations that redraw the operating model deliberately, ideally at the same procurement moment that they commit to MAS, spend less over five years and end up with a more current estate. Those that keep the old shape usually end up owning a three-year programme for five, and starting the next one before the current one has settled. On the evidence of the last eighteen months of MAS releases, that gap is widening rather than closing.
For sponsors thinking through what this means for their own MAS estate, our note on why upgrades keep becoming re-implementations covers the technical drift that most naturally translates into a case for product-mode delivery.
Sources
- IBM Documentation: What’s new in the Maximo Application Suite Feature Channel
- IBM Support: Maximo Application Suite Feature Channel
- IBM Community: Explore new outcomes with six-month Maximo Application Suite SaaS accelerators (April 2026)
- ISO 55001:2024 Asset management, management systems, requirements