Maximo 7.6 to MAS 9.0 upgrade for a major UK ferry operator
An upgrade from IBM Maximo 7.6 to MAS 9.0.1, with migration to Red Hat OpenShift, conversion from SQL Server to IBM DB2, inventory rework and Microsoft Dynamics 365 integration. Seven months, and one usable cutover window.
The date
A vendor end-of-support milestone that applied whatever else was happening in the business. Every decision below was made against it.
- Sector
- Maritime transport & ferry operations
- Region
- United Kingdom
- Duration
- 7 months
- Scope
- MAS upgrade, cloud, integration, support
- Versions
- Maximo 7.6 to IBM MAS 9.0.1 on Red Hat OpenShift
The estate at mobilisation
Four questions a version upgrade on its own would not have answered
A vendor date on the release
IBM Maximo 7.6 was approaching its end-of-support milestone on ageing on-premises infrastructure. The date applied whatever else was in the business, and a fixed date cannot be solved by adding a phase.
Stores practice grown up beside the platform
Subassemblies, rotables and bills of materials sat partly in Maximo and partly in the working habits of the stores team, so what a rotable was depended on who was asked.
Purchase demand raised twice
Maintenance demand and financial reality were reconciled between the platform and Microsoft Dynamics 365 by a person, usually later, and maintenance cost was answered by joining two views.
A database off the target support matrix
The application ran on SQL Server, while the MAS support matrix pointed at IBM DB2.
A year-round published timetable leaves few windows in which a production platform can stop, so the plan had to fit an upgrade, a cloud migration and a database vendor conversion into effectively one of them, with a tested way back.
Seven months, in the order the decisions were forced
Against a fixed date, the sequence is the design
Six stages, each with what it produced. The right-hand column is the test of whether a stage happened: a decision with no artefact behind it was taken again later.
-
Stage 01
Every customisation, interface, report and integration counted, then classified as carry forward, rebuild as configuration, or retire. Nothing joined the plan without an owner who confirmed it was still used.
Written A scope baseline the operator signed, and a retire list agreed in writing. It found reports and interfaces in live use that were not on the original scope list.
-
Stage 02
The database conversion from SQL Server to IBM DB2 pulled inside the upgrade rather than run as a second project afterwards.
Written One planned cutover window on the plan instead of two, at the cost of a longer build phase.
-
Stage 03
Subassemblies, rotating parts, bills of materials and warehouse transactions defined with the stores and engineering teams before a single record was loaded.
Written Inventory definitions agreed in writing, with the load mapping derived from them rather than the other way round.
-
Stage 04
The Microsoft Dynamics 365 interface built so a requisition raised against a work order in Maximo arrives in finance as the same object.
Written Purchase order in Dynamics, goods receipt back against the work order, and single sign-on through the corporate identity provider.
-
Stage 05
The cutover rehearsed end to end more than once, on a clock, with the database conversion included and the rollback point written down and tested.
Written A timed runbook with a named owner against each step, shorter and with fewer manual steps after every rehearsal.
-
Stage 06
Go-live on IBM MAS 9.0.1 on Red Hat OpenShift ahead of the support milestone, with hypercare staffed by the people who built it.
Written Incident, change and release management running, and the same team carried onto the ongoing service rather than a handover to a separate desk.
The decision the whole plan turned on
Production windows were the scarce resource, not engineering effort, so the database conversion was taken inside the upgrade.
Converting SQL Server to IBM DB2 in the same programme spent one production outage instead of two and matched the MAS support matrix at the same moment. It made the build longer and the cutover shorter, and against a date that will not move the cutover is the part that has to hold.
The figures, with their basis
What this estate needed
- 7 months
- Mobilisation to go-live
- 1
- Production outage spent
- MAS 9.0.1
- Release live today
- DB2
- Application database
This estate. Duration is set by the live customisation and interface count, whether the database platform has to change, and how many production windows the operating calendar offers.
The upgrade, the move to Red Hat OpenShift and the database conversion were all taken in a single planned window.
Upgraded from IBM Maximo 7.6 on ageing on-premises infrastructure, ahead of the vendor end-of-support milestone.
Converted from SQL Server inside the programme, which removed the SQL Server licence line and matched the MAS support matrix.
Scope discipline
What the plan left out, and why
Three deferrals, agreed with the operator and written into the plan rather than dropped quietly.
Report rationalisation beyond active use
Wider MAS application uptake
Process redesign outside inventory
What we would do differently
Three things we would sequence differently
The programme met its date and its scope. These three are sequencing rather than execution, and each of them is settled before mobilisation or not at all.
- 01
Settle the inventory definitions before mobilisation
Agreeing what a rotable, a subassembly and a bill of materials mean is a business decision, and it ran in the same weeks as the platform build, competing for the same attention. We would now run it as a short pre-programme workstream so the build inherits decisions instead of making them.
- 02
Bring finance into integration design at the first session
The Dynamics 365 interface was specified once maintenance scope had settled. Purchase order and goods receipt mapping is as much a finance design as a maintenance one, and involving that team from the first design session removes a set of decisions that otherwise arrive late in the build.
- 03
Start crew enablement weeks before cutover
Maximo Mobile was treated as a rollout with training attached. We would now begin enablement with vessel-side and shore-side supervisors weeks before go-live, so the first week on the new platform is not also the first week on the new way of working.
Where it stands now
The platform the operator runs today
Platform
- Release
- IBM MAS 9.0.1, upgraded from IBM Maximo 7.6
- Runtime
- Red Hat OpenShift, managed environment
- Database
- IBM DB2, converted from SQL Server during the upgrade
- Identity
- Corporate identity provider, single sign-on across MAS applications
Work, parts and money
- Finance
- Microsoft Dynamics 365: purchase order out, goods receipt back against the work order
- Inventory
- Subassemblies, rotables, bills of materials and warehouse transactions held in Maximo
- Field execution
- Maximo Mobile, vessel-side and shore-side crews
- Support
- MaxIron managed service, with the architects who designed the upgrade still on the account
Anonymised. Client-identifying systems, vessels, sites and naming removed.
If your support date is the problem
Services and products in this engagement
What buyers ask us about this upgrade
- Is seven months repeatable on our estate?
- Seven months was what this estate needed. What sets the duration is the number of live customisations and interfaces, whether the database platform has to change, how much inventory and asset data needs decisions rather than mapping, and how many production windows your operating calendar offers. Maximo to MAS upgrade sets out the shape of the work, and MaxIron Upgrade Factory covers how we industrialise it across several estates.
- Why convert the database during the upgrade rather than afterwards?
- Because production windows were the scarce resource. Converting from SQL Server to IBM DB2 inside the same programme spent one planned outage rather than two, and matched the MAS support matrix at the same moment. It is not automatically the right call: Maximo database conversion covers when we would separate the two.
- What stayed hard?
- Deciding what a rotable is, and getting stores and engineering to agree on it. Data definitions are a business conversation and software does not shorten them. Mobile adoption was the same: putting Maximo Mobile on a device is a deployment, and getting crews to work through it is a supervision job that continues after go-live.
- Why is the operator not named?
- Anonymised at their request. Operators in this sector treat platform and cutover detail as commercially sensitive, and an accurate anonymised account is worth more to a buyer than a named one with the substance removed. Reference conversations are arranged under an NDA once a discussion is serious.
- Who supports the platform now?
- MaxIron, on a managed service basis, with the same architects who designed the upgrade still on the account. The hosting and operational model is described on MaxIron Cloud.
A fixed support date and a hard downtime limit is the conversation we are useful in.
Ninety minutes on your estate. We will say where the sequence is tight, where you are carrying scope you could retire, and whether your date needs a programme this size.
Bring this and we can be specific in the first call
- Your current Maximo version, database platform and hosting arrangement.
- A list of customisations and interfaces, even an incomplete one, with a name against each.
- The reports your business genuinely uses, separated from the ones that exist.
- Your operating calendar, showing the windows where the platform could be down.
- Your licence and AppPoints position, or whatever you have of it.