Navigating the MAS 8.x End of Support: Your Complete Upgrade Path to MAS 9.x

Navigating the MAS 8.x End of Support: Your Complete Upgrade Path to MAS 9.x

If your organization is still running IBM Maximo Application Suite 8.7, 8.8, or 8.9, the clock has already run out. As of April 30, 2026, those releases reached end of support with no Extended Support option available. If you are on MAS 8.10 or 8.11, you entered IBM Extended Support on the same date, which means a reduced level of coverage with no new security patches or feature updates. The message from IBM is unambiguous: the future is MAS 9.x, and the time to plan your move is now, not when the next security vulnerability surfaces and you have no patch path.

This article breaks down what changed on April 30, 2026, how the MAS 9.x support model works, what upgrade paths exist from both Maximo 7.6.x and MAS 8.x, and the practical steps your team needs to take to execute the upgrade successfully. Whether you are a MAS administrator planning the migration or an IT architect designing the target environment, this guide gives you the technical detail you need to move forward with confidence.

The April 2026 Support Cliff: What Actually Changed

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. The transition created two tiers of impact depending on which version you were running.

For MAS 8.7, 8.8, and 8.9, the situation is severe. These releases reached complete end of support on April 30, 2026. IBM will not offer Extended Support for any of them. That means no patches, no security fixes, no defect resolution, and no technical support for product-related issues. Organizations still running these versions are operating without a safety net. Any security vulnerability discovered after April 30 will not receive an official patch from IBM. 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 MAS 8.10 and 8.11, the situation is less urgent but still pressing. These releases transitioned from full Base Support to IBM Extended Support on the same date. Extended Support is a paid program that provides a reduced level of coverage: product usage support, existing code patches, and critical defect fixes. It does not include proactive security fixes or new functionality. You can keep running MAS 8.10 or 8.11 under Extended Support for a period, but you are buying time, not a long-term position. The smart play is to use the Extended Support window to execute your upgrade to MAS 9.x rather than treating it as a reason to delay.

It is worth noting that Maximo 7.6.1 is on its own separate timeline. Standard Base Support for Maximo 7.6.1 ended on September 30, 2025. Extended Support runs until September 30, 2026. After that, only Sustained Support remains available, extending to 2030 but restricted to usage questions and existing fixes with no new security patches. If you are still on 7.6.1.x, your window to migrate with full support is closing fast.

The IBM Operator Catalog also flagged the transition. In the v9-260326-amd64 catalog release, IBM explicitly advised that MAS 8.10 and 8.11 standard support and software updates ended on April 30, 2026, and recommended all customers begin upgrade plans for MAS 9.0. This was not a quiet policy change buried in a support page. It was communicated through the operator catalog itself, which is the mechanism that administrators interact with during routine maintenance.

The MAS 9.x Lifecycle: Understanding the 3+1+3 Model

IBM introduced a new support lifecycle model with MAS 9.x that differs significantly from the 8.x era. Understanding this model is essential for planning your upgrade timing and long-term support strategy.

The lifecycle follows a 3+1+3 pattern. Each major MAS 9.x release receives 36 months of Base Support, which includes monthly maintenance updates with security patches, bug fixes, and feature channel drops. After the Base Support period ends, there is a 12-month Extended Support window with reduced coverage. Beyond that, the release moves to Sustained Support, which can extend for up to 3 additional years but provides only usage support and existing fixes with no new patches.

The release cadence for MAS 9.x is approximately every 12 months. MAS 9.0 shipped in June 2024, MAS 9.1 in June 2025, and MAS 9.2 in June 2026. This predictable cadence is a significant improvement over the 8.x era, where releases and their support timelines were less consistent. With the 12-month cadence, you can plan your upgrade cycle to align with major releases and stay within the Base Support window.

A critical architectural change in MAS 9.x is version alignment across all sub-applications. In the 8.x era, MAS Core, Manage, Monitor, Health, Predict, and other applications could be on different version numbers, creating confusion about compatibility and support. In MAS 9.x, all sub-components share the same version number. MAS 9.2 includes Maximo Manage 9.2, Maximo Monitor 9.2, Maximo Health 9.2, and so on. This alignment simplifies upgrade planning and eliminates the version compatibility matrices that plagued 8.x deployments.

IBM also delivers monthly Feature Channel updates within each major release. For example, MAS 9.2 has already seen January, February, March, April, and June Feature Channel drops in 2026, each delivering incremental improvements to Core, Manage, Monitor, Optimizer, and other applications. These feature channel updates allow organizations to access new capabilities without waiting for the next major release, while still maintaining the stability of the core platform.

The Feature Channel model also changes how administrators consume updates. Instead of a single annual upgrade event, organizations can subscribe to the stable channel for monthly maintenance patches or the feature channel for early access to new capabilities. This gives teams granular control over how quickly they adopt new functionality. A conservative organization might stay on the stable channel and receive only security and bug fixes, while a more aggressive organization might subscribe to the feature channel to test new capabilities in dev before promoting them to production.

Upgrade Paths: From 7.6.x and 8.x to 9.x

One of the most important changes in the MAS 9.x architecture is the direct upgrade path from Maximo 7.6.x. Organizations running Maximo 7.6.0.10, 7.6.1.2, or 7.6.1.3 can upgrade directly to MAS 9.x without an intermediate stop at MAS 8.x. This eliminates what was previously a two-step migration process and significantly reduces the project timeline and risk.

For organizations already on MAS 8.x, the upgrade path depends on your current version. If you are on MAS 8.7, 8.8, or 8.9, you cannot upgrade directly to 9.x. You must first upgrade to MAS 8.10 or 8.11, and then upgrade from there to 9.x. Since 8.10 and 8.11 are now on Extended Support, this intermediate step adds time and complexity to your project. If you are already on MAS 8.10 or 8.11, you can upgrade directly to MAS 9.x, which is the simplest path.

The upgrade method also differs between 8.x and 9.x. For MAS 8.9 and earlier, the upgrade process is manual: you download installers from IBM Passport Advantage and run upgrade scripts. This method is labor-intensive and error-prone, requiring significant manual effort and careful sequencing. For MAS 8.10 and later, including all 9.x releases, IBM recommends the Channel Subscription method through the IBM Operator Catalog in Red Hat OpenShift. This method provides automated or semi-automated updates delivered through operator subscriptions, which is significantly more reliable and less labor-intensive than the manual approach.

# Example: Checking current MAS version via OpenShift CLI
oc get maximosuite -n mas-dev -o jsonpath='{.status.version}'

# Example: Subscribing to the MAS 9.2 feature channel
oc patch maximosuite maximo -n mas-dev --type=merge -p '{
  "spec": {
    "channel": "mas-9.2-feature-channel",
    "updateStrategy": {
      "approval": "Automatic"
    }
  }
}'

# Example: Checking upgrade status and conditions
oc get maximosuite -n mas-dev -o jsonpath='{.status.conditions}' | jq .

# Example: Verifying operator catalog source is current
oc get catsrc -n openshift-marketplace ibm-operator-catalog \
  -o jsonpath='{.spec.image}'

The channel subscription model allows you to choose between automatic and manual approval for updates. Automatic approval means the operator applies updates as soon as they are available in the channel, which is suitable for development and test environments. Manual approval requires an administrator to explicitly approve each update, which is the recommended approach for production environments where you want to control the timing and validate updates before deployment.

For Maximo 7.6.x migrations, IBM provides migration tools that extract data from the 7.6.x database and import it into the MAS 9.x environment. The migration covers core EAM data including assets, locations, work orders, job plans, PMs, inventory, and procurement records. However, customizations developed in 7.6.x using Automation Scripts, Application Designer, and Workflow Designer need to be evaluated individually. Many customizations can be migrated, but some may need to be rebuilt on the new Maximo Application Framework, especially if they relied on legacy UI components that have been removed in 9.x.

Planning Your Upgrade: A Step-by-Step Approach

The upgrade process from MAS 8.x to 9.x involves several phases, each with its own technical requirements and validation steps. A well-planned upgrade project typically takes 3 to 6 months from initial assessment to production cutover, depending on the complexity of your environment and the extent of your customizations.

Phase 1: Assessment and Prerequisites. Before starting the upgrade, you need to verify that your Red Hat OpenShift Container Platform version meets the requirements for MAS 9.x. Even-numbered OCP versions (4.14, 4.16, etc.) are required for certain MAS applications, including Health, Predict, Utilities, and Collaborate, due to dependencies on IBM Cloud Pak components. You also need to check your cluster sizing against IBM guidelines for your workload, ensuring adequate CPU, memory, and storage resources. Review your certificates, storage classes, networking configuration, and security policies to ensure they are current and compatible with MAS 9.x requirements.

Phase 2: Backup and Preparation. Create a full backup of your current MAS environment, including etcd snapshots, persistent volumes, and database backups. Update the IBM Operator Catalog in your OpenShift cluster to ensure you have access to the latest MAS 9.x operators. Review compatibility for any custom integrations, third-party tools, automation scripts, and add-ons that you rely on. Custom configurations that worked in 8.x may need adjustments for 9.x, particularly if they depend on APIs or data structures that have changed.

Phase 3: Upgrade MAS Core. Using the OpenShift web console or the oc CLI, approve the operator upgrade for MAS Core. If you are using channel subscription, edit the MaximoSuite custom resource to point to the new channel version. The operator handles upgrades to Foundation services (Identity, Licensing, Workspace, and others) automatically. Monitor the upgrade progress through the OpenShift console or by watching operator logs. Prometheus and Grafana integrations can help you track the upgrade health and identify any issues early.

Phase 4: Upgrade Individual Applications. Applications like Manage, Monitor, Predict, Health, Visual Inspection, and Mobile upgrade automatically if auto-approval is enabled. If you are using manual approval, approve each operator update sequentially in the OpenShift console. After each application is updated, re-apply any custom configurations such as UI themes, automation scripts, or custom reports that may have been affected by the version change.

Phase 5: Post-Upgrade Validation. Test all integrations including REST APIs, Kafka connections, and external systems. Reconfigure custom UI elements, reports, or workflows if they were impacted by the upgrade. Run full regression testing, user acceptance testing, and performance benchmarks. Validate data integrity, especially if you are migrating from Maximo 7.6.x, where the data model differences are more significant. Use IBM's migration tools for data extraction and import validation.

Phase 6: Rollback Preparation. Create OpenShift snapshots or backups before starting the production upgrade. Understand OpenShift's built-in rollback features for operators in case issues arise. Have a documented contingency plan to revert to the previous channel or version, including the steps to restore from backup and the criteria for deciding to roll back versus forward-fix.

Common Pitfalls and How to Avoid Them

Upgrading MAS is not just a technical exercise. It is an organizational change management project. Here are the pitfalls that teams encounter most frequently:

Underestimating customization impact. Organizations with heavy automation script customizations, custom workflows, or Application Designer modifications often find that these customizations need rework after the upgrade. The shift from 8.x to 9.x includes changes to the Maximo Application Framework and the removal of legacy Work Centers in favor of role-based applications. Any customizations built on the old Work Center framework will need to be rebuilt on the new platform. Conduct a customization inventory before the upgrade and budget time for rework.

Ignoring the OpenShift version requirement. MAS 9.x has specific OCP version requirements. Running an outdated OpenShift version is the most common cause of upgrade failures and post-upgrade instability. Verify your OCP version early in the planning process and upgrade OpenShift first if needed.

Skipping the test environment. The temptation to skip the dev/test cycle and go straight to production is strong when timelines are tight. Do not do it. Every upgrade has environment-specific quirks that only surface in a test environment. A minimum of one full upgrade cycle in dev, one in test/staging, and then production is the safe approach.

Not planning for downtime. While MAS supports rolling upgrades in some configurations, there is still a service window during the upgrade. Plan for downtime, communicate it to users, and schedule it during a low-impact period. Trying to rush the upgrade during a narrow maintenance window leads to mistakes and incomplete validation.

Overlooking the ManageWorkspace custom resource. In MAS 9.x, attachment storage configuration is controlled through the ManageWorkspace custom resource, which supports both file-based and object-based storage. Organizations that were using file-based storage in 8.x may want to migrate to object-based storage (S3-compatible or Azure blob storage) during the upgrade to take advantage of better scalability. This is a configuration change that should be planned and tested, not discovered during the production cutover.

Practical Implications

The April 2026 support transition is not a surprise. IBM announced the lifecycle model years in advance and has been consistently communicating the deadline. But many organizations operate in a reactive mode, and the deadline has now arrived. If you are on MAS 8.7, 8.8, or 8.9, you are already in an unsupported state. Every day without an upgrade plan is a day of risk. If a critical security vulnerability is discovered, you will not receive a patch. If a bug impacts your production environment, IBM support will advise you to upgrade before investigating.

For organizations on MAS 8.10 or 8.11, the Extended Support window provides breathing room, but it is not free. Extended Support is a paid program with reduced coverage, and it has a finite duration. The smart strategy is to use the Extended Support period to execute your upgrade project, not to defer planning.

If you are still on Maximo 7.6.1.x, the situation is critical. Extended Support ends on September 30, 2026. After that, you will be on Sustained Support with no security patches. The direct upgrade path from 7.6.1.3 to MAS 9.x is available, but the migration project is significant because of the architectural differences between 7.6.x and 9.x. Start now, or you will be facing an unsupported production EAM system with no upgrade path that can be completed in time.

The 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 vendor support. Organizations on 8.10 and 8.11 have a paid, reduced-support window that will eventually close. The upgrade path to MAS 9.x is well-defined and technically sound, with direct migration from 7.6.x supported and channel-based upgrades making the process more automated than ever. But the upgrade requires planning, testing, and execution time. If you have not started your upgrade project, start today. The alternative is running a critical business system without security patches or vendor support, and that is a risk no organization should accept.