Maximo Application Suite 9.2: AI Extensibility and the New Upgrade Playbook

On June 25, 2026, IBM moved Maximo Application Suite 9.2 to General Availability, and the headline was not a refreshed user interface. The headline was extensibility. MAS 9.2 treats AI not as a feature buried inside Maximo Assist, but as an integration surface that any organization can extend using the Model Context Protocol (MCP), agent skills, and a richer set of public APIs. For teams that have spent the last three years deploying AI features inside a closed product, this is the most significant architectural shift since Maximo moved to containers.

The release also ships with the operational refinements that long-term operators asked for: a unified dashboard for asset and location performance, a new Asset & Location Dashboard that ties together Health, Monitor, and Manage data, deeper condition-based maintenance (CBM) integration through Meters, expanded reliability scoring with Probability of Failure modeling, and the deprecation of a number of legacy components that have been on the watch list since MAS 9.0. Voice inspections and the search function inside Maximo Assist are now retired. MRO Inventory Optimization is no longer launchable from the Suite navigator. The Self Service Center application is being replaced by Self Serve, and the entire platform now runs on Java 25.

This article walks through what changed in MAS 9.2, why the architectural decisions matter, and how to plan an upgrade that protects production stability. The guidance is written for Maximo architects, MAS administrators, and platform engineers who need a defensible upgrade plan, not a marketing summary.

What Actually Changed in MAS 9.2

The most important change in MAS 9.2 is the introduction of a real extensibility layer. Instead of treating AI as a closed feature with a fixed set of pre-built capabilities, IBM has exposed MCP Server, agent skills, and a set of APIs that let you bring your own agents into Maximo-driven workflows. The agents do not just make recommendations, they participate in execution and coordination. That distinction is not semantic. It changes how AI integrates with existing operational processes, because agents can now invoke Maximo Manage APIs directly, with the same governance and security model that applies to human users.

The second major change is the unification of asset and location performance data into a single dashboard. The new Asset & Locations Dashboard in MAS 9.2 brings together matrix views, automated analysis, work history, and direct drill-down into sensor and inspection data. Health, Monitor, and Manage are no longer three separate views that operators have to switch between. They are now one dashboard with role-tailored APM cards. IBM has reported that score calculations are 10x to 20x faster in the new architecture, which matters when you scale Health scoring across a fleet of tens of thousands of assets.

The third change is a deeper integration of CBM. In MAS 9.0, CBM was a configuration exercise: you set up Meters, configured Monitor, and hoped that the data flowed correctly into Health. In MAS 9.2, the integration is native. Meter data from Monitor, work order history from Manage, and inspection data from Maximo Inspections feed Health scores automatically. The result is a tighter loop between detection and action.

Beyond these three pillars, MAS 9.2 also includes the following changes that matter for upgrade planning:

• A new Probability of Failure tab in the Score Settings application, which lets you fit Weibull parameters from historical data directly inside Manage without needing an external notebook.
• Lease Abstraction in Maximo Real Estate and Facilities, which uses retrieval-augmented generation (RAG) to extract key information from lease documents.
• The new Software Tracking application, which provides improved cloud-based compliance oversight for software lifecycle governance.
• A new Service Offerings application that lets any business unit design and publish service catalog entries, not just administrators.
• IBM MaaS360 integration for automated device discovery.
• Chat sound notifications, service bundling in Self Serve, and a Reliability tab in Service View.

The MCP Server and Agent Skills: What They Are and Why They Matter

MCP is a protocol for connecting AI models to tools and data sources. In MAS 9.2, IBM has shipped an MCP Server inside the platform. The server exposes Maximo Manage APIs as MCP tools, which means any MCP-compatible agent can call those APIs. The agent does not need to know anything about Maximo's internal API structure, security model, or authentication mechanism. It only needs to know which tools it can call and what arguments those tools expect.

The practical implication is that organizations can now build agents in their own development environment using their preferred framework, and those agents can call Maximo APIs as if they were calling any other tool. For example, an agent that monitors a real-time pricing feed can call the Maximo Manage API to update the unit cost of a spare part when the price changes, without any custom integration code. An agent that monitors weather data can call the Maximo Manage API to generate a preventive maintenance work order when a storm is forecast. The integration is generic, and the governance is enforced by the platform.

Agent skills are the second piece of the extensibility story. A skill is a packaged capability that an agent can use to perform a specific task. In MAS 9.2, IBM has published a set of pre-built skills for common Maximo workflows, including configuration guidance, data retrieval, reporting, and asset-condition insights. The Maximo AI Assistant has matured well beyond a chatbot, and the skills are the reason. Instead of being a single LLM with a system prompt, the assistant is now a router that dispatches to the appropriate skill based on the user's intent.

For organizations that want to build their own skills, MAS 9.2 provides an SDK and a set of development guidelines. The skills are written in TypeScript or Python, packaged as containers, and deployed through the standard MAS extension mechanism. Once deployed, the skills are available to the assistant, to external agents through MCP, and to other skills through the skill composition API.

Here is a representative MCP tool definition for a Maximo Manage work order query:

{
  "name": "maximo_query_workorders",
  "description": "Query work orders in Maximo Manage with optional filters",
  "inputSchema": {
    "type": "object",
    "properties": {
      "siteId": { "type": "string", "description": "Site identifier" },
      "status": { "type": "string", "enum": ["WAPPR", "APPR", "INPRG", "COMP", "CLOSE"] },
      "assignedTo": { "type": "string", "description": "Username of assignee" },
      "dateFrom": { "type": "string", "format": "date" },
      "dateTo": { "type": "string", "format": "date" },
      "limit": { "type": "integer", "default": 50 }
    },
    "required": ["siteId"]
  }
}

When an agent calls this tool, the MCP Server handles authentication, authorization, and audit logging. The agent receives a JSON response with the matching work orders. The agent does not need to know about LTPA tokens, SCIM, or the Maximo internal data model.

Pre-Upgrade Checklist: What to Verify Before You Start

The MAS 9.2 upgrade is not a routine patch. The platform version moves from 9.0.x or 9.1.x to 9.2.0, which means the upgrade touches the core operator, the data tier, the application tier, and every installed industry solution or add-on. The first step is to verify the current state of your environment.

Start by confirming the version of MAS Core, the version of every installed application, and the version of every installed add-on. MAS 9.2 requires all components to be at compatible versions, and the upgrade will fail if any component is on an unsupported track. The IBM support page lists the compatible versions for every release, and it should be the first reference you consult.

Next, verify the OpenShift version. MAS 9.2 requires OpenShift 4.16 or later, with 4.18 recommended for production deployments. If you are running on an older OpenShift release, you will need to upgrade OpenShift first, and the OpenShift upgrade is a separate planning exercise. The OpenShift upgrade typically takes longer than the MAS upgrade itself, so it should be scheduled first.

Then check the database tier. MAS 9.2 supports Db2 11.5.9 or later, Oracle 19c or later, and Microsoft SQL Server 2019 or later. The database must be on a supported version before the upgrade can proceed. For Db2 deployments, verify that the db2_workload=maximo setting is in place, that the WLM_ADMISSION_CTRL is set to NO, and that the monitor switches are turned off except for timestamp. For SQL Server deployments, verify that the compatibility level matches the previous Maximo database version, and that snapshot isolation is enabled.

Finally, audit your current customization footprint. MAS 9.2 changes several object structures, automation script behaviors, and integration endpoints. Any customization that depends on deprecated or removed features will need to be refactored before or as part of the upgrade. The most common examples include custom Anywhere extensions (which have been unsupported since MAS 8.9), customizations that depend on User Data Services (which was replaced by Data Reporter Operator in MAS 9.0), and any custom code that calls the Maximo Assist search or voice inspection APIs (which are removed in MAS 9.2).

The Upgrade Process: A Step-by-Step Roadmap

Once the pre-upgrade checks are complete, the upgrade itself follows a well-defined sequence. The sequence is designed to minimize the risk of data loss or extended downtime, and it should be followed in order. Skipping steps or reordering them is a common source of upgrade failures.

The first step is to take a full backup of the database and a snapshot of the OpenShift cluster. The backup should be verified by restoring it to a non-production environment and running a smoke test. The OpenShift snapshot should be taken with the cluster in a quiesced state, which means stopping all MAS workloads before the snapshot.

The second step is to upgrade the MAS Core operator. The operator upgrade is independent of the application upgrades, and it can be done during a maintenance window with the cluster still running. The operator upgrade typically takes 30 to 60 minutes, and it does not require a database restart.

The third step is to upgrade the data tier. The data tier upgrade includes Db2, MongoDB, and any other databases that MAS uses. For Db2, the upgrade involves running the IBM-provided Db2 upgrade scripts and then validating the database configuration. For MongoDB, the upgrade involves rolling the MongoDB cluster forward one minor version at a time. MAS 9.2 supports MongoDB 5.0 and 6.0, and the upgrade path from earlier versions is well documented.

The fourth step is to upgrade the application tier. The application tier includes Maximo Manage, Maximo Health, Maximo Monitor, Maximo Predict, Maximo Visual Inspection, and every installed industry solution or add-on. The application tier upgrade is the most time-consuming part of the process, and it typically takes 4 to 8 hours for a full upgrade. The upgrade can be done in place, or it can be done by deploying a new MAS instance and migrating the data.

The fifth step is to validate the upgrade. The validation step includes running the full Maximo Manage test suite, verifying the integration touchpoints, and confirming that all customizations are still functional. The validation step is non-negotiable, and it should be done in a non-production environment before the production upgrade is approved.

The final step is to cut over production. The production cutover typically requires a 4 to 6 hour maintenance window, depending on the size of the database and the complexity of the customizations. The cutover should be scheduled for a low-activity period, and it should be communicated to all stakeholders in advance.

Here is a representative upgrade sequence for a production MAS 9.1 deployment to MAS 9.2:

# Step 1: Backup verification
apiVersion: batch/v1
kind: Job
metadata:
  name: mas-backup-verify
spec:
  template:
    spec:
      containers:
        - name: backup
          image: ibmcom/mas-backup:9.2.0
          command: ["mas", "backup", "verify", "--type", "full"]
      restartPolicy: Never
---
# Step 2: Operator upgrade
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  name: ibm-mas-core.v9.2.0
spec:
  install:
    spec:
      clusterPermissions:
        - serviceAccountName: ibm-mas-core-operator
          rules: []

Post-Upgrade Validation: What to Test

The post-upgrade validation is the most important step in the entire process, and it is the step that is most often skipped. The validation should cover the following areas:

• Functional validation: Run the full Maximo Manage test suite, including work order creation, asset updates, inventory transactions, and purchase order processing. Verify that all custom applications are still functional, and that all integration touchpoints are still working.
• Performance validation: Run a representative load test against the upgraded environment, and compare the results to the pre-upgrade baseline. The MAS 9.2 upgrade is expected to improve performance in most cases, but any regression should be investigated before the production cutover.
• Security validation: Verify that the authentication and authorization mechanisms are still working as expected. This includes SCIM 2.0, SAML, LDAP, and the new multiple-IdP support that MAS 9.0 introduced. Verify that the LTPA token timeout is still set to the expected value, and that the password lockout policy is still in effect.
• Integration validation: Verify that all external integrations are still working. This includes MIF, REST APIs, Kafka, MQTT, and any custom integrations. Pay particular attention to integrations that depend on deprecated features, such as User Data Services or Maximo Assist search.
• AI extensibility validation: If you have deployed any custom agents or skills, verify that they are still working. The MCP Server in MAS 9.2 is a new component, and any integration that depends on it should be tested thoroughly.

Common Pitfalls and Field-Tested Patterns

Over the past two years, we have collected a set of patterns that consistently show up in successful MAS upgrades, and a set of pitfalls that consistently show up in failed upgrades. The patterns and pitfalls are worth reviewing before you start your own upgrade.

The first pattern is the parallel-stack upgrade. Rather than upgrading the production stack in place, deploy a parallel MAS 9.2 stack in a separate OpenShift project, migrate the data, and run validation in the parallel stack. Once the validation is complete, cut over by switching the DNS or load balancer to the new stack. The parallel-stack approach adds cost, but it dramatically reduces the risk of an extended outage.

The second pattern is the customization refactor window. Use the upgrade as an opportunity to refactor customizations that have been on the technical debt list. Common candidates include Anywhere extensions (which should be moved to Mobile), User Data Services integrations (which should be moved to Data Reporter Operator), and custom Maximo Assist features (which should be replaced with skills in MAS 9.2). The refactor window is the right time to do this work, because the upgrade already requires regression testing.

The third pattern is the staged rollout. Rather than upgrading the entire environment at once, upgrade one site or one business unit at a time. The staged rollout lets you catch problems early, and it lets you roll back to the previous version if necessary. The staged rollout is most effective when combined with the parallel-stack approach.

The most common pitfall is the under-tested database upgrade. The database is the most fragile part of the upgrade, and it is the part that is most often undertested. The database upgrade should be done in a non-production environment first, and the non-production upgrade should be run with a full-scale data set, not a subset. Subset testing hides problems that only appear at scale, and those problems are the ones that cause production outages.

The second most common pitfall is the over-trusted documentation. The IBM documentation is comprehensive, but it is also large, and it is easy to miss a prerequisite or a known issue. The most reliable way to find these is to read the release notes for every component, line by line, and to cross-reference them with your own customization inventory.

Practical Implications

The MAS 9.2 upgrade has practical implications for every team in the organization. For platform engineers, the upgrade introduces new components (MCP Server, agent skills) that require new operational skills. The MCP Server in particular should be monitored like any other production service, with health checks, log aggregation, and alert routing. For administrators, the upgrade changes several user-facing workflows, including the deprecation of Maximo Assist search and the retirement of the Self Service Center application. End users will need to be retrained on the new Asset & Locations Dashboard, and on the new Service Offerings and Self Serve applications.

For developers, the upgrade introduces a new extensibility model. Custom integrations that previously required direct API calls can now be implemented as MCP tools or skills, and they can be reused across multiple agents. The new model reduces the amount of integration code that needs to be written, but it also requires developers to learn the MCP and skills frameworks.

For reliability engineers, the upgrade introduces new Health and Predict capabilities. The Probability of Failure tab in Score Settings allows Weibull fitting directly inside Manage, which means reliability engineers can iterate on failure models without needing an external notebook environment. The Asset & Locations Dashboard provides a unified view of asset performance, which reduces the cognitive load of switching between Health, Monitor, and Manage.

For executives, the upgrade is an opportunity to revisit the AI strategy. With MCP and agent skills, the organization can now build AI capabilities that integrate directly with Maximo workflows, without giving up governance. The investment in MAS 9.2 is not just a platform upgrade. It is an enabler for the next generation of AI-driven asset management.

Bottom Line

Maximo Application Suite 9.2 is the most significant release since MAS 9.0, and the headline is not the new dashboard or the new scores. The headline is extensibility. MCP Server, agent skills, and the broader API surface let organizations build AI capabilities that integrate directly with Maximo workflows, with the same governance and security model that applies to human users. The upgrade is also a chance to retire long-standing technical debt, including Anywhere extensions, User Data Services integrations, and the deprecated Maximo Assist features.

The upgrade itself is not trivial. It touches the core operator, the data tier, the application tier, and every installed industry solution or add-on. The upgrade should be planned in a separate OpenShift project, validated with a full-scale data set, and rolled out in stages. The parallel-stack approach adds cost, but it dramatically reduces the risk of an extended outage.

For organizations that are still on Maximo 7.6, the MAS 9.2 upgrade is also the right time to consider the migration. The longer you wait, the more technical debt accumulates, and the more expensive the migration becomes. For organizations that are already on MAS 9.0 or 9.1, the upgrade to MAS 9.2 should be prioritized in the next 6 to 12 months, before the next Long Term Support milestone passes.

The bottom line: MAS 9.2 is not just a release. It is the platform on which the next generation of Maximo AI will be built. Get on it.