MAS 9 Upgrade Strategy: From Maximo 7.6 to Modern EAM

MAS 9 Upgrade Strategy: From Maximo 7.6 to Modern EAMIBM Maximo 7.6 has served organizations well for nearly a decade, but the clock has run out. Standard support ended on September 30, 2025, and Extended Support concludes on September 30, 2026. For the thousands of organizations still running Maximo 7.6, the migration to IBM Maximo Application Suite (MAS) 9.x is no longer a future consideration. It is an immediate operational imperative.

The good news is that MAS 9.x represents a genuine generational leap. The containerized, OpenShift-based architecture brings弹性 scalability, a modular AppPoints licensing model, embedded AI capabilities, and a modern role-based user experience that eliminates much of the customization overhead that weighed down legacy Maximo environments. The challenge is that the migration from a traditional Java EE application to a containerized, cloud-native platform is not a simple patch. It requires careful planning, infrastructure transformation, and a disciplined approach to customizations, data, and integrations.

This article walks through the complete upgrade lifecycle: readiness assessment, environment build, data migration, customization rationalization, go-live execution, and post-go-live hypercare. Whether you are mid-planning or just starting, this guide provides the technical grounding you need to navigate the migration with confidence.

Understanding the MAS 9 Architecture Shift

The first thing every Maximo team needs to understand is that MAS 9 is not just a new version of Maximo. It is a fundamentally different architecture. Maximo 7.6 was a monolithic Java EE application deployed on WebSphere or WebLogic, with a relational database backend and a separate UI layer. MAS 9 is a containerized application suite deployed on Red Hat OpenShift, with each application (Manage, Monitor, Predict, Health, Mobile, Visual Inspection) running as an independent service with shared foundation components for identity, licensing, and workspace management.

The foundation layer, called MAS Core, provides the shared services that all MAS applications depend on: identity and access management, the AppPoints licensing engine, workspace management, and the underlying Kubernetes/OpenShift orchestration. Maximo Manage is the EAM application within the suite, roughly equivalent to what Maximo 7.6 was, but rebuilt for the containerized world. The other applications (Monitor, Predict, Health, Mobile, Visual Inspection) are modular add-ons that share the same data model and security framework.

This architectural shift has several practical implications. First, your IT team needs OpenShift expertise. Whether you deploy on IBM Cloud, AWS, Azure, or on-premises, the underlying platform is Red Hat OpenShift Container Platform. Second, the deployment model is operator-based. IBM provides operators that handle installation, upgrades, and configuration through Kubernetes custom resources rather than traditional installers. Third, the licensing model changes from perpetual or term licenses to AppPoints, a shared pool of entitlements that can be dynamically allocated across MAS applications based on usage needs.

For organizations coming from Maximo 7.6, this means three new skill areas: OpenShift administration, Kubernetes-based troubleshooting, and operator-based lifecycle management. Investing in training before the migration begins is one of the highest-leverage decisions a project team can make.

Readiness Assessment: What to Inventory Before You Touch OpenShift

The readiness assessment is the foundation of a successful migration. Skipping or rushing this phase is the single most common cause of delayed go-lives and budget overruns. The goal is to create a comprehensive inventory of everything in your current Maximo 7.6 environment that will be affected by the migration.

Start with the database. MAS 9 supports direct upgrades from Maximo 7.6.0.10, 7.6.1.2, or 7.6.1.3. If you are on an earlier fixpack, you must upgrade to one of these levels before attempting the migration. Validate your database platform against the MAS 9 compatibility matrix. DB2 and Oracle are the primary supported platforms, with DB2 12.1 support added in recent MAS 9.x releases. Run the Integrity Checker in report mode and resolve any errors before activation. Confirm there are no pending database configuration changes, and disable custom database triggers before the upgrade process begins.

Next, inventory customizations. This is where most organizations underestimate the effort. You need to document every Java customization, automation script, custom application, modified screen, custom workflow, BIRT report, integration interface, cron task, and third-party add-on. For each item, categorize it into one of three buckets: replace with native MAS feature, migrate with modification, or retire.

MAS 9 includes many features that were common customization targets in Maximo 7.6. The Maximo Application Framework (MAF) replaces much of the custom UI work that organizations did in Application Designer. The role-based applications provide modern, mobile-friendly interfaces for technicians, supervisors, and managers. The Automation Scripts engine is more capable and now supports Python in addition to JavaScript. The Workflow Designer is more visual and easier to configure. Many organizations find that 30 to 50 percent of their Maximo 7.6 customizations can be replaced by native MAS features.

For customizations that need to migrate, package them into MAS-compatible formats following IBM migration guidelines. Java customizations need to be reviewed for Java 17 compatibility, which is the runtime version in MAS 9.1 and later. Review your integration architecture: the Integration Framework is still present in MAS, but the external integration patterns have changed. REST APIs are the primary integration method, with Kafka-based event streaming for real-time data exchange.

Document your current security model, including LDAP/SAML configuration, security groups, and data restrictions. MAS uses a different identity model based on OpenShift identity providers and MAS Core identity management. Plan the mapping from your current authentication model to the new one early.

Finally, assess your integration landscape. Every interface that touches Maximo needs to be documented: enterprise integrations, file-based imports, cron-driven exports, real-time API calls, and any custom middleware. For each integration, identify the protocol, authentication method, data format, frequency, and business criticality. This inventory becomes the integration migration plan.

Building the OpenShift Environment and Deploying MAS

Once the readiness assessment is complete, the next phase is building the target environment. This is where OpenShift expertise becomes critical. If your organization does not have in-house OpenShift skills, engage an IBM partner or invest in training immediately.

The OpenShift cluster sizing depends on your MAS deployment scope. A minimal MAS Core plus Manage deployment for a mid-size organization typically requires 3 worker nodes with 16 vCPU and 64 GB RAM each. A full suite deployment with Monitor, Predict, Health, and Mobile can easily require 6 to 8 worker nodes with 32 vCPU and 128 GB RAM each. IBM provides detailed sizing guides that account for user count, asset count, transaction volume, and data history. Under-provisioning is a common cause of performance issues in early MAS deployments, so size for your peak workload plus 30 percent headroom.

The deployment process follows a defined sequence. First, install and configure the OpenShift Container Platform itself. Use an even-numbered OCP version (4.14 or later) because IBM's Cloud Pak dependencies require specific OCP versions. Next, install the IBM Operator Catalog, which provides the operators for MAS Core and each MAS application. Then install MAS Core, which sets up the foundation services: identity, licensing, workspace, and the internal certificate authority.

After MAS Core is operational, deploy Maximo Manage. The ManageWorkspace custom resource defines the configuration: database connection, attachment storage type (file-based or object-based), JVM settings, and pod resource limits. Manage connects to your cloned Maximo database and activates the upgrade, which transforms the database schema from 7.6 to 9.x format.

apiVersion: mas.ibm.com/v1
kind: ManageWorkspace
metadata:
  name: maximo-manage-prod
  namespace: mas-maximo
spec:
  config:
    database:
      type: db2
      hostname: db2-prod.internal.example.com
      port: 50000
      name: MAXDB76
      sslEnabled: true
    attachment:
      type: object-storage
      endpoint: https://s3.us-east-1.amazonaws.com
      bucket: maximo-attachments-prod
    jvm:
      heapSize: "4096"
      maxMemory: "8192"
    pods:
      resources:
        requests:
          cpu: "4"
          memory: "8Gi"
        limits:
          cpu: "8"
          memory: "16Gi"

After Manage is deployed and the database upgrade is complete, install any additional MAS applications you need. Each application is deployed via its own operator and custom resource. Monitor requires sensor data pipelines and integration with Maximo Manage for asset context. Predict requires a CP4D (Cloud Pak for Data) instance for model training and scoring. Health connects to Manage for asset and failure data. Mobile is deployed as a set of mobile app definitions that sync with Manage.

The typical timeline for this phase is 1 to 2 months for a standard deployment. Plan for at least two non-production environments (dev/test and staging) before production. The first deployment will surface configuration issues that subsequent deployments can avoid.

Customization Migration and Data Strategy

Customization migration is the most labor-intensive part of a MAS 9 upgrade. The goal is not to replicate every customization from Maximo 7.6 but to evaluate each one against the native capabilities of MAS 9 and reduce technical debt wherever possible.

For Java customizations, the migration path depends on the complexity and business value of each customization. Simple Java classes that extend Maximo business objects or implement custom MBOs can often be migrated with minimal changes, primarily updating import statements and API references for the Java 17 runtime. Complex customizations that deeply hook into the Maximo UI layer or use unsupported internal APIs may need to be rewritten as automation scripts or MAF applications.

Automation scripts are the preferred customization mechanism in MAS 9. They are easier to maintain, do not require compilation, and are more portable across environments. If a customization can be expressed as an automation script, convert it. The MAS automation script engine supports JavaScript, Python, and the Maximo expression language.

# Example: Auto-assign work order priority based on asset criticality
# Automation Script - Object: WORKORDER - Event: Save - Before Save
from psdi.mbo import MboConstants
asset = mbo.getMboSet("ASSET").getMbo(0)
if asset is not None:
    criticality = asset.getString("CRITICALITY")
    if criticality == "HIGH":
        mbo.setValue("WOPRIORITY", 1, MboConstants.NOACCESSCHECK)
    elif criticality == "MEDIUM":
        mbo.setValue("WOPRIORITY", 3, MboConstants.NOACCESSCHECK)
    else:
        mbo.setValue("WOPRIORITY", 5, MboConstants.NOACCESSCHECK)

For data strategy, the key decision is how much historical data to migrate. Maximo 7.6 environments often contain 10 to 15 years of transactional data: work orders, asset history, meter readings, failure records, and inventory transactions. Migrating all of this data into MAS extends the upgrade time, increases storage costs, and can impact performance. A common approach is to migrate active data (typically the last 3 to 5 years) into MAS and archive older data in a read-only reporting database or data warehouse.

IBM provides migration tools for the database upgrade from 7.6 to 9.x. The tool extracts the 7.6 database, transforms the schema, and loads it into the MAS Manage database. The process is largely automated but requires validation. After the migration, run data integrity checks, verify asset hierarchies, confirm that failure codes and job plans are intact, and validate that security groups and data restrictions are correctly mapped.

For integrations, the migration approach depends on the integration type. REST API integrations from Maximo 7.6 generally work in MAS with endpoint changes. The Maximo Integration Framework is present in MAS with the same object structures, enterprise services, and external systems. However, the base URL changes, authentication shifts to OAuth 2.0 or API keys, and some internal MBO relationships may have changed. Test every integration in the non-production environment before production cutover.

Go-Live Execution and Post-Go-Live Hypercare

The go-live execution is the culmination of months of preparation. The recommended approach is a phased cutover, not a big-bang migration. Start with a pilot: select one to two sites, one asset family, or one business unit and go live with that subset first. This validates the migration rules, data quality, user experience, and integrations in a controlled environment before exposing the full organization to the new system.

Before go-live, complete a full regression test cycle. This includes all business processes (work order lifecycle, PM execution, inventory transactions, procurement flow, inspection completion), all integrations (REST APIs, Kafka events, file imports), all customizations (automation scripts, MAF applications, workflow processes), and all reports. User acceptance testing should involve representatives from every user role: technicians, planners, supervisors, storekeepers, and managers.

The cutover weekend typically follows this sequence: stop all Maximo 7.6 cron tasks and integrations, take a final database backup, run the database upgrade, deploy the production MAS environment, connect to the upgraded database, validate core functionality, and open the system to users. Plan for a 12 to 24 hour cutover window with a dedicated war room team.

Post-go-live hypercare is critical. Plan for 2 to 3 months of dedicated support immediately after go-live. During hypercare, have a dedicated support team on-site or on-call that can quickly resolve user issues, fix configuration problems, and tune performance. Track issues by category (data, configuration, integration, training, performance) and prioritize fixes based on business impact.

Common hypercare issues include: users unable to find applications because the navigation is different from 7.6, reports that do not render correctly due to BIRT version changes (MAS 9 uses BIRT 4.16), integrations that fail due to authentication changes, and performance issues from under-provisioned OpenShift resources. Having a pre-built knowledge base of common issues and resolutions accelerates hypercare resolution.

Monitor system health during hypercare using the OpenShift monitoring stack. Prometheus and Grafana, which are built into OpenShift, provide real-time visibility into pod health, resource utilization, and application performance. Set up alerts for critical metrics: pod restart count, database connection pool utilization, JVM heap usage, and API response times.

After hypercare, transition to continuous improvement. MAS 9.x releases monthly maintenance updates via the IBM Operator Catalog. Subscribe to the stable channel for production updates and the feature channel for preview capabilities. The channel subscription model means you no longer need to download and run installers for updates. The operator handles upgrades automatically or with manual approval, depending on your configuration.

Practical Implications

For organizations still on Maximo 7.6, the September 2026 Extended Support deadline is a hard deadline. After that date, IBM will no longer provide fixes, security patches, or technical support for Maximo 7.6. Organizations that miss this deadline will be running an unsupported system, which creates operational risk, security exposure, and compliance issues.

The migration timeline from assessment to go-live typically runs 6 to 9 months for a mid-size organization. Larger organizations with complex customizations and many integrations should plan for 9 to 12 months. Starting the readiness assessment now, in mid-2026, means a go-live in early to mid-2027, which is cutting it close to the deadline. If you have not started, begin immediately.

Budget for training as a first-class expense, not an afterthought. OpenShift administration, MAS configuration, and the new role-based application model all require new skills. Sending the IT team to a one-week OpenShift course and a MAS configuration workshop before the migration begins will pay for itself many times over in avoided mistakes and accelerated problem resolution.

Engage all stakeholders early. The migration from Maximo 7.6 to MAS 9 is not just an IT project. It affects maintenance teams, procurement, operations, and executive leadership. Discovery workshops that bring these groups together surface requirements, constraints, and potential conflicts early in the process.

Bottom Line

The migration from Maximo 7.6 to MAS 9 is a significant undertaking, but it is a well-traveled path with documented best practices, IBM tooling, and partner expertise available. The architectural shift to containerized, cloud-native deployment brings real benefits: scalability, modularity, embedded AI, and a modern user experience that reduces customization burden. The key success factors are early and thorough readiness assessment, investment in OpenShift skills, aggressive customization rationalization, phased go-live with pilot validation, and a properly resourced hypercare period. With the September 2026 Extended Support deadline looming, the time to start is now.