Maximo service transition, stabilisation and support uplift for a UK industrial joint venture
Taking over a live IBM Maximo environment from an incumbent supplier, in two months, with no extended parallel running. A transition like this is a risk exercise rather than a project, so this is written as the register of what goes wrong and what we did about each one.
How this is written
As a failure-mode register. Six ways a support handover goes wrong on a live platform, and the control we used against each.
- Sector
- Industrial services & engineering
- Region
- United Kingdom
- Duration
- Transition completed in 2 months
- Scope
- Service transition, stabilisation, BAU support
- Versions
- IBM Maximo (production)
What we walked into
A live production platform with weak governance and a date that would not move
Service had deteriorated
Response times slowed, unresolved issues accumulated, and the client had limited visibility into their own platform.
No structured controls
No structured reporting, no formal change control, no clear improvement roadmap.
Production depended on it
Maximo underpins live operational processes, so a service failure shows in production schedules within days.
Contractual handover date
The transition date came from the outgoing contract, not from a readiness assessment.
One party is accountable on the Friday and another on the Monday, with no extended parallel running.
The register
Six ways a support transition fails, and the control for each
None of these are hypothetical. They are what a transition method exists to prevent.
01, Handover pack describes an estate that no longer exists
02, Transition day turns into discovery day
03, Users lose their route to support
04, Inherited backlog worked in arrival order
05, Same defect returns under a new ticket number
06, Improvement work quietly disappears
The constraint
A contractual handover date, a live production platform, and no parallel running concentrate the whole risk into a single day.
The only direction risk can move is earlier. The cutover was short because the preparation was not: verified capture, owned assumptions, and a tested fallback for support routing.
The two months, in order
Five stages, each with an owner and a duration
Full operational responsibility inside two months. Governance stood up during the transition so the first service review covered the handover itself.
- 01
Assessment
Configuration, interfaces, customisations, scheduled jobs, backlog and workarounds read from the estate. Output was a risk list ordered by operational consequence.
Owner Incoming MaxIron lead, with operations Typically Week 1-2
- 02
Knowledge capture
Checklist against the platform: configuration inventory, interfaces, jobs, runbooks, access, licences. Unverifiable items written as owned assumptions.
Owner Transition team Typically Week 2-4
- 03
Controlled cutover
Named day, named responsibilities, support routing switched in one step, fallback for the routing itself tested.
Owner Both parties on the cutover day Typically One day
- 04
Stabilisation
Defects and configuration issues worked in operational-consequence order. Recurring items split into platform versus process before either was fixed.
Owner Support team with operations Typically Remainder of the two months
- 05
BAU support
Incident, problem, change and release management live, with a jointly maintained improvement backlog reviewed monthly.
Owner MaxIron managed service Typically Ongoing
Held back, and what we would change
Three refusals during transition, and three sequencing changes next time
Each refusal was held until support ownership was settled. The sequencing changes are about the weeks before cutover.
No upgrades or process redesign during transition
Changing the version while changing the support provider means that if something breaks, you cannot tell which change caused it.
Plan on the estate as the only source of truth
Build the transition on discovery from the estate as the primary source; treat incoming documentation as a cross-check only.
Risk prioritisation with operations in week one
Hold that session in the first week, treat its output as the stabilisation plan, and begin service reporting from day one of the transition.
Shape of the handover
Assessment to BAU inside two months
Users saw a new contact route rather than a change in service. Afterwards a problem becomes an incident with an owner and a clock, then a problem record, then a line in the monthly service review.
Stages on the bar
- Preparation
- Assessment and knowledge capture move risk out of cutover day.
- Cutover
- Single-step routing switch with a tested fallback.
- After
- Stabilisation by operational consequence, then roadmap-led BAU support.
Where it stands now
The support model after the handover
Transition result
- Window
- 2 months to full operational responsibility
- Parallel run
- None extended; single-step cutover
- Disruption
- Zero service disruption to live production processes
- Platform
- IBM Maximo (production), left on the inherited version during transition
What was stood up
- Governance
- Service reporting, incident and problem management, change and release
- Stabilisation
- Risk-ordered defect and configuration clearance with causes recorded
- Improvement
- Joint backlog reviewed monthly alongside operational work
- Left alone
- Existing operational system connections preserved as-is
Anonymised. Client-identifying detail removed.
If your support arrangement has stopped working
Services and products in this engagement
What buyers ask before changing support provider
- Why is the client not named?
- Anonymised at their request. A supplier change is a sensitive commercial matter and naming the client would also identify the outgoing supplier. We can arrange a reference conversation under an NDA when a discussion is serious.
- Two months with no parallel running. How is that safe?
- It is safe when the risk is moved out of transition day and into the weeks before it: verifying every captured item against the platform, writing unverifiable ones up as owned assumptions, and defining a fallback for the support routing itself.
- What happens if the outgoing supplier will not co-operate?
- You plan on the estate being the source of truth. Documentation from an outgoing party is a cross-check, not a foundation. Every transition we run is designed to work without goodwill, and better when there is some.
- Do you change the platform during a transition?
- Only what is needed to remove operational risk. No upgrades, no process redesign, no configuration tidying while support ownership is moving. Those go on the improvement backlog. See MaxIron Cloud for the ongoing service.
- What stays hard?
- Separating platform problems from process habits. A recurring defect is often a workaround that became a way of working, and fixing it in configuration keeps the cause intact.
When a support arrangement ends, the handover is the hard part.
A transition assessment that tells you what can be verified from your estate, what depends on your current supplier, and whether your contractual dates allow a single-step cutover or need an overlap. If your incumbent is recoverable, we will tell you that instead of quoting you.
Bring this and the assessment can be direct
- Your current support contract dates and notice position.
- Whatever documentation you hold, including the parts you suspect are out of date.
- Your open ticket list, and the items operations would put at the top regardless of age.
- Which business processes stop if Maximo is unavailable for a day.
- Your access and credential position, and who currently holds it.