MAS 9.1 Goes Multi-Architecture: S390x, Power, and the Foundation Service You Should Already Be Using

MAS 9.1 Goes Multi-Architecture: S390x, Power, and the Foundation Service You Should Already Be UsingThe Maximo Application Suite 9.1 release is not just another feature drop. It is a structural shift in how the platform is built, deployed, and administered. Three changes matter most for anyone planning a 9.0 to 9.1 upgrade, sizing new infrastructure, or rationalizing their security and identity architecture: native multi-architecture support for IBM Z and Power, the consolidated Foundation Service, and a refined set of single sign-on and identity options that finally make sense in a hybrid enterprise.

For teams that have been on MAS 8.x for the last three to four years, 9.1 is also the first release where the "stay on-prem on x86" and "go hybrid" paths converge. You can now run the same MAS core and Maximo Manage base on Red Hat OpenShift Container Platform across x86_64, S390x, or ppc64le without forking the deployment model. That single capability unlocks procurement decisions that were previously blocked by an assumption that Maximo only runs on commodity hardware.

This article walks through what the architecture change means in practice, how the Foundation Service replaces a stack of legacy administrative surfaces, and the upgrade sequencing decisions that will save you weeks of pain. It closes with a configuration example you can use to validate the new model in a non-prod cluster before you commit to a production migration.

What Multi-Architecture Support Actually Changes

Before 9.1, Maximo Application Suite core and Maximo Manage base were effectively x86_64-only. You could run the OpenShift control plane on other architectures in theory, but the MAS operators and the Manage build chain depended on x86-specific container images. That made any z16 or Power E1080 conversation about Maximo a short conversation. Starting in MAS 9.1, IBM publishes the core and Manage base images for three architectures: amd64 (the default), s390x (IBM Z), and ppc64le (IBM Power).

The practical consequence is that you can stand up MAS 9.1 on an existing OpenShift cluster running on IBM Z or Power, reuse your existing SUSE / Red Hat subscription, your existing storage classes, your existing backup tooling, and your existing network segmentation. The MAS install process, the custom resource definitions, the database requirements, and the upgrade tooling are identical across architectures. There is no second build pipeline to maintain. There is no "Maximo on Z" SKU or "Maximo on Power" SKU.

The IBM documentation is explicit that this is about using existing Red Hat OpenShift Container Platform capabilities for scalability and resilience. In other words, IBM is not selling a new appliance. They are saying: if your enterprise standard is z16 for regulated workloads, MAS now runs there with the same operational model you use for any other OCP workload. If your enterprise standard is Power because you have AIX adjacencies and a HANA-style data tier, MAS now runs there too.

For a platform team, the decision tree gets simpler. The question is no longer "can Maximo run on the platform we have already procured?" It is "which OpenShift cluster is the right home for this workload, and do we have the storage and network profile to support it?" For most enterprises, the answer is the cluster that already meets your disaster recovery objectives, your network latency budget, and your security segmentation requirements. The architecture question is downstream of that.

There are real differences to understand, however. The S390x and ppc64le builds are validated for the same MAS core and Maximo Manage base capabilities, but the supporting ecosystem varies. The IBM Maximo Operator Catalog ships the same content for all three architectures, but some optional add-ons, particularly those that depend on third-party machine learning or computer vision services, may still have amd64-only dependencies. Before you commit, validate the specific add-ons you use against the architecture-specific catalog.

The Foundation Service and the End of the Admin Icon

One of the more quietly important changes in MAS 9.1 is the introduction of the Foundation Service. In previous releases, administrative tasks were spread across application-specific settings, an Application switcher, and an administration icon in the header. If you wanted to add a user, configure a security group, or tune a setting for a specific application, you navigated to that application, then drilled into the application-level administration. The Foundation Service consolidates these tasks.

In practice, the Foundation Service is a single suite-wide administrative surface that handles user management, security configuration, and a subset of common data and application settings. It does not replace every per-application configuration screen, but it removes the most common friction. Adding a user, mapping them to a security group, granting application access, and verifying their roles can now happen in one place instead of three or four.

For anyone who has onboarded a new reliability engineer or contract administrator, the operational impact is significant. The old flow required navigating to the user application, creating the record, navigating to the security groups application to map group membership, navigating to the application access settings, and then verifying in each target application that the user had the right start center and right options. The new flow walks the administrator through the same decisions in a single flow, with validation feedback as you go. The result is faster onboarding, fewer orphaned user records, and less drift between what the user can theoretically do and what they can actually do.

The Foundation Service also unifies viewing. Capabilities that were previously visible only inside individual applications are now visible from a single navigation surface. This is a small change in the user interface but a meaningful change in operations. If your help desk team gets a ticket that says "I cannot see the Work Order Tracking application," they can now diagnose that ticket from a single user record view, rather than logging into multiple applications to validate the configuration. The mean time to resolution drops because the data is in one place.

The migration story for existing customers is straightforward but should not be skipped. As you upgrade to 9.1, the Foundation Service initializes from your existing user registry and existing security configuration. There is no re-import step, no data migration, and no separate license to assign. The new administrative surface is available immediately after upgrade. The legacy per-application administration screens remain available for compatibility, and IBM has stated that they will continue to be supported through the 9.x line. You do not need to migrate your administration process on day one. You should, however, plan to migrate it within the first 60 to 90 days after upgrade, because the new model is what IBM will continue to invest in.

SSO, OIDC, LDAP, and the New Identity Model

The identity and access management story in MAS 9.1 is the most substantial refactor since the move to the suite-level user registry. Three changes are worth tracking.

First, OpenID Connect (OIDC) is now a first-class single sign-on option. Before 9.1, OIDC was possible but required custom configuration and was not officially documented as a primary authentication path. In 9.1, IBM documents the OIDC configuration flow, supports it as a production-grade option, and provides a custom resource pattern for connecting MAS to an external OIDC provider such as IBM Verify, Microsoft Entra ID, Okta, or any compliant identity provider. The flow supports standard claims, group claims for authorization, and refresh token handling. For organizations that have standardized on OIDC as their primary authentication protocol, this removes a long-standing integration gap.

Second, multiple LDAP user registry synchronizations are now supported. In previous releases, you could configure MAS to synchronize with a single LDAP server. In 9.1, you can configure multiple LDAP synchronizations, which means you can synchronize users and groups from more than one directory server into your local MAS user registry. The immediate use case is supporting acquisitions and divestitures, where one part of the organization authenticates against one directory and another part authenticates against a different directory. The longer-term use case is supporting hybrid directory topologies where a primary corporate directory is supplemented by a regional directory or a partner directory.

Third, password expiration policy is now configurable, with grace period support. The system property for password validity period lets you define how long a password is valid before the user is required to change it. The grace period property lets you define a window during which the user can still log in after expiration. These are not groundbreaking features, but they are the kind of basic policy controls that auditors expect, and their absence in previous releases was a real friction point for organizations that had to align MAS with broader enterprise security policy.

The new user management APIs are worth understanding as well. The pre-9.1 user management APIs are replaced by a new set that provides greater granularity for user authorization. The practical impact is that you can now script user provisioning with finer-grained control over what the user can do in each application, rather than relying on a small set of coarse-grained roles. For organizations that have invested in identity governance and administration platforms, this is the integration point you have been waiting for.

Upgrade Sequencing: The Order That Saves You Weeks

The 9.1 upgrade is a multi-step process, and the order matters. The first decision is which version of the IBM Maximo Operator Catalog you are targeting. As of mid-2026, the catalog naming convention is v9-YYMMDD-arch, with the most recent stable catalogs shipping quarterly. Choose a catalog that has been Generally Available for at least 30 days, and that has at least one patch release behind it. This gives the community time to surface and resolve upgrade issues before you encounter them.

The second decision is whether you are doing a control plane upgrade first or a workload upgrade first. In most cases, you should upgrade the OpenShift Container Platform control plane first, separately from the MAS operator and workload upgrade. This gives you a clean rollback path if the OCP upgrade fails, and it isolates the MAS-specific risk. Once the control plane is on the target version, you upgrade the MAS operator, and then you upgrade the managed applications one at a time.

For the MAS 9.1 upgrade specifically, the order should be: core, then IoT (if installed), then Manage, then Health (if installed as a separate application), then Predict (if installed), then the remaining add-ons in order of criticality. This order matters because some add-ons have version dependencies on the core, and you want to be able to validate each stage before moving to the next.

Before you start, capture a full database backup, a full PVC snapshot, and a verified restore in your non-prod environment. The restore test is non-negotiable. A backup you have never restored is a hope, not a backup. Run the restore against a copy of the production data in a non-prod environment, validate that Manage comes up cleanly, and validate that the integration framework, the cron tasks, and the escalation rules all work. This takes two to three days in most environments, and it is the single highest-value insurance you can buy.

During the upgrade, watch the operator logs. The MAS operator logs surface dependency mismatches, license issues, and configuration validation errors that would otherwise cause the upgrade to fail at a later, more expensive stage. A clean operator log through the first 30 minutes of the upgrade is a strong signal that the rest of the upgrade will proceed smoothly.

After the upgrade, validate the Foundation Service migration by spot-checking five to ten user records. Confirm that each user has the expected security group, the expected application access, and the expected default start center. If you find drift, address it before you hand the environment back to the business. Drift found in the first week is easy to fix. Drift found in the first quarter becomes a project.

A Configuration Example: Validating the New Identity Model in Non-Prod

Before you commit to a production migration, validate the new identity model in a non-prod cluster. The following custom resource pattern is a starting point for configuring OIDC against a test identity provider, and it is the kind of validation you should be able to complete inside a single working day.

apiVersion: core.mas.ibm.com/v1
kind: MASAppWorkspace
metadata:
  name: oidc-validation
  namespace: mas-dev
spec:
  settings:
    security:
      oidc:
        enabled: true
        provider:
          issuer: https://test-idp.example.com
          clientId: mas-oidc-client
          clientSecretRef:
            name: oidc-client-secret
            key: client-secret
        claims:
          username: preferred_username
          email: email
          groups: groups
        groupFilter:
          - maximo-users
          - maximo-admins
      ldap:
        synchronizations:
          - name: primary-corp
            server: ldap://ldap-primary.corp.example.com
            baseDN: dc=corp,dc=example,dc=com
            userFilter: (objectClass=person)
            groupFilter: (objectClass=group)
          - name: regional-partner
            server: ldap://ldap-partner.partner.example.com
            baseDN: dc=partner,dc=example,dc=com
            userFilter: (objectClass=person)
            groupFilter: (objectClass=group)
      passwordPolicy:
        maxAge: 90
        gracePeriod: 7

The validation steps are: deploy the custom resource, wait for the Foundation Service to reconcile, attempt a login through the OIDC provider, verify that the user record is created in the MAS user registry, verify that the group memberships are mapped correctly, and verify that the password expiration policy is enforced on a test account. Each of these steps has a measurable pass or fail outcome. Document the results and attach them to the upgrade runbook.

Practical Implications

The 9.1 architecture changes are not theoretical. They change the procurement conversation, the operations conversation, and the security conversation. For platform teams, the multi-architecture support means that the cluster decision can be made on operational grounds rather than software compatibility grounds. The Foundation Service means that the administrative surface that operations teams use every day is finally consolidated, and the mean time to resolve identity and access tickets drops measurably. The OIDC, multi-LDAP, and password policy changes mean that the identity story can finally align with enterprise policy without custom configuration.

For upgrade teams, the implication is that you should not defer the 9.1 upgrade indefinitely. The longer you stay on 9.0, the more you are deferring value that the new architecture and the Foundation Service are already delivering to organizations that have made the move. Plan the upgrade, sequence it carefully, validate it in non-prod, and commit to a production window. The 9.1 release has been Generally Available long enough that the early-adopter risk is well understood, and the operational risk is well within the range of any team that has done a major MAS upgrade before.

For security and identity teams, the new model is the integration point you have been waiting for. Plan the OIDC migration as a parallel workstream to the MAS upgrade. Validate the multi-LDAP synchronization in non-prod. Document the password policy that you intend to enforce. And engage with your identity provider team early, because the OIDC integration requires cooperation on both sides and is much smoother when both teams are ready at the same time.

Bottom Line

MAS 9.1 is a structural release, not a feature release. The multi-architecture support, the Foundation Service, and the new identity model are the changes that justify the upgrade on their own, independent of any of the individual feature additions. For most organizations, the right answer is to plan the 9.1 upgrade in the next two quarters, validate it carefully in non-prod, and use the upgrade as the catalyst for the broader identity and operations improvements that the new architecture enables. Teams that delay the upgrade beyond that window will be running an architecture that IBM is no longer investing in, and they will be carrying operational debt that the rest of the ecosystem has already retired.