MAS 8.x End of Support: What It Means and How to Plan Your Move to 9.x

August 19, 2026

If your organization is still running IBM Maximo Application Suite 8.x, the clock has already run out. As of April 30, 2026, MAS 8.7, 8.8, and 8.9 reached complete end of support with no Extended Support option available. MAS 8.10 and 8.11 transitioned to IBM Extended Support on the same date, which means reduced coverage at additional cost with no new features or feature channel updates. The message from IBM is unambiguous: begin making upgrade plans for MAS 9.x immediately.

This article walks through what the MAS 8.x end of support actually means for your organization, which upgrade paths are available, how to assess your readiness, and what a realistic upgrade timeline looks like. Whether you are running a version that has already lost support or one that is limping along on Extended Support, the path forward converges on the same destination: MAS 9.x.

The urgency is not hypothetical. Organizations still running unsupported versions are operating without a safety net. Any security vulnerability discovered after April 30, 2026, will not receive an official patch from IBM for MAS 8.7, 8.8, or 8.9. Any bug that surfaces in the core platform will not be fixed. If you open a support ticket, IBM will advise you to upgrade. For those on 8.10 or 8.11, Extended Support is a paid program that provides product usage support, existing code patches, and critical defect fixes, but it is not a long-term solution.

The Support Timeline: How We Got Here

IBM formally announced the support transition for MAS 8.7 through 8.11 in March 2026, giving organizations roughly six weeks of formal notice before the changes took effect on April 30. While the writing had been on the wall since the MAS 9.0 release, the formal announcement put a hard date on the deadline.

The support lifecycle breaks down into clear tiers. MAS 8.7, 8.8, and 8.9 reached what IBM calls End of Support on April 30, 2026. There is no Extended Support offered for these releases. That means no patches, no security fixes, no defect resolution, and no technical support for product-related issues. Organizations running these versions are fully exposed to any issue that arises with no vendor remediation path.

MAS 8.10 and 8.11 entered IBM Extended Support on the same date. Extended Support is a paid program that provides a reduced level of coverage compared to Base Support. You get product usage support, meaning you can still call IBM for help using the product. You get existing code patches, meaning fixes that were already developed remain available. And you get critical defect fixes, meaning IBM will address severe issues that meet their criteria for critical severity. What you do not get is new features, feature channel updates, or fixes for non-critical defects.

The distinction matters because many organizations assume Extended Support is roughly equivalent to full support at a higher price. It is not. It is a bridge designed to give you time to plan and execute an upgrade, not a sustainable long-term operating state. IBM's own documentation and the operator catalog explicitly advise customers to begin upgrade plans for MAS 9.0 or later.

Looking at the broader timeline, Maximo Asset Management 7.6.1.x reached end of Base Support on September 30, 2025. Extended Support for 7.6.1.x runs through September 30, 2026, with Sustained Support available until 2030 under limited terms. The point is that IBM has been systematically pushing the installed base forward, and the 8.x line is no longer a viable resting place.

Upgrade Paths: Getting from 8.x to 9.x

The upgrade path from MAS 8.x to MAS 9.x depends on your current version, and not all paths are direct. Understanding which path applies to your environment is the first step in planning.

For organizations on MAS 8.7, 8.8, or 8.9, there is no direct upgrade to MAS 9.x. You must first upgrade to MAS 8.10 or 8.11, and then upgrade from there to 9.x. This two-step process adds complexity and time to the migration. The intermediate upgrade to 8.10 or 8.11 gets you onto a version that has a supported path forward, but you are still on Extended Support for the intermediate version, so the goal should be to move through this step as quickly as possible.

For organizations already on MAS 8.10 or 8.11, the path is more straightforward. You can upgrade directly to MAS 9.x via the Channel Subscription method. This involves updating the IBM Operator Catalog in your OpenShift cluster, approving the operator upgrade, and letting the system handle the transition. The process is designed to be semi-automated, with options for automatic or manual approval depending on your change management requirements.

For organizations still on Maximo 7.6.x, IBM supports direct upgrades from Maximo 7.6.0.10, 7.6.1.2, or 7.6.1.3 to MAS 9.x without requiring an intermediate stop at MAS 8.x. This is a significant advantage for organizations that delayed their initial migration to MAS. The upgrade is effectively a database migration: you clone your Maximo database, connect it to a fresh MAS Manage deployment, and activate the database upgrade. The Maximo 7.6 database schema is upgraded in place to the MAS 9.x schema.

Once you are on MAS 9.0, moving to 9.1 or 9.2 is handled through feature channel updates. These are lighter-weight updates that flow through the operator catalog and do not require a full migration. MAS 9.1 is the active release stream with version 9.1.19 shipped in late June 2026, and MAS 9.2 reached General Availability on June 25, 2026. The 9.2 release is IBM's current development focus, bringing significant AI capabilities including Condition Insight, the MCP Server for AI agent development, and conversational scheduling.

A critical note on OpenShift compatibility: verify your Red Hat OpenShift version before planning any upgrade. Even-numbered OCP versions like 4.14 or later are required for certain MAS applications such as Maximo Health, Predict, and Collaborate due to dependencies on IBM App Connect and Cloud Pak. Check cluster sizing against IBM guidelines for your specific workload, and ensure certificates, storage classes, networking, and security policies are current.

Assessing Your Current Environment

Before initiating any upgrade, you need a comprehensive assessment of your current MAS environment. This assessment serves as the foundation for your upgrade plan and helps identify potential blockers early.

Start with version identification. Confirm your exact MAS version, including the patch level. This determines your upgrade path and what intermediate steps, if any, are required. Check the IBM Operator Catalog version in your OpenShift cluster, as this needs to be updated before the upgrade can proceed.

Next, inventory all customizations. This is often the most time-consuming part of the assessment and the most likely to cause delays. Document every Java customization, automation script, custom application, integration, report, and workflow. For each item, assess whether it is compatible with MAS 9.x, whether it needs modification, or whether it can be replaced by native MAS 9.x functionality. MAS 9.x introduces significant architectural changes, and some customizations that worked in 8.x may not translate directly.

Integrations deserve particular attention. Any REST API integrations, Kafka connections, SAP connectors, or third-party tool integrations need to be verified against MAS 9.x compatibility. The SAP connector has been updated in 9.2 to use CPI, and Oracle Fusion connector support has been added, but existing integration configurations may need adjustment.

Run the Integrity Checker in REPORT mode against your database. This is a non-negotiable step. The Integrity Checker identifies data issues that could cause the upgrade to fail or produce unexpected results. Fix all errors before attempting the upgrade. Warnings should be reviewed and addressed where feasible. Attempting an upgrade with unresolved Integrity Checker errors is a recipe for extended downtime and potential data loss.

Assess your OpenShift cluster health. Check resource utilization, storage capacity, node health, and network configuration. MAS 9.x may have different resource requirements than 8.x, particularly if you plan to use new applications like Maximo Monitor or the AI Service. Ensure your cluster has sufficient CPU, memory, and storage headroom for the upgrade process and the post-upgrade environment.

Review your licensing position. MAS uses the AppPoints model, where a shared pool of points is consumed across MAS applications. The applications you run and the number of users determines your AppPoint consumption. MAS 9.2 introduces new applications and capabilities that may affect your licensing needs. Work with your IBM account team to confirm your AppPoint entitlements and understand the consumption impact of the features you plan to use.

Building a Realistic Upgrade Timeline

One of the most common mistakes in MAS upgrade planning is underestimating the timeline. Organizations frequently plan for a three-month upgrade and find themselves at month six still working through UAT. A realistic timeline accounts for assessment, execution, validation, and hypercare.

The assessment phase typically runs two to three months. During this phase, you complete the environment inventory, run the Integrity Checker, identify and document customizations, verify integration compatibility, assess OpenShift readiness, and confirm licensing. The output of this phase is a detailed upgrade plan with identified risks, mitigation strategies, and a projected timeline.

The execution phase typically runs four to six weeks. This is the actual technical work of performing the upgrade in a non-production environment first, validating the process, and then executing in production. For organizations on 8.7, 8.8, or 8.9 that require the intermediate step through 8.10 or 8.11, add two to four weeks for the intermediate upgrade. The execution phase includes updating the operator catalog, approving the operator upgrade, waiting for foundation services to upgrade, updating individual applications, and verifying post-upgrade system health.

User Acceptance Testing runs four to six weeks. This is where business users validate that core processes work correctly in the upgraded environment. Testing should cover all critical business processes: work order management, preventive maintenance scheduling, procurement, inventory management, and any custom workflows. Integration testing is part of this phase, confirming that all external systems communicate correctly with the upgraded MAS environment.

The go-live and hypercare phase runs two to three months. Go-live itself is a focused event, but the hypercare period that follows is critical. During hypercare, you monitor the system closely, address user issues quickly, and stabilize the environment. This is also when you identify any performance issues that did not surface in testing.

For organizations on 8.7, 8.8, or 8.9, the total timeline from assessment to hypercare completion is typically nine to twelve months. For organizations on 8.10 or 8.11 with a direct path to 9.x, the timeline is closer to seven to nine months. For organizations on 7.6.x with a direct path to 9.x, the timeline is similar to the 8.10/8.11 path since the database migration process is well-established.

The key takeaway is that this is not a project to defer. Every month of delay increases operational risk for unsupported versions and consumes Extended Support budget for those on 8.10 or 8.11. Start the assessment phase now, even if you do not plan to execute the upgrade for several months. The assessment will identify blockers early and give you the information needed to make informed decisions about timing and resource allocation.

Common Pitfalls and How to Avoid Them

Several patterns emerge consistently in MAS upgrade projects that encounter problems. Understanding these pitfalls in advance can save significant time, cost, and frustration.

The most common pitfall is underestimating customization remediation. Organizations often discover during execution that customizations they assumed would work in 9.x require significant rework. This discovery mid-upgrade leads to delays, scope creep, and sometimes rollback. The solution is thorough customization assessment during the planning phase. Do not assume compatibility. Test critical customizations in a sandbox environment running 9.x before committing to the upgrade.

The second pitfall is skipping non-production validation. Under time pressure, organizations sometimes attempt to move from assessment directly to production upgrade. This almost always ends badly. Always validate the upgrade process in a development or staging environment first. This includes a full upgrade cycle, post-upgrade validation, and at least a subset of UAT. Issues discovered in non-production are inconvenient. Issues discovered in production are crises.

The third pitfall is neglecting integration testing. Integrations are often the last thing tested and the first thing to break. External systems that communicated correctly with MAS 8.x may behave differently with 9.x due to API changes, authentication updates, or data model modifications. Include integration testing in your UAT plan and test every integration, not just the obvious ones.

The fourth pitfall is inadequate rollback planning. Before starting the upgrade, ensure you have a viable rollback path. Create OpenShift snapshots or backups of etcd and persistent volumes. Document the rollback procedure and verify that the team knows how to execute it. A rollback plan that has never been tested is not a rollback plan; it is a hope.

The fifth pitfall is insufficient user communication. Users who arrive at work on Monday morning to find a different interface and changed workflows will generate a flood of support tickets that can overwhelm your hypercare team. Communicate changes in advance, provide training on new features, and set expectations for the transition period. Consider a phased rollout for large organizations rather than a big-bang approach.

Practical Implications

For organizations on MAS 8.7, 8.8, or 8.9, the situation is urgent. You are operating without vendor support, and every day increases risk. Your first priority should be getting to 8.10 or 8.11 as an intermediate step, then moving to 9.x as quickly as possible. Engage with IBM or a qualified partner to accelerate the intermediate upgrade.

For organizations on 8.10 or 8.11, you have some breathing room but not much. Extended Support is a paid program with reduced coverage, and IBM has made it clear that the expectation is for customers to move to 9.x. Use the Extended Support window to execute a deliberate, well-planned upgrade to 9.x rather than waiting until Extended Support ends and facing the same crisis that 8.7-8.9 customers face today.

For organizations on Maximo 7.6.x, the direct path to MAS 9.x is available but the window is closing. Extended Support for 7.6.1.x ends September 30, 2026. After that, only Sustained Support remains, which provides no new security patches. The direct migration path from 7.6.x to 9.x is well-tested and documented, and starting now means you can complete the migration before the Extended Support deadline.

Bottom Line

The MAS 8.x end of support is not a future event. It happened on April 30, 2026. Organizations still running 8.7, 8.8, or 8.9 are operating without a safety net. Organizations on 8.10 or 8.11 are on borrowed time with Extended Support. The only viable path forward is MAS 9.x, and the upgrade process takes longer than most organizations expect. Start your assessment today, identify your upgrade path, document your customizations, run the Integrity Checker, and build a realistic timeline. The longer you wait, the higher the risk and the more compressed your timeline becomes. MAS 9.2 is a significant release with AI capabilities that justify the migration effort, but the primary justification is simpler: it is the only version that IBM will actually support.