Open download
PDF version of this guide, no email gate, share freely.
A Maximo to MAS upgrade is not a patch. It is a programme. It is also an opportunity: the only time you get a clean look at a decade or more of accumulated decisions, and the only time replacing a bad decision is cheaper than keeping it.
This is the checklist we work through with our own clients. It is not exhaustive, but it is honest about what matters.
Who this is for, and what it is for
It is written for the person who has to put a date in front of a board: an IT lead, a programme manager, or a head of asset management who owns the outcome. Used properly, it is a working document. Take the seventeen items, put a named owner and a piece of evidence against each one, and you have the pre-flight pack that a serious supplier will ask for on day one. If you would rather see how the delivery side runs, that sits on our Maximo to MAS upgrade page.
Two jobs that get conflated
Almost every upgrade that overruns overran because two different pieces of work were funded, planned and governed as one.
An upgrade moves your existing business process onto MAS. The functional design is a given. Success is measured by the estate behaving the same way on the new platform, faster, with the customisation debt reduced. It is testable against a baseline that already exists.
A re-implementation changes the business process while the platform changes underneath it. New work-management model, new asset hierarchy, new failure taxonomy, new roles. That work can be worth doing, and sometimes it is overdue, but it needs its own budget line, its own sponsor from operations rather than IT, and its own timeline.
Name which one you are doing before the first workshop. The failure mode is not choosing the wrong one, it is discovering halfway through the test cycle that half the room assumed the other.
Before the upgrade
1. Audit customisations against current Maximo behaviour
Every customisation should be classified into one of four buckets:
- Now standard: Maximo has caught up and the customisation can be retired
- Now redundant: the business need has changed, so the customisation can be retired
- Still needed, replatform with configuration: preferred, because configuration survives upgrades
- Still needed, replatform with custom code: last resort, designed with future upgrades in mind
A typical estate finds 20% to 40% of customisations can be retired outright. That alone justifies the audit. Where Java customisations have to survive, the modernisation route to Automation Scripts is a separate piece of work with its own test cycle: see customisation modernisation.
2. Audit integrations
For each integration, document:
- Direction (in, out, both)
- Volume and pattern (real-time, batch, on-demand)
- Error-handling and reconciliation behaviour
- Owner on both sides
Plan to retest every integration through the upgrade, not just the ones you are ‘sure’ about. The pattern choice for each interface, publish channel, REST, or a broker, is worth revisiting at the same time: Maximo integrations covers how we decide.
3. Audit reports and dashboards
Reports are where customisation hides. List every report, identify the active ones (most are not), and decide which survive. The same applies to start-centre layouts, KPIs and BIRT artefacts.
4. Database health check
Database conversion (often from SQL Server to DB2, sometimes to Oracle) is part of many MAS upgrades. Before the upgrade, identify:
- Indexes that are no longer used
- Tables that have grown unboundedly because of missing housekeeping
- Custom database objects (triggers, views, stored procedures) that need to be migrated or retired
If a vendor change is in scope, treat it as its own controlled exercise rather than a step inside cutover: database vendor conversion.
5. Asset register and data quality
Asset hierarchy, classification, location structures and master data should be cleaned before, not after, the upgrade. The upgrade does not fix bad data. It just moves it to a new platform. Where records are coming in from another system at the same time, the load design matters more than the load tool: data migration into Maximo.
6. Mobile estate review
If you are on legacy Maximo Anywhere or a third-party mobile, plan the move to Maximo Mobile. The Mobile move is often more disruptive than the application upgrade, because it changes how the technician works rather than where the software runs. Our Maximo Mobile rollout practice and the rollout guide both start from the operating model rather than the device.
7. Hosting target decision
MAS deployment options include Red Hat OpenShift on cloud, IBM Cloud Pak, and various managed-service patterns. Make this decision early; the architecture and cost profile differ significantly. The trade-offs are worked through in MAS SaaS versus managed OpenShift, and the operated version of the answer is MaxIron Cloud.
8. Licensing and AppPoints assessment
MAS licensing is structured around AppPoints. Map your current Maximo footprint to MAS modules and AppPoints before signing. An authorised reseller partner can structure this alongside delivery. Start from MAS AppPoints and licensing, and take the workbook in the licensing guide to your software asset management owner before the quote is signed.
If the date you can realistically hold is later than the support position you are in today, that gap is what Maximo 7.6 Extended Support exists to cover. Deciding to bridge deliberately is a plan. Discovering the gap in month four is not.
During the upgrade
9. Trial upgrade in a non-production environment first
Always. We do this within the first week of programme start. It de-risks the production cutover by surfacing the unexpected before the cutover plan is locked.
10. Integration retest in upgrade order
Test each integration as soon as the application stack is stable enough, not at the end. Problems found late are problems found expensive.
11. Performance testing under realistic load
Performance changes in MAS are real, mostly for the better. Test with realistic concurrent-user load, realistic data volumes and the integrations turned on.
12. Cutover rehearsal
At least one full cutover rehearsal in non-production. Time everything. Identify the steps that always run long and either parallelise them or budget for them.
13. Communications plan for users
The visible UI changes will dominate user feedback even when the deep changes matter more. Plan training and communications around the parts users will see immediately.
After the upgrade
14. Hypercare with named engineers
Hypercare is not a generic ticket queue for the first month. It is named engineers on standby, daily standups, and an explicit triage process for issues caught after go-live. Our own model assigns the same architects who designed the upgrade to hypercare.
15. Post-go-live performance review
Two weeks after cutover, review actual performance against the baseline and against expected gains. This is where you discover whether the upgrade delivered what it promised.
16. Lessons learned, captured in Maximo
Capture lessons in the Maximo system itself (against the work order or the change record), not in a project office that disbands. The next upgrade will thank you.
17. Plan the next thing now, not later
Most MAS estates that succeed long-term plan a Mobile rollout, a Health / Monitor / Predict layered deployment, or an additional business unit within twelve months of the upgrade. Putting that on the roadmap immediately keeps momentum and protects the investment in the upgrade itself.
What stays hard
An upgrade programme removes a specific set of problems. It does not remove all of them, and a supplier who says otherwise is selling.
- Decisions still take as long as your governance takes. A change advisory board that meets fortnightly sets the pace of cutover, whoever is doing the engineering.
- Data quality is still your data. Automation finds duplicates, blanks and orphan records quickly. Deciding which of two asset records is the real one is a judgement call your engineers have to make.
- Customisation you insist on keeping stays a liability. It can be replatformed cleanly, and we will do that. It will still need regression testing at every future release.
- Integration partners move at their own speed. If the SAP or GIS team cannot retest in your window, that constraint belongs in the plan on day one rather than in the risk log at week ten.
- User habit is slower than software. The screens change on cutover weekend. The way a supervisor actually plans work changes over a quarter, and only if somebody owns that change.
Where the effort actually moves
The useful way to think about the payoff is not “faster”. It is that a category of work disappears while another category stays exactly where it was.
Unchanged: the functional decisions, the data judgement calls, the integration retests, the training, and the governance cycle around all of it.
Removed, once the estate is on MAS and operated properly: the version-specific workaround nobody documented, the manual patching window, the fear of the next release, and the annual argument about whether the platform can carry another business unit. Continuous delivery replaces the every-few-years re-platforming event, which is the change most boards have not yet planned for.
Bring three things to the first conversation
We do this for a living. We commit to fixed-price upgrade quotes within 24 hours of analysis and to trial upgrades within a week. We have upgraded estates from every Maximo version from 5.x onwards.
The conversation is short if you bring three artefacts: your current version and database, the list of integrations even if it is out of date, and the date somebody has already promised internally. We will map where risk sits on your estate, and where this checklist does not apply.
Book a 30-minute review, or read how we run the programme on the Maximo to MAS upgrade page.
Where this guide leads
The pages below are the delivery side of the decision this guide covers.