Start Here: MAS Platform & Upgrades

What is the first thing to understand about MAS?

Maximo Application Suite is not simply the next installer for the Maximo product people have run for years. It is a suite operating model built around Red Hat OpenShift, containerized services, shared identity, entitlement management, and multiple applications that can be adopted at different speeds. That difference changes the upgrade conversation. A Maximo 7.6 team often thinks in terms of application servers, EAR files, database changes, and downtime windows. A MAS team has to think about cluster operations, operators, storage classes, ingress, certificates, identity providers, backups, monitoring, and support boundaries before the first business user sees a work order.

The practical implication is simple: the platform track must lead the application track. Manage configuration testing still matters, but it cannot compensate for unresolved platform ownership. If nobody owns OpenShift upgrades, logging, certificate renewal, backup validation, and identity incidents, the application team inherits problems it cannot fix quickly.

Summary: MAS planning should start with operational ownership: who runs the platform, who validates Maximo behavior, who approves business cutover, and who responds when an integration fails at 2 a.m.

How should teams approach OpenShift readiness?

OpenShift readiness is less about passing an installation checklist and more about proving that the target environment can be operated after go-live. Confirm cluster sizing, storage performance, image registry access, ingress design, DNS, certificates, monitoring, backup and restore, and patch windows. The Maximo team should not accept a cluster as ready until it has seen evidence of restore testing, log access, alert routing, and support escalation.

A useful readiness review asks these questions:

• Which team owns cluster upgrades and operator lifecycle management?
• What storage classes are approved for MAS workloads and backups?
• How are certificates renewed and who is paged if renewal fails?
• Where do application logs go, and how long are they retained?
• What is the restore target for the database, persistent volumes, and configuration?

Where do Cloud Pak and MAS architecture fit?

Cloud Pak packaging gives MAS a consistent enterprise deployment foundation, but it does not remove architecture work. Identity, network segmentation, environment strategy, namespace governance, secrets management, and integration zones still need design decisions. Teams should document the target environment pattern for development, test, staging, and production. They should also define what belongs in MAS, what remains external, and what must be integrated through supported APIs.

| Decision | Why it matters | Evidence to collect | | --- | --- | --- | | Environment count | Controls release rehearsal quality | Named dev, test, staging, prod roles | | Identity provider | Shapes access, SSO, and support | OIDC/SAML design and test users | | Integration routing | Affects reliability and security | API gateway, firewall, retry plan | | Backup ownership | Determines recovery confidence | Restore test results and RTO/RPO |

How should AppPoints affect the plan?

AppPoints are not just a procurement topic. They influence role design, adoption sequencing, and executive expectations. Before a team enables every application for every user, it should map personas to actual tasks. A planner may need Manage and dashboard access. A field technician may need mobile work execution. A reliability engineer may need Health, Monitor, or Predict. A casual requester may need a much lighter path.

Modeling this early prevents two common mistakes: underestimating entitlement needs for a pilot that becomes popular, and over-licensing users who only need a narrow workflow. The best AppPoints workshops include application owners, security administrators, procurement, and finance, because entitlement decisions quickly become operating-model decisions.

What migration strategy works from Maximo 7.6?

A strong migration strategy starts with an inventory, then separates business value from technical baggage. List custom Java, automation scripts, escalations, workflows, reports, object structures, cron tasks, integrations, security groups, domains, database configuration, and mobile dependencies. For each item, decide whether to retire, replace, remediate, or migrate.

Do not use migration as an excuse to recreate every old behavior. Preserve the processes that protect safety, compliance, uptime, and financial control. Challenge the customizations that only exist because of an old UI limitation or a past reporting habit. The upgrade is a chance to reduce future maintenance cost, but only if the team makes explicit choices.

What should the first 90 days include?

1. Build a platform readiness scorecard with named owners.
2. Complete the customization and integration inventory.
3. Model AppPoints by persona and expected adoption.
4. Run a non-production migration rehearsal with defect triage.
5. Pilot one high-value workflow before expanding suite scope.

The teams that succeed with MAS are not the teams that rush to the most applications. They are the teams that make the platform boring, the migration evidence visible, and the adoption sequence understandable to both technicians and executives.