On 30 September 2026, the twelve-month IBM Extended Support window for Maximo Asset Management 7.6.1.x closes. Regular base support for 7.6.1.3 was withdrawn a year earlier, on 30 September 2025, and the extended year that most 7.6.1 customers bought to keep production supportable is now roughly eight weeks from expiry. For a control engineer, a reliability manager or a Maximo platform owner still running 7.6.1.3 on WebSphere, the calendar has quietly become the meeting. The question is not whether to react; it is which of three narrow routes IBM has left open, and which one an operator can actually execute in the time remaining.
The route that is no longer open: silent drift
Running 7.6.1.3 into October 2026 without any IBM support wrapper is a supportability position that is difficult to defend in an audit. Cyber insurance renewals now ask an explicit question about unsupported enterprise applications, and IBM Announcement Letter 922-024 (published 12 April 2022) is the reference auditors quote. Once the Extended year expires, security patches and new defect fixes for the Maximo Manage tier stop, regardless of whether the WebSphere and database tiers underneath are still receiving vendor updates.
One prerequisite matters before either paid IBM route is available: the estate must be on fix pack 7.6.1.3. An estate still running 7.6.1.1 or 7.6.1.2 in October will not qualify, which forecloses two of the three routes below before the conversation starts.
Route one: buy Sustained Support and stay on 7.6.1.3
IBM’s Sustained Support offering is available for up to five years after standard support ended, which fixes the outer horizon for 7.6.1.x at 30 September 2030. The scope narrows sharply at the transition into it. Sustained Support covers how-to questions, usage issues, and known defects that already have a published fix. New defect fixes, new fix packs and new security patches sit outside the offering; whatever is in the fix catalogue on 1 October 2026 is what the estate runs on until it moves off 7.6.1.x.
That distinction matters at procurement time and at audit time. Sustained Support is the correct route where three conditions hold: the estate is stable, customisation is minimal enough that new defects are unlikely, and MAS migration is genuinely scheduled and funded on a plan that lands well before September 2030. It is the wrong route when it is chosen as a passive alternative to migration planning, because the risk profile after October 2026 is materially different from before it.
Two operating conditions are worth checking now if this is the route:
- The estate must be at 7.6.1.3, with sub-quarterly fix pack currency established and documented before the switch to Sustained.
- The Sustained Support contract must be aligned with the MAS migration plan, not treated as an independent five-year runway.
Route two: complete the MAS migration by 30 September 2026
For customers who started the MAS migration twelve to eighteen months ago and are close to production cutover, the deadline collapses into one test: can the technical, data and licensing workstreams all clear by end of September. The last twelve months of a MAS migration typically consume more effort than the first twelve, and the culprits are consistent.
The workstreams that most often extend into the window that operators wanted to keep clear:
- Automation Scripts, in Jython or JavaScript, need runtime validation against Maximo Manage on OpenShift. Automation Scripts have been available since Maximo 7.5 (2012), so a mature estate typically has dozens.
- Integration Framework artefacts (Object Structures, Publish Channels, Enterprise Services, Invocation Channels) need to be repointed and retested against MAS endpoints, and message-level parity is not a given.
- Classic UI screens that were configured in Application Designer need a decision on the Graphite UI: carry forward, rebuild or retire. Application Designer itself did not change, but the target rendering framework did.
- OpenShift cluster capacity, sized against the current 7.6.1.3 concurrent-user profile and the batch load profile from cron tasks, escalations and integration windows.
Estates with any of these still in flight in early August 2026 belong on a different route this quarter. Committing to a September cutover from that starting point is how programmes end up with a partial cutover in mid-October, an unsupported production system through November, and an IBM sales conversation about Sustained Support that was not in the budget.
Route three: third-party maintenance until MAS is ready
Third-party support providers offer a Maximo 7.6.1.x maintenance contract that steps into the space Sustained Support leaves open, typically at a lower headline cost and often with a broader scope on defect fixes than IBM Sustained provides. It is a genuine option for the operator who has decided that MAS is the destination but needs eighteen to thirty months of stable running to get there, and who is not comfortable relying on a defect fix backlog frozen at September 2026.
Three practical constraints to check before signing:
- The contract has to explicitly cover the Maximo Manage application tier, the WebSphere Application Server tier and the DB2 or Oracle database tier as one supported estate. A contract that covers only the Maximo Java stack leaves the middleware and database layers dependent on separate IBM or Oracle contracts.
- Any active IBM Passport Advantage entitlements need to be reviewed against the contract change, particularly where MAS AppPoints have already been acquired. Overlapping support contracts against the same production system usually indicate a licensing issue that should be resolved first.
- The scope for security advisory response has to be documented as an SLA, not as a best-effort clause. Under IBM Sustained, the answer to a newly published CVE is a matter of catalogue coverage; under third-party support, it is a matter of the provider’s engineering commitment.
Third-party support earns its place as a bridge to MAS. It underperforms as a permanent posture: MAS is where IBM investment is directed, and the third-party estate ages further with each passing quarter.
What stays hard
None of the three routes shortens a MAS migration that is genuinely two years of work. Data cleanup, criticality re-scoring, integration re-platforming and OpenShift operations discipline all take the time they take, and the deadline of 30 September 2026 does not compress them. The routes above are ways of buying that time under a supported footing, not ways of removing the underlying work. An operator who reads route one as a five-year holiday, or route three as a permanent alternative to migration, will be having a different, harder conversation in 2028.
Two adjacent items on the same lifecycle picture are also worth holding in view. MAS 8.10 and 8.11 were withdrawn from standard support on 30 April 2026, which reframes MAS as a moving target the migration has to aim at accurately (currently MAS 9.2, generally available since 25 June 2026). And the MAS dual support arrangement for customers running EAM 7.6.1.x alongside a MAS entitlement ends on 30 April 2027, which sets the outer edge of the parallel-running window regardless of which of the three routes above the operator picks.
The position to take into the meeting
For a 7.6.1.3 estate with a credible MAS programme already underway, route two is the target and the September date is the deadline the plan is measured against. For estates where MAS is on the roadmap but not funded to complete in 2026, route three is the defensible bridge, and it is easier to defend in front of a risk committee than a September scramble. Route one is the correct answer for a narrower group than the vendor conversations suggest, and it should be picked deliberately, contract-in-hand, with a MAS migration plan that lands well inside the Sustained window. Every route above is defensible; arriving at 1 October 2026 without having chosen one is not.
For teams working through the operational side of that migration decision, our note on why Maximo upgrades keep becoming re-implementations sits alongside this, and the managed Maximo hosting service is where the OpenShift operating discipline this route needs actually lives.