The MAS 9.x Upgrade Path: What Every Maximo Admin Needs to Know in 2026

The MAS 9.x Upgrade Path: What Every Maximo Admin Needs to Know in 2026If you are still running Maximo 7.6 or an early MAS 8.x release, 2026 is the year the safety net disappears. IBM ended regular base support for Maximo Asset Management 7.6.1.x on September 30, 2025. MAS 8.7, 8.8, and 8.9 reached end of support on April 30, 2026, with no Extended Support option. MAS 8.10 and 8.11 transitioned to IBM Extended Support on the same date, which means reduced coverage at additional cost. The only viable path forward is MAS 9.x, with 9.1.x as the generally available production baseline and 9.2 introducing deeper AI integration as of June 2026.

This article is a practical guide for Maximo administrators and IT architects who are planning or actively executing an upgrade. We will cover the supported upgrade paths, the technical prerequisites that catch teams off guard, the four-phase migration methodology, the customization modernization strategy, and the post-go-live stabilization patterns that separate successful projects from the ones that stall.

Understanding the Upgrade Paths and Support Timeline

The upgrade landscape in 2026 is clearer than it has ever been, but the clarity comes with hard deadlines. IBM supports direct upgrades from Maximo 7.6.0.10, 7.6.1.2, or 7.6.1.3 to MAS 9.x. There is no requirement to stop at MAS 8.x as an intermediate step. This is important because many teams assumed they needed a two-hop migration, which would have added months and significant cost to the project. The direct path is available, tested, and documented by IBM.

For organizations already on MAS 8.x, the situation depends on the version. MAS 8.7, 8.8, and 8.9 have no Extended Support path. There are no patches, no security fixes, and no defect resolution available from IBM after April 30, 2026. Organizations running these versions are operating without a safety net. MAS 8.10 and 8.11 are on Extended Support, which provides a reduced level of coverage including product usage support, existing code patches, and critical defect fixes. Extended Support is a paid program, and it is not a long-term solution. The recommendation from IBM and partners is to move to MAS 9.x as quickly as practical.

MAS 9.1.x has been generally available since June 24, 2025, and runs on a Support Cycle-3 lifecycle policy. MAS 9.2 was announced in June 2026 and expands AI capabilities across reliability insights, field execution, safety and compliance, and document-based information extraction. The 9.2 release also introduces agentic workflows, which represents a significant shift in how Maximo handles decision-making and task orchestration.

The upgrade method that IBM recommends for MAS 9.x is Channel Subscription. This method delivers updates monthly through the IBM Operator Catalog in OpenShift. You subscribe to a release channel (stable or feature), and updates are delivered automatically or require manual approval depending on your configuration. This is a departure from the manual upgrade process that MAS 8.9 and earlier required, where teams downloaded installers from IBM Passport Advantage and ran scripts. The Channel Subscription method handles both MAS Core and application upgrades, including Manage, Monitor, Predict, Health, Visual Inspection, and Mobile.

Here is what the Channel Subscription configuration looks like in the MaximoSuite custom resource:

apiVersion: mas.ibm.com/v1
kind: MaximoSuite
metadata:
  name: mas-inst1
  namespace: mas-inst1-core
spec:
  channel: 9.1.x
  updatePlan: manual
  applications:
    manage:
      channel: 9.1.x
      customResource:
        settings:
          jsonMapping: enabled
          workOrderIntelligence: enabled
    mobile:
      channel: 9.1.x
    health:
      channel: 9.1.x
    predict:
      channel: 9.1.x

The channel field determines which release track you subscribe to. The updatePlan field controls whether updates are applied automatically or require manual approval. Most production environments use manual to maintain control over when changes are introduced. Development and test environments can use automatic to reduce administrative overhead.

Technical Prerequisites and Infrastructure Readiness

The technical prerequisites for MAS 9.x are where many upgrade projects encounter their first significant delays. MAS runs on Red Hat OpenShift Container Platform, and the version requirements are specific. Even-numbered OpenShift versions (4.14, 4.16, etc.) are required for applications like Maximo Health, Predict, and Visual Inspection due to dependencies on IBM App Connect and Cloud Pak components. Organizations that have not previously operated OpenShift face a learning curve that can add weeks to the timeline.

Cluster sizing is the second common stumbling block. MAS 9.x requires sufficient CPU, memory, and storage to run the core platform and each application. The sizing depends on the number of users, the number of assets, the transaction volume, and the number of applications deployed. IBM provides sizing guidelines, but many teams underestimate the storage requirements, particularly for attachment storage and database volumes. A typical mid-size deployment with Manage, Mobile, and Health for 500 users requires a minimum of 3 worker nodes with 16 vCPU and 64 GB RAM each, plus 2 TB of persistent storage for the database and 500 GB for attachment storage.

Networking and security prerequisites are the third area that catches teams off guard. MAS 9.x uses containerized services that communicate over internal OpenShift network policies. External integrations must use REST APIs or Kafka events, and the legacy JMS and SOAP integration patterns from Maximo 7.6 require rework. Certificate management, DNS configuration, and firewall rules all need to be in place before the installation begins.

The pre-upgrade checklist should include:

• Verify Red Hat OpenShift version (even-numbered, 4.14 or higher)
• Check cluster sizing against IBM guidelines for your workload
• Ensure certificates, storage classes, and networking are configured
• Update the IBM Operator Catalog in your OpenShift cluster
• Back up your current environment (etcd snapshots, persistent volumes, databases)
• Review compatibility for add-ons, custom integrations, and third-party tools
• Validate Java 17 compatibility for any custom Java code

The backup step is non-negotiable. Before any upgrade, create etcd snapshots and persistent volume backups. OpenShift has built-in rollback features for operators, but they only work if you have snapshots to roll back to. Have a contingency plan to revert to the previous channel or version, and test the rollback procedure in a non-production environment before the production upgrade.

The Four-Phase Migration Methodology

A successful MAS 9.x migration follows a four-phase methodology that has been validated across hundreds of implementations. The phases are Preparation and Learning, Assessment and Decision-Making, Execution, and Post-Go-Live Stabilization. Each phase has specific deliverables and exit criteria.

Phase 1: Preparation and Learning (2-4 months)

The first phase is about building organizational readiness. This is not a technical phase; it is a people phase. Teams need to learn MAS, understand the modular application architecture, and become familiar with OpenShift. IBM provides official documentation, partner demos, and Maximo user groups as learning resources. The key activities in this phase include training the IT team on OpenShift, engaging business stakeholders in discovery workshops, and establishing a sandbox or proof-of-concept environment.

The stakeholder engagement is critical. MAS is not just a technology upgrade; it is an opportunity to rethink maintenance processes. Bring together Maintenance, IT, Procurement, Operations, and Executive Leadership for discovery workshops. Use these workshops to identify pain points in current processes, redundant workflows, and opportunities to leverage new MAS capabilities like Work Order Intelligence and Reliability Strategies.

Phase 2: Assessment and Decision-Making (2-3 months)

The second phase is where the technical and business decisions are made. Start by documenting the current Maximo 7.6 environment comprehensively. This includes all interfaces, reports, scripts, Java customizations, add-ons, and obsolete components. Every customization must be cataloged with its business purpose, technical implementation, and migration approach.

The deployment model decision is made in this phase. Cloud deployment (IBM Cloud, AWS, or Azure) is recommended for most organizations because it provides managed SLAs, scalability, and reduces the OpenShift administration burden. On-premise deployment provides more control but requires deep OpenShift expertise within the organization.

The data archiving strategy is another key decision. Do not migrate everything. Identify active data and recent history that must be carried forward. Archive or decommission old, unused data. This reduces migration time, storage costs, and the risk of carrying forward data quality issues.

Phase 3: Execution (1-2 months for upgrade, 3-6 months for full migration)

The execution phase is where the actual migration happens. Build a backward-scheduled timeline from the target go-live date, accounting for business constraints like fiscal periods and peak seasons. The typical timeline for a Maximo 7.6 to MAS 9.x migration is 6-9 months total, including assessment (2-3 months), upgrade execution (1 month), UAT (1 month), go-live (1 month), and hypercare (2 months).

Launch a pilot with 1-2 sites, asset families, or business units before full rollout. The pilot validates migration rules, data quality, user experience, and integrations. This is where you discover the issues that would have been catastrophic in a full rollout. Fix them in the pilot, document the fixes, and then scale.

Phase 4: Post-Go-Live Stabilization (2-3 months)

The hypercare period is dedicated support immediately after go-live. Have a dedicated team available to help users navigate the new system and to quickly fix issues. After hypercare, transition to continuous improvement. Once the environment is stable, optimize processes by leveraging the analytics and AI features of MAS, and take advantage of the monthly updates delivered through the Channel Subscription.

Customization Modernization and Integration Strategy

Customization modernization is the most time-consuming and risk-prone part of any Maximo migration. Maximo 7.6 environments typically have years or decades of custom Java code, automation scripts, UI modifications, and integration logic. MAS 9.x changes the customization landscape significantly.

The first principle of customization modernization is to prefer configuration over code. MAS provides native APIs, low-code configuration tools, and automation scripts that can replace much of the custom Java code in legacy Maximo environments. Before migrating any customization, evaluate whether it can be replaced with a native MAS feature or configuration. The goal is to reduce the customization footprint, not to reproduce it.

For customizations that must be carried forward, the Java code needs to be recompiled and potentially refactored for Java 17 compatibility. MAS 9.1 requires Java 17, which is a significant change from the Java 8 environment that Maximo 7.6 used. This is not a simple recompilation; some libraries and APIs that were available in Java 8 have been removed or deprecated in Java 17. Plan for code review, testing, and potentially rewriting portions of custom Java classes.

Automation scripts are generally easier to migrate than Java code, but they still require review. Syntax changes, updated error handling, and compatibility with the new MAS automation script engine can require modifications. The migration is an opportunity to refactor legacy scripts, improve error handling, and adopt modern coding patterns.

UI customizations are handled differently in MAS. The old method of modifying JSP files and XML presentation templates is gone. MAS uses real-time CSS and layout tools that allow UI modifications without code deployment. This is a significant improvement, but it means that UI customizations must be rebuilt from scratch using the new tools.

The integration strategy is equally important. Legacy JMS and SOAP-based interfaces should be migrated to Kafka events and REST APIs. The integration security model changes from maxauth tokens to MAS API keys and OAuth. This is not just a technical change; it requires coordination with every external system that integrates with Maximo.

Here is an example of migrating a legacy SOAP integration to a REST API endpoint in MAS:

{
  "endpointConfig": {
    "name": "ERP_WORK_ORDER_SYNC",
    "type": "REST",
    "direction": "OUTBOUND",
    "method": "POST",
    "url": "https://erp.corp.com/api/maximo/workorders",
    "authType": "OAUTH2",
    "tokenEndpoint": "https://auth.corp.com/oauth/token",
    "clientId": "mas_integration",
    "objectStructure": "MXAPIWODETAIL",
    "whereClause": "status in ('WAPPR','APPR') and changedate > :lastsync",
    "batchSize": 500,
    "retryCount": 3,
    "retryInterval": 60
  }
}

This configuration replaces what would have been a SOAP-based integration with a REST endpoint using OAuth2 authentication, batch processing, and retry logic. The objectStructure field references the standard Maximo object structure, and the whereClause ensures only relevant records are synchronized.

Common Pitfalls and Field-Tested Patterns

After hundreds of MAS migrations, certain patterns emerge as the most common causes of project delays and failures. Understanding these pitfalls and the patterns that avoid them can save months of rework.

Pitfall 1: Underestimating OpenShift Complexity

Organizations that have never operated OpenShift consistently underestimate the learning curve. OpenShift is a full Kubernetes distribution with its own networking, storage, security, and operator framework. Teams that try to learn OpenShift while simultaneously deploying MAS end up with a fragile environment that is difficult to troubleshoot and maintain. The fix is to start OpenShift training in Phase 1, before any MAS deployment begins. Set up a sandbox cluster and have the IT team deploy a simple application before attempting MAS.

Pitfall 2: Migrating Everything

The temptation to migrate all historical data is strong, particularly in organizations with compliance requirements. But migrating decades of work order history, asset records, and transaction data slows down the migration, increases storage costs, and introduces data quality issues. The field-tested pattern is to migrate active assets, open work orders, and 2-3 years of history. Archive the rest in a read-only database that can be queried if needed.

Pitfall 3: Reproducing Customizations Instead of Modernizing

Many teams approach the migration as a like-for-like reproduction of their Maximo 7.6 environment. This is a mistake. The migration is an opportunity to simplify and modernize. Every customization should be evaluated: Is it still needed? Can it be replaced with a native feature? Can it be simplified? The teams that take this approach end up with a cleaner, more maintainable MAS environment. The teams that reproduce everything end up with a migration that takes twice as long and a system that is harder to maintain.

Pitfall 4: Inadequate Testing

Testing is frequently compressed at the end of the project when the timeline is under pressure. This is exactly when testing matters most. Develop automated functional and regression test scripts for customizations and core features. Perform parallel runs of the legacy Maximo and MAS environments to ensure data and process consistency. Conduct User Acceptance Testing with business users and power users, not just IT. Establish rollback plans and test them.

Pitfall 5: Ignoring Licensing Transition

The MAS AppPoints licensing model is fundamentally different from the legacy Maximo license types. Use IBM's AppPoints calculator early in the project, conduct a detailed user role analysis, and map legacy license types to AppPoints. Plan the license transition early to enable phased migration and uninterrupted user access. Teams that leave licensing to the end find that they do not have enough AppPoints for all users at go-live, which delays the rollout.

Practical Implications

For organizations still on Maximo 7.6, the message is clear: the time to act is now. End of support means no patches, no security fixes, and no defect resolution. The risk of running an unsupported EAM system in a regulated industry is significant. The direct upgrade path to MAS 9.x is available and tested, but the migration takes 6-9 months. Organizations that have not started by mid-2026 will be operating without support into 2027.

For organizations on MAS 8.7-8.9, the situation is more urgent. There is no Extended Support option. The only path is to MAS 9.x, and the upgrade should be planned and executed as quickly as possible. For organizations on MAS 8.10 or 8.11, the Extended Support provides a buffer, but it is a paid program with reduced coverage. The cost of Extended Support should be weighed against the cost of upgrading to 9.x.

The technical prerequisites are the most common source of delay. Start the OpenShift training, cluster sizing, and network preparation early. Document the current environment comprehensively. Engage business stakeholders in process review workshops. And do not reproduce the legacy environment; use the migration as an opportunity to modernize.

Bottom Line

MAS 9.x is the only supported path forward for Maximo customers in 2026. The upgrade from Maximo 7.6 is direct and supported, but it requires 6-9 months of planning and execution. The technical prerequisites around OpenShift, cluster sizing, and integration modernization are the most common sources of delay. The four-phase methodology (Preparation, Assessment, Execution, Stabilization) provides a proven framework. The customization modernization strategy should prioritize configuration over code, and the integration strategy should move from JMS/SOAP to Kafka/REST. Organizations that treat the migration as a modernization opportunity rather than a like-for-like reproduction end up with a cleaner, more maintainable system and a faster return on investment. The safety net is gone. The time to plan is now.