Maximo 7.6 to MAS 9.0 upgrade for a major UK ferry operator
IBM Maximo 7.6 upgraded to MAS 9.0.1, with inventory rework, Dynamics 365 integration and continuing support.
Engagement summary
Download client brief (PDF)- Situation
- A year-round ferry timetable and a fixed support milestone limited the available production cutover windows. IBM Maximo 7.6 ran on ageing infrastructure and SQL Server.
- MaxIron responsibility
- MaxIron held the upgrade, OpenShift migration, database conversion, inventory design and finance integration, then continued with platform support. The operator approved scope, data definitions and cutover.
- Delivery
- The team inventoried live customisations, agreed stores definitions, built the Dynamics 365 interface and rehearsed the combined upgrade and conversion with a timed rollback plan.
- Outcome
- MAS 9.0.1 went live in seven months through one planned production outage. IBM DB2, Maximo Mobile and finance integration operate on the new estate, with the delivery architects retained on the account.
Anonymised client engagement. Reference conversations require client permission and an NDA where applicable.
The estate at mobilisation
Four operating requirements shaped the upgrade
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
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.
-
1
Production outage spent
The upgrade, the move to Red Hat OpenShift and the database conversion were all taken in a single planned window.
-
MAS 9.0.1
Release live today
Upgraded from IBM Maximo 7.6 on ageing on-premises infrastructure, ahead of the vendor end-of-support milestone.
-
DB2
Application database
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.
Programme architecture
One cutover connects the upgrade to live operation
The combined build included the database conversion and the finance interface. Support retained the architects who designed it.
01 · Scope and design
- IBM Maximo 7.6 / SQL ServerCount active customisations, reports and interfaces; agree retire list.
- Stores and financeDefine rotables, subassemblies and bills of materials; map Dynamics 365 transactions.
02 · Build and rehearse
- MAS 9.0.1 / OpenShift / DB2Build the supported target and convert the database inside the upgrade.
- Timed cutover runbookRehearse the combined move with named owners and a tested rollback point.
03 · Go-live and operate
- One production outageComplete the combined move within the operating window.
- Same delivery architectsCarry platform knowledge into hypercare and ongoing MaxIron support.
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.
Engagement facts
- 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
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?
- The operator requested anonymisation. Client-identifying vessels, sites and records are withheld. Reference conversations require client permission and an NDA where applicable.
- 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.