MAS upgrade
A tested transition from IBM Maximo to MAS.
MaxIron assesses the existing IBM Maximo estate, agrees which configuration and customisations carry forward, then rehearses the move to IBM Maximo Application Suite. The programme includes measured cutover planning, interface retesting and stabilisation, with scope and price based on the assessment evidence.
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 →Operating context
Fewer than about forty custom items, every interface has a named owner, and no two sites are arguing about how a job is recorded.
Planning consideration
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 →Operating context
Over a hundred custom items, several written before 2016, and two or three that nobody currently in the building can explain.
Planning consideration
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 →Operating context
Two depots record the same fault differently, both defend it, and the reporting your executive team asks for cannot be produced from the mixture.
Planning consideration
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
Upgrade delivery
Assessment, rehearsal, cutover and stabilisation
The customisation register defines the route. Measured rehearsals establish the production window and rollback decision; business owners accept behaviour and the sponsor approves cutover.
Modernise the platform while retaining operational knowledge.
An upgrade needs to carry forward the processes, records and connections your operation relies on. We assess what to retain, simplify or retire, then rehearse the transition and recovery route. Your team can review the evidence before committing to the production window.
Explore a ferry operator’s MAS upgrade-
Assess the estate
Inventory configuration, code, data volumes, interfaces, hosting and entitlement.
Decision and evidence
Verdict register, dependencies and upgrade scope.
MaxIron assesses; rule owners approve retained behaviour.
-
Rehearse the upgrade
Restore a production copy, run the upgrade and test representative business processes and interfaces.
Decision and evidence
Trial environment, comparison results and measured timings.
MaxIron runs; business and counterpart teams witness.
-
Approve and cut over
Confirm the freeze, interface sequence, reconciliation and rollback call-by time in the runbook.
Decision and evidence
Approved cutover runbook and go-live decision.
Sponsor authorises; MaxIron executes the approved run.
-
Stabilise and hand over
Verify operational transactions, watch integration queues and resolve agreed post-release issues.
Decision and evidence
Acceptance record, open items and support runbooks.
Platform owner accepts the service handover.
A trial upgrade usually follows a five-day working sequence. Data volume, attachments and interface scope determine the actual duration and cutover window.
Delivered
Three numbers from upgrades MaxIron has run
-
7 months
Maximo 7.6 to MAS 9.0.1, UK ferry operator
Against a hard regulatory deadline, including a Microsoft SQL Server to IBM DB2 conversion on Red Hat OpenShift. Read the case study.
-
5 days
Restore to signed pack, trial week
The standard shape. Longer where the attachment store or the interface count demands it.
-
5.x to 7.6.x
Maximo generations upgraded
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.
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 cloud: MaxIron Cloud, or MAS in their Azure, AWS or OCI subscription. 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.
Review the route from your estate to MAS.
Bring the configuration register, interface list and available change windows. We will scope the trial upgrade and identify the evidence needed for a programme proposal.
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