MAS 9.2 Readiness: OpenShift 4.19, MongoDB 8.0, OAuth2, and the Kasten Backup Blueprint That Actually Works

If you are running MAS 9.0 or 9.1 today, MAS 9.2 is not a drop-in upgrade. It is a coordinated platform shift: OpenShift moves to 4.19, MongoDB to 8.0, the authentication stack gets a real OAuth2 surface, and the operator catalog gains new architecture options. Each of these is an upgrade of its own. Together they form a single decision about how the platform is run, and the right time to think about that decision is now — not the week you decide to cut over.

This article walks through the four changes that matter most for MAS 9.2 readiness, and the practical patterns that the most experienced platform teams are using to prepare.

The four changes that matter

1. OpenShift 4.19 (Kubernetes 1.32) becomes the supported target

MAS 9.2 introduces official support for OpenShift Container Platform 4.19, which ships Kubernetes 1.32. The practical reality is that MAS has run on a narrow band of OpenShift versions for years (4.14, 4.16, 4.17), and 4.19 is the version IBM is committing to for the 9.2 line.

If you are on OpenShift on IBM Cloud (ROKS), the version timeline matters:

A few things to notice. First, 4.16 and 4.17 both go out of support in 2026 — 4.16 in August, 4.17 in October. If you are still on either, MAS 9.2 will not run there. Second, 4.19 is a "stable middle" — it has nearly a year of support runway left, but the train is moving. Third, the IBM Cloud VPC default at the time of writing is 4.20, and the long-term recommendation is to follow the IBM Cloud default rather than pinning a specific OCP version.

For customer-managed (on-prem) OpenShift, the rule is the same: get to 4.19 before you start the MAS 9.2 upgrade. Do not try to upgrade MAS and OpenShift in the same change window.

2. MongoDB 8.0 for the core catalog and suite databases

MAS 9.2 moves the MongoDB dependency for the core catalog and MAS Core databases to 8.0. This is more consequential than the typical "point release" bump because the Mongo 8.0 storage engine has changed and the operator-managed MongoCE has been reworked.

The practical impact is on three things:

• mongodump and restore behavior. Mongo 8.0's wire format and storage compression are different. Older mongodump binaries (especially the ones pre-bundled in older Kasten or operator images) cannot read 8.0 dumps. Test your backup chain against 8.0 before the upgrade.
• Storage sizing. 8.0's compression is more efficient for typical MAS metadata, but the new engine allocates working set memory differently. The MAS sizing calculator is the starting point, but expect a 10–15% reduction in storage footprint for the same logical dataset and a small increase in working memory pressure on the Mongo pods.
• Compatibility with managed Mongo offerings. If you are using MongoDB Atlas or IBM Cloud Databases for MongoDB as an external store, confirm the version you are on supports 8.0 and that the MAS operator's external Mongo configuration is compatible. The operator's external Mongo support matrix is the source of truth here, not the MongoDB documentation.

The single most common MAS 9.2 upgrade failure during early trials has been Mongo 8.0 compatibility. Get the Mongo version right first; everything else follows.

3. Native OAuth2 / OIDC support for Manage

MAS 9.2 lands real OAuth 2.0 / OIDC as a first-class authentication option in Manage, alongside the existing SAML 2.0 and LDAP options. The framing is "OAuth 2.1 conformance" — the implicit grant and the resource-owner password credentials grant are gone, PKCE is mandatory, redirect URIs must match exactly, and refresh tokens rotate.

In practice this means three things for a typical Maximo customer:

1. You can finally retire the SAML 2.0 SP if you want to. Many customers have been running SAML because that was the only modern option. OAuth2/OIDC works with Azure Entra ID, Okta, Auth0, Keycloak, IBM Security Verify, and any OIDC-compliant IdP. The integration is via standard discovery (/.well-known/openid-configuration).
2. The Maximo Mobile login path changes. The Mobile client uses an OIDC flow against the IdP, then exchanges the token for a Maximo session. The Maximo Operator and Mobile client need to be configured to trust the IdP's issuer and JWKS endpoint.
3. eSignature works. E-signature approvals, which previously required SAML 2.0, now work with OIDC as long as the IdP honors the forceAuthn flag in the OIDC request.

The auth change is the one your security and identity teams will care about most. Get the IdP's OIDC discovery URL, the client ID, and the redirect URIs registered before the upgrade. Do not let it become a cutover-day surprise.

4. New operator catalog architectures

The Maximo Operator Catalog has been reworked to support new architecture options, including:

• z/Architecture and ppc64le support is more clearly delineated in 9.2, which matters for IBM Z (LinuxONE) and Power customers running MAS.
• The "all-included" option is now a documented pattern: run every database (MongoCE, DB2U, the optional external Postgres for Industry Solutions) inside OpenShift on OpenShift Data Foundation (ODF) or any CSI-capable storage class, for a fully self-contained platform.
• OpenShift Pipelines (Tekton) drives more of the day-2 workflow. Deployment, upgrade, and configuration migration are operator-managed, with Tekton handling the long-running pipeline steps. This is the most underappreciated change in 9.2 — the upgrade process is more predictable and recoverable than it was in 9.1.

The backup blueprint that works on 9.2

The most mature pattern for MAS 9.2 backup and DR — the one that has been validated on production 9.1 deployments and ported cleanly to 9.2 — uses Veeam Kasten to protect three layers:

1. MAS Core (the mas-<instance>-core namespace and its supporting namespaces: cert-manager, ibm-sls, grafana).
2. MongoCE (the mongoce namespace) — protected via mongodump into a backup PVC that Kasten then snapshots.
3. Manage (the mas-<instance>-manage namespace and the db2u namespace) — including the Manage workspace state, encryption keys, and the DB2U application database.

The blueprint's key insight is that the suite-level Custom Resources are the source of truth, and the derived resources can be regenerated. Restore order matters:

1. Restore the Suite, ManageWorkspace, ManageDeployment, and ManageBuild Custom Resources first.
2. Scale all deployments to zero replicas.
3. Restore the rest of the resources with overwrite existing, excluding pods and CertificateRequest.
4. Let the operator rebuild the derived resources from the restored CRs.

The result: MAS Core is back online in about 7 minutes for in-place restores, instead of the 2.5 hours it takes to rebuild from scratch.

For full DR (different cluster, different site), the same blueprint applies but with a different rule of thumb: reinstall MAS on the destination cluster first, then restore the data layer. Specifically:

• Do not restore cluster-specific namespaces like cert-manager — the operator will reissue a fresh, internally consistent CA on the new cluster. Restoring the old CA keypairs creates a tangle of old and new trust anchors.
• Set autoGenerateEncryptionKeys: false on the Manage deployment so the operator does not overwrite the encryption key you are about to restore.
• Restore MongoCE first, then the Manage database, then the Manage workspace state.
• Watch the ManageWorkspace reconcile to Ready. When it does, you are back in business.

Typical full DR with this blueprint: 3 to 7 hours end to end, depending on data volume and network throughput.

The readiness checklist that holds up

The platform teams that get MAS 9.2 right run a checklist that looks like this:

1. Get OpenShift to 4.19 first. Separate change window. Validate workloads, storage classes, and ingress.
2. Validate the Mongo 8.0 backup chain. Run a mongodump from a test Mongo 8.0 instance and restore it into a clean target. Confirm the dump binary is 8.0-compatible.
3. Register the OIDC client in the IdP. Get the discovery URL, the JWKS URL, the redirect URIs, and the client ID/secret into the Maximo Operator's auth configuration before the upgrade.
4. Update the Kasten policies. Confirm the namespaces, the include/exclude lists, and the encryption key handling for the new MongoCE and DB2U layout.
5. Run a non-prod MAS 9.2 activation. Clone the production database, run the upgrade activation in non-prod, document every error, fix it, repeat. Only then repeat in production.
6. Cut over on a planned window with rollback path. If in-place restore via Kasten is the rollback path, make sure the most recent consistent backup is less than 24 hours old.

MAS 9.2 is the right time to modernize the platform underneath Maximo. The reward for doing the prep work is a clean, repeatable upgrade. The cost of skipping it is a six-month incident.