MAS upgrade
The customisation register sets your route to MAS.
Three routes lead from legacy Maximo to IBM Maximo Application Suite, and the register decides which one your estate is on. We count it from a restored copy of production in week one, put the blocked rules in front of the people who own them, and price the route the evidence puts you on.
Three routes onto MAS
Pick the route the register supports
Route one is the route most estates take by default, and on an estate carrying a decade of custom code it is the expensive one. Every generation from Maximo 5.x through 7.6.x is upgradeable; the version gap sets the method and the register sets the bill.
Carry the estate forward as it stands
How configuration keeps the register short →You are on it if
Fewer than about forty custom items, every interface has a named owner, and no two sites are arguing about how a job is recorded.
The wrong move here
Pricing the route from the register your team keeps rather than from a count taken against a restored database. The count is almost always the larger number.
Re-decide the register, then upgrade
See customisation modernisation →You are on it if
Over a hundred custom items, several written before 2016, and two or three that nobody currently in the building can explain.
The wrong move here
Revalidating and retesting items you were going to retire. Retirement is the one decision that lowers the bill at the upgrade after this one as well as at this one.
Re-implement, with the platform move inside it
See implementation programmes →You are on it if
Two depots record the same fault differently, both defend it, and the reporting your executive team asks for cannot be produced from the mixture.
The wrong move here
Writing it into the business case as an upgrade. An upgrade needs administrators for days. This needs process owners for months, and the gap surfaces in month four.
What each route asks of you
One route at a time, with the three facts that move between them
Every item travels, and every item is revalidated on MAS
The fastest route to scope and the cheapest to sign. The register you arrive with is the register you keep, and you pay to revalidate it again at the next upgrade.
- Who you release
- Maximo administrator and interface owners, days at defined points
- What testing proves
- Regression: what worked still works, on the same data, plus every interface end to end
- What sets the price
- Item count, interface count, data volume and test rigour, all countable before you commit
One verdict per item before anything is rebuilt
Each custom item is carried, moved to configuration, rewritten as an Automation Script, or retired. The verdict is taken by the person accountable for the rule and recorded with their name and the date.
- Who you release
- The approval policy owner and the role behind each rule, alongside administrators
- What testing proves
- Regression on what travels, plus evidence that a retired item has no live consumer
- What sets the price
- How many items reach a decision before the run, rather than how many items exist
The operating model is decided again, then configured on MAS
How work is planned, recorded and reported is settled first. MaxIron facilitates the decisions, brings the options and the consequences, and writes them down. Your organisation takes them, because they commit your operation.
- Who you release
- Process owners across maintenance, stores, procurement and finance, for months
- What testing proves
- Acceptance: a process nobody has run before, on data nobody has used in that shape
- What sets the price
- Open process decisions, data readiness, and how many people need retraining
Trial upgrade week
Five days that settle which route you are on
Production is read from and never written to. The week ends with a register, measured timings and an environment your people can sign into.
- 01
Count the register from the database
Last night's production database is restored into an isolated environment. The scan counts automation scripts, Java extensions, Application Designer screens, BIRT reports, object structures, publish channels and cron tasks.
Owner MaxIron upgrade lead with your Maximo administrator Typically Monday
- 02
Run the upgrade and record what stops it
The run rarely completes first time, and the causes are age rather than architecture: a 2013 Java extension, a script written against a field length somebody later widened, a report naming a renamed table.
Owner MaxIron platform engineer Typically Tuesday
- 03
Put the blocked rules in front of their owner
A workflow customisation forcing a second approval above a value threshold raised two years ago, for a role that no longer exists. Carry, re-decide or retire, decided by the approval policy owner and written on the register row.
Owner Your approval policy owner Typically Wednesday
- 04
Retest interfaces and time the heavy steps
Interfaces run against test endpoints where they exist and stubs where they do not. Work order history, meter readings and the attachment store are timed on your volumes, which is how the cutover window gets a number.
Owner Your interface owners with MaxIron Typically Thursday
- 05
Hand over the pack and the environment
Register with owner, decision and effort class per row. Interface retest results with named external dependencies. Measured timings. A written list of what is still unknown. All of it is yours whether or not you proceed with us.
Owner Your programme sponsor Typically Friday
Delivered
Three numbers from upgrades MaxIron has run
- 7 months
- Maximo 7.6 to MAS 9.0.1, UK ferry operator
- 5 days
- Restore to signed pack, trial week
- 5.x to 7.6.x
- Maximo generations upgraded
Against a hard regulatory deadline, including a Microsoft SQL Server to IBM DB2 conversion on Red Hat OpenShift. Read the case study.
The standard shape. Longer where the attachment store or the interface count demands it.
Every generation of legacy Maximo currently in the field, on estates MaxIron manages today.
The decision boundary
Who decides what, and where the decision is written
Three kinds of decision run through an upgrade. The method, the sequence and the technical execution are ours. Whether a rule still applies belongs to the role accountable for that rule. Whether the operation can give up a Saturday night belongs to the business.
The Wednesday session in the trial week exists so the second kind is taken while the environment can still be thrown away.
Every customisation decision lands on one register row: the item, the verdict, the owner who took the call, and the date. Deferred items are marked as deferred rather than quietly carried, because a default carried forward is the most expensive line in the programme and the hardest to find afterwards.
On a long-running estate the register is the largest single input to the fixed price.
The cutover window is calculated from timings measured on your own data volumes rather than from a comparable client. Where the three heaviest steps take eleven hours, a four-hour Saturday window is a finding, and week one is a cheaper place to find it than the night itself.
Work order history, meter readings and the attachment store are the three steps that usually set the length.
Boundaries
Three boundaries on an upgrade programme
Each is cheaper to settle in scoping than in a steering committee.
The price follows the trial upgrade
We quote a fixed price against measured scope, with anything still resting on judgement labelled as such. A number produced before the audit and the trial run is a negotiating position rather than a programme cost.
Data quality carries its own budget
A duplicated asset hierarchy moved to MAS is the same duplication on a current platform. Cleansing, classification and failure coding sit under data migration, where they hold their own budget instead of being absorbed into an upgrade price and quietly cut.
Counterpart availability sets the schedule
Interface retest needs the ERP, finance and GIS teams. The Wednesday decision needs the approval policy owner. Training needs supervisors off the floor. We plan around real availability and name each one in the risk log.
Usually in scope alongside
Capabilities a MAS upgrade draws on
Maximo to MAS upgrade, frequently asked questions
- What is the difference between legacy IBM Maximo and Maximo Application Suite (MAS)?
- Legacy Maximo usually means a long-running deployment built around Maximo 7.x patterns and older middleware. IBM Maximo Application Suite is the current modular suite: Manage, Monitor, Predict, Health, Visual Inspection and related applications, on Red Hat OpenShift and under AppPoints licensing. Moving to it is a programme of upgrade, integration retest and often cloud relocation.
- Can you upgrade from Maximo 7.6 to MAS on a fixed price?
- Yes, once the trial week has measured the scope. We quote a fixed price against the register, the interface list and the timings that week produces, with anything still resting on judgement labelled as such. Scope changes run through change control.
- Does the trial upgrade touch production?
- No. It runs on a restore of your production database inside an isolated environment. Interfaces point at stubs or test endpoints, so no message reaches finance, ERP, GIS or the field, and nothing is written back to the live estate.
- What normally stops the first run?
- The bespoke edges, and almost always because of their age: an extension written against the patterns of a decade ago, a report with a hard-coded schema reference, an interface using an authentication mechanism your own security team has since retired. Standard configuration generally carries forward.
- Do we have to adopt the other MAS applications when we upgrade?
- No. Maximo Manage is the core asset and work management application and it is what an upgrade from classic Maximo moves you onto. Health, Monitor, Predict, Assist and Visual Inspection are separately licensed, each with its own data prerequisites and its own business case. See MAS AppPoints and licensing for how that is structured commercially.
- Do you handle cloud migration and database conversion inside the upgrade?
- Yes. Most clients use the upgrade to move to managed cloud, and a Microsoft SQL Server, IBM DB2 or Oracle move is sequenced inside the same programme so only one variable changes at a time. See database vendor conversion and managed Maximo hosting.
Bring the customisation nobody can explain.
Send what you have. We will say what a trial week on your estate would look like, which items we expect to stop the first run, and who from your side needs to be in the room on Wednesday.
Bring this to the first call
- Your Maximo or MAS version, database platform and rough database size
- Whatever customisation register exists, however incomplete, plus the two items nobody can explain
- The list of interfaces, and which counterpart teams own a test environment
- The cutover window your operation can give up, in hours, and on which day
- The name of the person who can approve a change to a work order lifecycle or an approval rule