MAS 9.1 Architecture Deep Dive: Planning Your Upgrade from Maximo 7.6.1.3

Upgrading from Maximo 7.6.1.3 to IBM Maximo Application Suite (MAS) 9.1 is not a version bump. It is a fundamental platform change. Where Maximo 7.6.x was a Java EE monolith typically deployed on WebSphere or WebLogic with a Db2 or Oracle backend, MAS 9.1 is a cloud-native suite running on Red Hat OpenShift Container Platform with containerized workloads, foundation services, and a new licensing model based on AppPoints. Organizations that treat this as a simple install will encounter weeks of troubleshooting, integration rewrites, and infrastructure rework.

This article walks through the architectural shifts introduced in MAS 9.1, the preparation work you need to do in your existing 7.6.1.3 environment before migration, and the technical decisions that determine whether your upgrade succeeds or stalls. Whether you are running Maximo on-premises on Windows, on AIX, or already on a containerized pilot, the patterns below will help you sequence work, manage risk, and avoid the most common pitfalls.

The Platform Shift: From Java EE to Cloud-Native

The biggest mental model change between 7.6.1.3 and MAS 9.1 is the move from a monolithic application server to a Kubernetes-native architecture. MAS 9.1 runs on Red Hat OpenShift 4.16 (or later in the 4.16 release train), which is the supported runtime for both production and development environments. Every component of Maximo Manage, from the UI bundle to the cron task workers, the MIF (Maximo Integration Framework), and the report bundle, is now deployed as a separate set of containers managed by Kubernetes operators.

This separation gives you independent scaling, rolling updates, and the ability to isolate workloads that historically competed for the same heap. In 7.6.1.3, if cron tasks and user-facing transactions ran in the same JVM, a runaway escalation could degrade the entire user experience. In MAS 9.1, you can define separate ManageWorkspace custom resources for UI, cron, MIF, and report bundles, each with its own CPU, memory, and replica counts. Lab testing shows that separating these workloads alone can yield 30 to 40 percent improvement in transaction response times at the same hardware footprint.

The ManageWorkspace custom resource is the primary tuning surface. A typical production deployment might specify three replicas for the UI bundle at 4 CPU and 8 GB of memory each, two replicas for the cron bundle at 2 CPU and 4 GB, and a single MIF replica at 4 CPU and 8 GB. The exact values depend on user count, integration volume, and cron density, but the principle is the same: right-size each workload independently rather than scaling a single monolith.

Java 17 is now mandatory. Every Java customization, every custom class, every JSP, and every automation script that touches Java must be compatible with Java 17. In practice this means removing dependencies on removed APIs, updating reflection-based code that may be blocked by the Java 17 module system, and recompiling all custom Java against the new JDK. Code that worked on Java 8 will not deploy to MAS 9.1 without recompilation, and in some cases without refactoring.

Preparing Maximo 7.6.1.3: The Migration Inventory

Before you touch the MAS installer, you need a complete inventory of your 7.6.1.3 environment. The IBM Community and PacMUG communities have published detailed preparation guides, and they all converge on the same set of required activities. The first step is to catalog every Java customization by type. Custom Mbo classes, MboSet extensions, custom field classes, condition evaluators, integration processors, and workflow implementations all need to be inventoried, version-controlled, and assessed for Java 17 compatibility.

The second step is to extract every automation script. Automation scripts are stored in the database and can be exported as XML bundles. Each script has a launch point, a scripting language (Jython or JavaScript), and event bindings. Scripts that depend on deprecated Maximo APIs, scripts that use external Java classes not in the default classpath, and scripts that have grown beyond maintainability should all be flagged for review.

The third step is to document every integration. For each MIF endpoint, document the protocol (JMS, SOAP, HTTP, file-based), the authentication mechanism (maxauth tokens, LDAP, certificate-based), the data shape, the trigger, and the downstream system. In MAS 9.1, JMS and SOAP integrations must be migrated to Kafka events and REST APIs. Authentication moves from maxauth tokens to MAS API keys or OAuth. This is not optional. The JMS providers and SOAP stacks that worked in 7.6.1.3 are not present in the MAS container image.

The fourth step is to engage business stakeholders and identify obsolete components. Every custom feature, every niche report, every unused field has a carrying cost during a migration. Use the upgrade as a forcing function to retire what is no longer needed. If a custom field has not been queried in the past 18 months, archive it. If a custom Java class duplicates out-of-the-box functionality added in a later fix pack, remove it.

The fifth step is to catalog configurations. Workflows, database configurations, escalations, conditions, UI changes, cron task definitions, and security groups all need to be inventoried. The Database Configuration application in 7.6.1.3 is your friend here. Export all DB config as a config XML bundle. Capture all workflow process definitions. List every escalation, every condition, every launch point, and every cron task instance.

Licensing: From CPU/USER to AppPoints

One of the most disruptive changes in the MAS model is licensing. Where Maximo 7.6.x was licensed by named users and processor value units, MAS is licensed by AppPoints. AppPoints are a consumption-based metric that bundles EAM, APM, mobile, and add-on capabilities into a single entitlement pool. A technician using Maximo Mobile consumes AppPoints. A planner using Maximo Asset Investment Planning consumes AppPoints. A monitor ingesting IoT data consumes AppPoints.

The implication for upgrades is that you must map your current license entitlements to AppPoint consumption before you cut over. IBM provides a license mapping worksheet, and your IBM representative can help model the AppPoint cost of your current usage profile. In most cases, organizations that already use Maximo Mobile, Health, and Predict find that AppPoints are cost-neutral or slightly favorable. Organizations that add capabilities such as Maximo AI Service, Maximo Real Estate and Facilities, or Asset Investment Planning will see AppPoint consumption rise.

Plan the license conversion early. The cutover from 7.6.1.3 to MAS is not the right time to renegotiate licensing. Lock in your AppPoint entitlement before migration begins so that the cutover is operationally smooth and the contract team is not negotiating in parallel with the technical team.

Customization Archive: The MAS Deployment Model

In 7.6.1.3, customizations were typically deployed by copying compiled Java classes into the Maximo installation directory, updating the classpath, and restarting the application server. In MAS 9.1, customizations are packaged as customization archives and deployed through the MAS Administration application or the OpenShift CLI.

A customization archive is a tar file that contains compiled Java classes, JARs, automation script XML files, database config XML, and a manifest describing the deployment. The MAS operator picks up the archive and rolls out a new version of the affected bundle. This model is powerful because it is GitOps-friendly. You can store customization archives in a container registry, version them with Git, and roll forward or back using standard OpenShift deployment patterns.

The implication is that every customization must be reviewable, reproducible, and deployable from a single artifact. The days of "I have a fix in production that I never put in source control" are over. If your team has a long tail of hotfixes, you need to refactor them into a proper customization archive before migration. This is one of the largest sources of migration delays observed in the field.

A typical customization archive manifest might look like this:

apiVersion: v1
kind: ConfigMap
metadata:
  name: manage-customization-manifest
  namespace: mas-manage
data:
  manifest.yaml: |
    name: acme-asset-extensions
    version: 2.4.1
    dependencies:
      - name: maximo-manage
        version: ">=9.1.0"
    components:
      - type: java
        classes: /opt/IBM/customization/classes
        classpath:
          - acme-asset-extensions-2.4.1.jar
          - acme-integration-helpers-1.7.0.jar
      - type: script
        path: /opt/IBM/customization/scripts
      - type: dbconfig
        path: /opt/IBM/customization/dbconfig.xml
    healthCheck:
      timeoutSeconds: 600
      failurePolicy: rollback

This manifest declares the customization version, the Manage bundle version it requires, the components included, and the health check policy. The MAS operator uses this to determine deployment order, validation steps, and rollback behavior. Once published to the cluster, the operator applies the archive to the next available rollout of the Manage bundle.

The Upgrade Path: Stage, Pilot, Cutover

A successful MAS 9.1 upgrade follows a three-stage approach. The first stage is environment readiness. You need a production-grade OpenShift cluster sized for your Maximo workload. The minimum is typically a three-master, three-worker cluster with sufficient storage for the Db2u database and block storage for the Manage workspace. Network latency between the application pods and the database must be under 10 milliseconds for production, with 50 milliseconds as the absolute upper bound. Storage throughput must exceed 250 MB per second with at least 10 IOPS per GB.

The second stage is a pilot. Pick a single site, a single business unit, or a defined user group. Migrate their Maximo environment first. Run parallel operations for 30 to 90 days. Validate integrations, performance, and user acceptance. Document every issue. Build a runbook. The pilot is not a dress rehearsal; it is a production system that you will keep. Use it to learn.

The third stage is phased cutover. Migrate additional sites, business units, or user groups in waves. Each wave should be no larger than your support team can troubleshoot in a 48-hour window. Between waves, apply lessons learned, update the runbook, and tune the OpenShift infrastructure. A typical multi-site migration takes 6 to 12 months from kickoff to full cutover.

Database Considerations: Db2u, Db2 Warehouse, and Beyond

MAS 9.1 supports Db2u (the OpenShift-native Db2 operator), Db2 Warehouse, and Oracle as the database backend. The most common production deployment is Db2u running in the same OpenShift cluster as the Manage application bundles. This gives you the lowest network latency, the tightest integration with OpenShift storage, and the simplest operational model.

Db2u requires specific configuration for Maximo. The recommended db2set settings include db2_workload=maximo and explicit configuration of the buffer pool, log file size, and table spaces. Index statistics must be refreshed regularly. Runstats and reorg should be scheduled weekly on the largest tables. For very large tables (work order, asset, poline, and invoice history), consider partitioning strategies if your Db2 license supports them, or archiving records older than one year if it does not.

The isolation level settings recommended for MAS 9.1 are snapshot isolation with read-committed snapshot enabled. The SQL commands are:

ALTER DATABASE MAXDB
SET ALLOW_SNAPSHOT_ISOLATION ON

ALTER DATABASE MAXDB
SET READ_COMMITTED_SNAPSHOT ON

These settings reduce lock contention and improve concurrency. The tempdb tablespace should be placed on dedicated high-speed disks separate from the main data tablespace. Transaction logs should be on a third set of high-speed disks. This three-way split (data, logs, tempdb) is standard Db2 best practice and applies equally to MAS deployments.

Common Pitfalls and Field-Tested Patterns

The most common migration pitfall is underestimating the customization refactor. Teams often assume that automation scripts will "just work" because they are stored as text in the database. In practice, scripts that depend on internal Maximo APIs can break in subtle ways. A script that calls a method signature that has changed in the new bundle can throw a NoSuchMethodError at runtime that does not surface in unit tests. Run every script in a staging environment before cutover.

The second pitfall is treating the OpenShift cluster as an afterthought. The cluster is the runtime. If you size it too small, every workload will fight for CPU and memory. If you size it too large, you pay for capacity you do not use. Right-size using the ManageWorkspace custom resource and the Db2u custom resource. Start conservative and scale up based on observed load.

The third pitfall is skipping the integrity check. The integrity check tool in 7.6.1.3 reports on autokey mismatches, same-as field configuration errors, and database structure issues. Run it in report mode, address every error, run it again in a month, compare results. If autokey issues exist in 7.6.1.3, they will block the upgrade to MAS. Fix them first.

A field-tested pattern is to use SAML authentication from day one. LDAP requires direct network access from the OpenShift pods to Active Directory, which is a security concern for most enterprise IT teams. SAML delegates authentication to an identity provider (Okta, Microsoft Entra ID, ADFS, Auth0) and supports multi-factor authentication natively. Configure SAML before cutover and require MFA for all administrative users.

Practical Implications

For infrastructure teams, MAS 9.1 means investing in OpenShift skills. Your Linux administrators become Kubernetes administrators. Your WebSphere tuning expertise becomes ManageWorkspace tuning expertise. Your Db2 DBA skills transfer directly, but the operational tools change. Budget for training, certification, or external support during the first 6 to 12 months of the migration.

For application teams, MAS 9.1 means embracing GitOps. Every customization, every configuration, every automation script lives in source control. Every deployment is reproducible. Every rollback is a single command. This is a higher bar than 7.6.1.3, but it is also a more sustainable model once you adopt it.

For project sponsors, MAS 9.1 means a realistic 6 to 18 month migration timeline. Pilot, parallel run, phased cutover, and decommissioning of the legacy environment all take time. Build the schedule with these phases explicit. Communicate it to stakeholders. Adjust expectations away from "weekend cutover" and toward "phased migration with measurable gates."

For security teams, MAS 9.1 means retiring the maxauth token model. API keys, OAuth, and SAML are the supported authentication paths. Plan for token rotation, secret management through Kubernetes secrets or an external vault, and TLS everywhere. The MAS installation defaults to self-signed certificates; replace them with certificates from your enterprise CA before cutover.

Bottom Line

The move from Maximo 7.6.1.3 to MAS 9.1 is a platform transformation, not a software upgrade. Java 17, OpenShift, AppPoints, and customization archives are the new operating model. Organizations that prepare their customization inventory, refactor their integrations, and right-size their OpenShift infrastructure can complete the migration in 6 to 12 months. Organizations that treat it as a simple install will spend twice as long and miss the business value.

Start with the customization inventory. Inventory your Java classes, automation scripts, integrations, and configurations. Map them to AppPoint consumption. Build a customization archive. Pilot on a single site. Cut over in waves. Document everything. The work is significant, but the result is a more maintainable, more scalable, and more AI-ready asset management platform.

If you are evaluating MAS 9.1 for the first time, treat it as a strategic platform decision, not a tactical upgrade. The investment pays back through reduced infrastructure overhead, faster customization deployment, and access to capabilities such as Maximo AI Service, Asset Investment Planning, and the unified Asset and Locations dashboard. The clock is ticking. MAS 9.1 is the supported platform through at least 2028, and MAS 9.2 is projected for mid-2026. Plan now.