Why Upgrading to IBM Maximo Application Suite Is No Longer Optional
IBM is sunsetting classic Maximo support. Here's what that means for organisations still running 7.6.x and earlier, and what the migration actually involves.
If your organisation runs IBM Maximo 7.6.x or earlier, the support window is closing. IBM has been progressively shifting investment away from the classic Maximo platform toward the Maximo Application Suite (MAS) — and the timelines are no longer comfortable.
This is worth understanding clearly, because the decision to upgrade (or not) carries real operational and financial consequences.
What MAS Actually Is
MAS is IBM’s next-generation asset management platform, built on Red Hat OpenShift. It consolidates Manage (the traditional Maximo), Monitor, Health, Predict, Visual Inspection, and Assist into a single suite under one entitlement model.
The architectural shift is significant:
- Containerised deployment — Kubernetes-based, designed for horizontal scaling and infrastructure portability
- Unified licensing — one subscription covers multiple capabilities that were previously licensed separately
- AI and IoT integration — Predict and Health use machine learning models for condition-based maintenance; Monitor handles real-time sensor ingestion
- Modern UI — Carbon Design System replaces the legacy JSP interface, with responsive layouts and improved accessibility
This isn’t a cosmetic refresh. The underlying platform is fundamentally different — different runtime, different deployment model, different operational requirements.
Why Most Organisations Delay
The upgrade stalls for predictable reasons, and they’re worth naming directly:
Scope uncertainty. Most Maximo implementations carry years of customisation — automation scripts, custom MBOs, screen modifications, integration endpoints. Until someone analyses that estate against MAS compatibility, the scope is genuinely unknown. Organisations delay because they can’t size the effort, and they can’t size the effort without doing the analysis.
Infrastructure complexity. MAS runs on OpenShift. For organisations that have never operated a Kubernetes platform, this introduces a new operational domain — container orchestration, namespace management, persistent storage, ingress configuration. Enterprise procurement for this infrastructure can take months.
Risk aversion. A failed Maximo migration isn’t a minor incident. It’s work orders not being raised, maintenance not being scheduled, compliance data going dark. The stakes are high enough that “wait and see” feels rational, even when it isn’t.
These are legitimate concerns. They’re also solvable — but only if addressed explicitly rather than ignored.
What the Migration Actually Involves
A realistic MAS migration has several distinct phases:
1. Configuration analysis. Every customisation in the existing Maximo instance needs to be catalogued and assessed for MAS compatibility. Automation scripts, custom Java classes, screen modifications, cron tasks, escalations, integration endpoints — all of it. Some will carry forward directly. Some will require rework. Some can be eliminated entirely because MAS handles the requirement natively.
2. Environment provisioning. MAS requires an OpenShift cluster with specific operator configurations (IBM Maximo Operator, MongoDB, Kafka, etc.). The provisioning approach — whether on-premises, cloud-managed, or hosted — determines timeline and operational overhead.
3. Data migration. Schema differences between classic Maximo and MAS Manage are relatively contained, but data integrity validation is critical. Lookup tables, classification hierarchies, GL account mappings, and workflow configurations all need verification.
4. Trial upgrade. Running the upgrade against a copy of production data in an isolated environment. This is where compatibility issues surface — and where they should be resolved, not in production.
5. Integration re-establishment. External systems that communicate with Maximo via integration framework, REST APIs, or direct database connections need to be reconnected and validated against the new environment.
6. User acceptance and cutover. Training on the new UI, validating business processes, and executing the production switchover with a documented rollback plan.
The Support Timeline Problem
IBM’s support lifecycle for classic Maximo is well-documented. Extended support for Maximo 7.6.1.x carries premium pricing and reduced SLA commitments. Critical security patches may continue, but feature development has stopped entirely. The engineering investment is in MAS.
Organisations that delay the upgrade aren’t just missing new features — they’re accumulating technical debt on a platform with a shrinking support footprint. Every month that passes makes the eventual migration more complex, because:
- Custom code continues to grow on the legacy platform
- Staff familiarity with classic Maximo increases while MAS skills remain absent
- Integration dependencies multiply
- The gap between current-state and target-state widens
What to Evaluate Now
Regardless of when the migration happens, three things should start immediately:
Run a configuration audit. Catalogue every customisation, integration, and non-standard configuration in the current environment. This is the single most valuable input to any upgrade decision, and it costs nothing to begin.
Assess OpenShift readiness. Determine whether the organisation will operate its own OpenShift cluster, use a managed service, or outsource the hosting entirely. This decision shapes the migration timeline and ongoing operational model.
Identify the MAS applications that matter. Not every organisation needs Predict, Health, and Visual Inspection on day one. A phased adoption — starting with Manage and expanding into AI-driven capabilities — reduces risk and allows the organisation to absorb the change incrementally.
The upgrade to MAS is not a question of if. The remaining question is whether it happens on the organisation’s terms — planned, validated, and controlled — or as an emergency response when legacy support runs out.