"Can Maximo do this?" almost always gets a yes. That is the problem. Maximo is deep enough that nearly any request can be satisfied, so the real question is never "can we" but "at what level should we, and what does that cost us at the next upgrade?" Over 22 years I have watched teams answer the first question and ignore the second, then spend a fortune untangling the result. This is the framework I use to draw the line before the work starts.
The four-level ladder
Think of every change as landing on one of four rungs. The higher you climb, the more the platform stops protecting you and the more you own forever. If you are new to the platform, my introduction to IBM Maximo sets the context for what follows.
Level 1: Configuration.
The Application Designer and Database Configuration. New attributes, screen layout changes, domains, table extensions, conditional UI. This is the platform behaving exactly as IBM built it to behave. Upgrade cost is near zero because the metadata carries forward. Full IBM support. This is home base, and most requests belong here.
Level 2: Low-code.
Automation scripts and workflow. You write logic, but inside the sanctioned scripting engine and the delivered workflow designer. Upgrade cost is low and predictable: scripts survive upgrades, though APIs they call can shift, so they need a retest pass. Support is shared. IBM supports the engine; your logic is yours to defend. A large share of "Maximo cannot do that out of the box" requests actually live here.
Level 3: Extension.
Custom Java classes and bespoke object structures that reach past the scripting sandbox into the business object layer. Real developer territory, source control, a build pipeline. Upgrade cost is material: custom classes can bind to internal methods that IBM is free to change without notice, so every major upgrade means recompilation and regression. Support is on you for anything you wrote.
Level 4: Modification.
Editing delivered code, overriding shipped classes, patching stock JSPs or the base schema. This voids the safety net. IBM support can decline a ticket the moment they see altered core. Upgrade cost is the worst kind, invisible until an upgrade silently overwrites your change or breaks on it. On a modern deployment, especially IBM Maximo Application Suite , this should be treated as almost never acceptable.
The one line that decides everything
Every rung you climb, the platform stops carrying the change and you start. Level 1 is IBM's problem at upgrade. Level 4 is entirely yours, forever. Pick the lowest rung that actually satisfies the requirement, not the one that feels most elegant to build.
What each rung costs you later
The table below is the version I keep in front of me. The columns that matter are not "can it be done" but upgrade cost and who owns support when something breaks at 2am.
| Level | Built with | Upgrade cost | Support |
|---|---|---|---|
| 1 Configuration | App Designer, Database Config | Near zero | Full IBM |
| 2 Low-code | Automation scripts, workflow | Low, retest scripts | Shared |
| 3 Extension | Java classes, custom object structures | Material, recompile and regress | You own your code |
| 4 Modification | Edited delivered code | Severe, often invisible | Support at risk |
Applying the ladder to real requests
Frameworks are cheap until you test them against real tickets. Here are twelve requests I have genuinely received, mapped to the rung each should land on. Two of them I would refuse outright, and the argument for refusing is in the table.
| Request | Level | Why |
|---|---|---|
| Add a "warranty expiry" field to Assets | 1 | New attribute in Database Config, nothing more. |
| Make that field mandatory on a status change | 1 | Conditional data attribute, no code. |
| Validate a serial number format | 2 | Attribute automation script, a few lines. |
| Auto-populate a cost centre from the asset | 2 | Object launch script, delivered pattern. |
| Two-step PO approval by amount | 2 | Standard workflow designer, no build. |
| Email a vendor when a warranty claim opens | 2 | Workflow plus communication template. |
| Nightly sync of meter reads from SCADA | 3 | Integration and object structure, real dev work. |
| Custom depreciation calc across asset classes | 3 | Java class, beyond safe scripting scope. |
| Reskin the Work Order app to match intranet | 1 | App Designer and CSS, resist going deeper. |
| Bespoke multi-branch approval engine | 3 | Object structures plus scripts; justify hard before building. |
| Rewrite the delivered PM generation logic | Refuse | Modifying core. Re-express the actual need as PM options and a script instead. |
| Patch a stock JSP to hide a "standard" button | Refuse | Level 4 for a Level 1 outcome. Security groups or App Designer do this cleanly. |
The two refusals share a pattern: both reach for the top of the ladder to solve something the bottom of the ladder already handles. That is the single most common failure I see, a Level 4 build shipped for a Level 1 requirement, because the person who scoped it did not know the lower rung existed.
Governance that makes the discipline stick
A ladder in a slide deck changes nothing. Three lightweight artefacts turn it into a habit that survives staff turnover and vendor pressure.
1. A change register.
One row per customisation, recording the level, the business justification, the named owner, and the upgrade risk in plain words. This is the single most valuable document in a mature Maximo estate. Without it, nobody at the next upgrade knows why a class exists or whether it can be deleted, so everything gets retested defensively. The same discipline pays off for adjacent records like contracts and warranties, where undocumented logic quietly changes financial behaviour.
2. A naming standard.
A fixed prefix for every custom object and attribute, for example an org-specific tag on tables, columns, scripts and classes. It sounds trivial. It is the difference between an upgrade impact analysis that takes an afternoon and one that takes a week, because you can filter custom from delivered in one query instead of guessing.
3. A rejected-alternative rule.
Anything above Level 2 requires a documented rejected alternative. Before you approve a Java class, someone writes down the configuration or script approach that was considered and why it genuinely could not meet the need. This one rule kills most unnecessary Level 3 and 4 work on its own, because the act of writing "we could not use a script because..." usually reveals that you could.
The trap that catches everyone
Customisations are cheap to add and expensive to remove. Each one looks small and justified in isolation. The cost is never the build, it is the compound interest paid at every upgrade for the rest of the system's life. Governance is not bureaucracy here, it is the only thing standing between you and a platform you cannot afford to upgrade.
The compound cost of drift
A client came to me facing a major version upgrade with 140 customisations accumulated over eight years. No register, no naming standard, mixed across all four levels. Here is roughly how the retest burden broke down.
The 90-odd Level 1 and 2 items were mostly safe, but "mostly" still means testing, because a configuration can depend on a script that depends on a workflow. Call it a light pass. The 35 Level 3 extensions each needed recompilation against the new libraries, code review, and a full regression of the process they touched. At a conservative half a day of analysis, fix and test per class, that alone is roughly 18 person-days. The 15 Level 4 modifications were the real damage: each had to be reverse-engineered to work out what stock behaviour it changed, then re-expressed at a lower level or abandoned, because IBM would not support the upgrade otherwise. Several took days apiece.
The total retest and remediation ran past 60 person-days before a single new feature was delivered. On a clean estate of the same size, governed to Levels 1 and 2 with a register and naming standard, the equivalent effort would have been a fraction of that, days rather than months. That gap is the price of skipping governance, paid in full, with interest, exactly when you can least afford the delay.
Pushing back without saying no
The hardest part of this framework is not technical, it is the conversation with a stakeholder who wants their exact request built their exact way. "No" makes you the obstacle. Reframing makes you the guide. Here is the script I actually use.
- Separate the outcome from the mechanism. "Help me understand the business outcome you need, not the screen you pictured. If we nail the outcome, I can usually reach it more cheaply than you expect."
- Name the real cost honestly. "I can build exactly that, and it lands at Level 3. That means every future upgrade carries a recompile and a regression test on this. Are you signing up to own that cost each year?"
- Offer the lower rung as the default. "There is a configuration route that gets you 90 percent of this with near-zero upgrade cost. Let me show you that first, and we only climb the ladder if it genuinely falls short."
- Make the register the referee. "If we do go higher, I need a rejected alternative on record. Not to slow you down, but so the person doing the upgrade in three years knows this was a deliberate choice, not an accident."
Nine times out of ten the outcome is reachable a rung or two lower than the original request. The tenth time, the customisation is genuinely justified, and now it is documented, owned, and defensible. Either way you never actually said no. You moved the conversation from mechanism to cost, and cost decides for you.
A note on independence
I do not sell Maximo licences and I am not paid by IBM. The framework above is what I would apply on my own budget. Always confirm current behaviour against the official IBM Maximo Manage documentation , because supported patterns shift between releases.
Conclusion
Configuration versus customisation is not a binary, it is a ladder, and the discipline is choosing the lowest rung that meets the need. Level 1 and 2 should cover most of your requests. Level 3 needs a documented reason. Level 4 needs a very good one, and usually the answer is that there is a better way. Back the ladder with a change register, a naming standard, and a rejected-alternative rule, and you keep a platform you can still afford to upgrade in five years. Skip them, and you inherit the 140-customisation problem, one small, reasonable-looking decision at a time.
Written by Muhammad Abbas
CMMS / CAFM Manager & Enterprise Integration Specialist · 22+ years across ERP, EAM, CAFM and enterprise integration.
Work with me