Navigating the MAS 9 Upgrade Path: What Every Maximo Administrator Needs to Know

The Maximo Application Suite (MAS) represents IBM's most significant architectural shift in the Maximo ecosystem since the product's inception. For organizations still running Maximo 7.6.1.x on traditional WebSphere or WebLogic middleware, the path to MAS 9 is not merely an upgrade. It is a platform migration that touches every layer of the stack: infrastructure, middleware, authentication, integration, and the user experience itself.

This article provides a technical walkthrough of the MAS 9 upgrade journey, from pre-upgrade assessment through post-migration validation. Whether you are planning a greenfield deployment or migrating from an existing MAS 8.x instance, the considerations here will help you avoid the most common pitfalls.

Understanding the MAS 9 Architecture Shift

Before diving into the upgrade mechanics, it is worth understanding what changed under the hood. MAS 9 continues the containerization journey that began with MAS 8, running entirely on Red Hat OpenShift. There is no WebSphere, no WebLogic, and no standalone middleware to manage. Every component runs as a containerized microservice orchestrated by OpenShift.

The core MAS 9 architecture consists of several layers:

The most significant change in MAS 9 is the decoupling of the suite administration plane from individual application instances. In MAS 8.x, the suite admin shared resources with Manage. In MAS 9, the admin plane runs as a fully independent set of services, which means upgrades to individual applications no longer require suite-level downtime.

OpenShift Version Requirements

MAS 9 requires OpenShift 4.14 or later, with 4.16 being the recommended target for new deployments. This is a hard requirement. Organizations running older OpenShift clusters must plan a cluster upgrade before attempting the MAS migration.

# Example: Minimum OpenShift cluster sizing for MAS 9 (non-HA)
# Control plane nodes
control_plane:
count: 3
vCPU: 4
RAM: 16GB

# Worker nodes for MAS services
worker_mas:
count: 3
vCPU: 16
RAM: 64GB
storage: 200GB

# Worker nodes for databases
worker_data:
count: 3
vCPU: 8
RAM: 32GB
storage: 500GB

Pre-Upgrade Assessment: The Four Pillars

A successful MAS 9 migration depends on thorough assessment across four dimensions. Skipping any of these is the most common cause of failed or delayed upgrades.

Pillar 1: Infrastructure Readiness

Your OpenShift cluster must meet the sizing requirements for MAS 9. IBM publishes detailed sizing guides, but as a rule of thumb, a production MAS 9 deployment with Manage, Monitor, Health, and Predict requires a minimum of 9 worker nodes (3 for MAS services, 3 for databases, 3 for application-specific workloads).

Key infrastructure checks:

• Storage classes: MAS 9 requires ReadWriteMany (RWX) storage for shared components. If your cluster only has RWO storage, you need to provision an NFS or CephFS storage class before installation.
• Network policies: MAS 9 uses OpenShift network policies extensively. Ensure your cluster network plugin supports NetworkPolicy objects (OpenShift SDN or OVN-Kubernetes).
• Certificate management: MAS 9 expects valid TLS certificates for all ingress routes. Self-signed certificates work for development but will cause issues with mobile clients and external integrations in production.
• Registry access: All MAS images are pulled from icr.io/cpopen. Ensure your cluster nodes have outbound access to this registry and that your pull secret is current.

Pillar 2: Data Migration Strategy

Data migration is where most projects hit their first major roadblock. The path depends on your source version:

From Maximo 7.6.1.x (traditional): This is a full database migration. IBM provides the Maximo Migration Manager, which handles schema transformation, data type conversions, and the restructuring of configuration data into the MAS database schema. The migration is not a simple exp/imp operation. The schema differences between 7.6.1.x and MAS 9 are substantial, particularly around:

• Security model: Users and groups move from Maximo's internal tables to the MAS user registry backed by LDAP or SAML.
• Attachment storage: Attachments move from database BLOBs or file system storage to MongoDB-backed document storage.
• Cron tasks: Cron task definitions are restructured. Some become OpenShift CronJobs, others become MAS scheduler entries.
• Conditional expressions: The expression engine has been updated. Complex conditional UIs and workflow conditions should be tested thoroughly.

From MAS 8.x: This is a suite-level upgrade managed through the MAS Operator. The operator handles rolling updates of all components. However, you must still validate:

• Custom automation scripts (they may reference deprecated APIs)
• Custom UI extensions (the UI framework receives updates)
• Integration endpoints (API version changes)

Pillar 3: Customization Inventory

Every Maximo instance has customizations. The question is whether they survive the migration. IBM's stated direction is toward configuration over customization, and MAS 9 reinforces this with a more opinionated extension model.

Create an inventory of every customization in your current system:

-- Identify custom automation scripts
SELECT scriptname, description, sourcescript
FROM maximo.autoscript
WHERE sourcescript IS NOT NULL
ORDER BY scriptname;

-- Identify custom Java classes
SELECT classname, description
FROM maximo.maxjavaclass
WHERE persistent = 1;

-- Identify custom database objects (7.6.1.x)
SELECT objectname, description
FROM maximo.maxobject
WHERE isuserdefined = 1;

For each customization, determine whether it can be replaced by configuration in MAS 9. Many custom field validations, for example, can now be handled through the Automation Script framework without Java code. Custom Java classes that extend MBO behavior are the highest risk and should be prioritized for redesign.

Pillar 4: Integration Impact Analysis

MAS 9 changes the integration landscape significantly:

• MIF (Maximo Integration Framework) remains but runs differently. In traditional Maximo, MIF ran inside the application server JVM. In MAS 9, MIF runs as a separate microservice with its own scaling and resource allocation.
• REST APIs are versioned. MAS 9 introduces API versioning through the API gateway. Existing REST clients may need updates to target the correct API version.
• JMS queues are replaced by Kafka topics. If your integrations use JMS, you need to migrate to Kafka-based messaging or use the MIF bridge.
• OSLC continues to be supported but with updated endpoint URLs.

The Upgrade Execution Plan

With the assessment complete, the actual upgrade follows a structured sequence. Here is a battle-tested execution plan:

Phase 1: Environment Provisioning (Week 1-2)

Provision the target OpenShift environment and install the MAS Operator. Do not install any MAS applications yet. Validate:

# Verify OpenShift version
oc version

# Install MAS Operator from OperatorHub
oc create -f mas-operator-subscription.yaml

# Verify operator is running
oc get pods -n openshift-operators | grep ibm-mas

# Create MAS instance namespace
oc new-project mas-core

Phase 2: Suite Installation (Week 2-3)

Install the MAS suite core. This gives you the suite administration console, user registry integration, and licensing services. Configure SAML or LDAP authentication at this stage and verify that users can log in.

# Suite CR example
apiVersion: core.mas.ibm.com/v1
kind: Suite
metadata:
name: mas-prod
namespace: mas-core
spec:
size: production
license:
accept: true
domain: mas.example.com
certificateIssuer:
name: letsencrypt-prod
type: ClusterIssuer

Phase 3: Data Migration (Week 3-5)

This is the longest phase. Run the database migration using IBM's tools. For 7.6.1.x migrations, expect the process to take several hours for databases over 100GB. Key steps:

1. Run the pre-migration validation tool
2. Execute the schema migration
3. Migrate attachments to MongoDB
4. Rebuild text search indexes in Elasticsearch
5. Validate data integrity with spot checks

Phase 4: Application Installation (Week 5-6)

Install Manage and any additional applications (Monitor, Health, Predict). Configure them against the migrated database.

# Manage application CR
apiVersion: apps.mas.ibm.com/v1
kind: ManageApp
metadata:
name: manage-prod
namespace: mas-core
spec:
bindings:
jdbc:
config: db2-connection
settings:
deployment:
size: production

Phase 5: Customization Migration (Week 6-8)

Migrate and test customizations. This is iterative. Start with the most critical customizations and work through the inventory. Use MAS's built-in automation script migration tools where available.

Phase 6: Integration Cutover (Week 8-9)

Reconfigure integrations to point to the new MAS 9 endpoints. Run parallel integration testing with production data before cutting over.

Phase 7: User Acceptance Testing (Week 9-10)

Full UAT with business users. Focus on workflows, mobile access, reporting, and any business-critical processes.

Phase 8: Go-Live and Hypercare (Week 10-12)

Cut over, monitor closely, and maintain a rollback plan for at least the first week.

Common Upgrade Pitfalls and How to Avoid Them

Pitfall 1: Underestimating Storage Requirements

MAS 9 uses significantly more storage than traditional Maximo. Between MongoDB for attachments, Elasticsearch for search indexes, Kafka for messaging, and the container registry cache, a production deployment can easily consume 500GB to 1TB of persistent storage. Plan storage capacity before you start.

Pitfall 2: Ignoring Network Latency

MAS 9 services communicate heavily over the network. If your OpenShift nodes are spread across data centers with high latency, you will see performance degradation. All MAS components should be deployed within the same OpenShift cluster, ideally in the same availability zone.

Pitfall 3: Skipping the Customization Audit

Organizations that skip the customization audit invariably discover critical customizations that do not work post-migration, often during UAT or worse, after go-live. The time to discover this is during the assessment phase, not during testing.

Pitfall 4: Inadequate User Training

MAS 9's user interface is substantially different from Maximo 7.6.1.x. Users accustomed to the classic UI will need training on the new role-based applications, the updated navigation model, and the mobile-first design philosophy. Budget at least two weeks for user training before UAT.

Pitfall 5: Certificate Expiry During Migration

MAS 9 relies heavily on TLS certificates for inter-service communication. If your certificates have short validity periods, they may expire during a multi-week migration. Use certificates with at least 90-day validity for the migration window, or automate certificate renewal through cert-manager.

Practical Implications

For IT infrastructure teams: You need OpenShift expertise on your team or through a partner. MAS 9 cannot be installed on VMs or bare metal without OpenShift. This is a non-negotiable architectural requirement. If your organization has no container orchestration experience, budget for training or managed OpenShift services (ROSA, ARO) before starting the MAS migration.

For Maximo administrators: Your role changes significantly. Traditional WebSphere administration skills (JVM tuning, EAR deployments, node agent management) become less relevant. New skills in OpenShift administration, Kubernetes troubleshooting, and container orchestration become essential. IBM's MAS administration certification path reflects this shift.

For integration developers: Review every integration endpoint. The MIF REST API endpoints change in MAS 9, and JMS-based integrations need to be redesigned for Kafka. Budget time for integration testing, as this is often the longest pole in the migration tent.

For business stakeholders: The migration to MAS 9 is a multi-month project with significant infrastructure costs. However, the long-term benefits include reduced middleware licensing costs, improved scalability, better mobile support, and access to the full suite of MAS applications (Monitor, Health, Predict, Safety) that are not available on the traditional platform.

Bottom Line

The MAS 9 upgrade is a platform migration, not a version upgrade. Organizations that treat it as a version upgrade will fail. Organizations that treat it as a platform migration, with proper assessment, planning, and resourcing, will succeed.

The key success factors are: OpenShift expertise on the team, a thorough customization audit before migration, realistic storage and network planning, and adequate user training before go-live. The migration is achievable for organizations of any size, but it requires commitment to the containerized architecture that IBM has bet the Maximo platform on.

If you are still on Maximo 7.6.1.x, start planning now. IBM's end-of-support timelines for the traditional platform are not indefinite, and the longer you wait, the more customizations and data you will have to migrate. The best time to start your MAS 9 migration was last year. The second best time is today.