How long does an IBM Maximo implementation take? The honest answer is: longer than you want, shorter than you fear, and entirely dependent on three things — scope, data, and decisions.
This guide gives you realistic timelines, the phases that consume them, and the places where most programmes lose weeks they did not need to.
Realistic timelines by scope
These are bands drawn from current UK programmes, calibrated to be neither aggressive nor padded.
- Single-site, single-business-unit, conventional EAM scope: 4–9 months from contract signature to go-live
- Multi-site rollout following a templated pilot: 9–18 months total, with the pilot site landing within the single-site band
- Greenfield enterprise programme spanning multiple business units, integrations and mobile: 12–24 months
- Maximo to MAS upgrade: 4–9 months for a focused upgrade, longer for heavily customised legacy estates
- Cloud migration of an existing MAS deployment: 2–4 months
A programme that is being sold to you in half these timelines is being sold optimistically, not aggressively. Aggressive is fine if it is honest. Optimistic is what produces the slip you are trying to avoid.
Where the time actually goes
The implementation phases are well-known. The time consumed by each is often surprising.
Discovery and target operating model: 4–10 weeks
This is the phase where the programme either gets sharper or fuzzier. Done well, it sharpens scope and commits the business to operating-model decisions. Done badly, it surfaces decisions that should have been made before contract, costing four to six weeks of slip later.
Solution design and configuration baseline: 4–8 weeks
Asset hierarchy, classification, work-type discipline, security model, organisational structure, codes and lookups. This is where Maximo expertise pays for itself: a senior team will close design decisions in four weeks that an inexperienced team will reopen for ten.
Build and configuration: 8–16 weeks
Configuration, custom-code where unavoidable, base reports, mobile patterns. Runs in parallel with integration build.
Integration build: 6–14 weeks
Per integration, depending on complexity. Integrations are where programmes lose the most time, because each one depends on the readiness of the system at the other end.
Data migration cycles: 6–12 weeks
Three to five cycles, with the first deliberately rough to expose the issues, the middle ones cleaning up, and the last being the cutover dress rehearsal. Programmes that try to do this in two cycles regret it.
SIT, UAT and training: 4–8 weeks
System integration test, user acceptance test, training delivery. Often overlapping. Often compressed to make a date. Compression here is one of the most expensive false economies in the programme.
Cutover and hypercare: 1–2 weeks cutover, 4–8 weeks hypercare
Cutover is the visible event. Hypercare is what makes the cutover stick. Hypercare staffed by named senior engineers, with a clear triage process, prevents the early go-live issues from becoming permanent operational pain.
Where programmes lose weeks they did not need to
In our experience, most programmes that slip lose time to one of five things.
Decisions that should have been made before contract
Operating model, asset hierarchy principles, integration scope. Closing these in week one is normal. Closing them in week ten costs you eight weeks.
Data quality assumptions that turn out to be wrong
Source data is always worse than the source-system owners think it is. Plan for this, do not be surprised by it.
Integration partners on the other side of the integration
The system at the other end of every integration has its own owner, who has their own roadmap. Get them in the room early.
Customisation that should have been configuration
Every customisation that is later replaced by configuration is wasted time twice over. Press hard on the configuration-versus-customisation decision in design.
Stakeholder absences at key decision points
Programmes that pause for two weeks because the decision-maker is on leave usually never recover those two weeks. Plan around the calendar from day one.
How to compress without breaking
Some compression techniques are real. Some are wishful.
Real:
- Discovery in parallel with mobilisation, not sequentially
- Trial upgrade environment in week one for upgrade programmes (we commit to this)
- Templated multi-site rollout with one well-run pilot
- Senior team on day one, not ramping up over the first month
- Integration partners committed in advance, not chased mid-programme
Wishful:
- Skipping data migration cycles
- Compressing UAT
- Reducing hypercare staffing
- Running discovery and design ‘in the build phase’
- Replacing senior team members with juniors after contract
How MaxIron fits
We give realistic timelines and we hit them. Where we cannot hit a date the client wants, we say so before contract. Where we can compress honestly, we do. If you would like a direct conversation about a realistic timeline for your specific scope, get in touch.
Talk to the people who would actually deliver it
No pitch deck, no pressure. A direct conversation with one of our senior consultants.
Related services