For CIOs, IT directors and heads of enterprise applications
The real question is what this estate looks like on day 1,000.
You own the cost line, the security posture, the upgrade story and the integrations nobody else wants. The decision is whether the next MAS version is a scheduled event or an unscheduled programme, and whether the number you give the board this quarter is still true in month four.
- Predictability
- Whether a commitment made at a steering committee survives contact with the estate it was made about.
- Total run cost
- Licence and infrastructure, plus the internal capacity quietly absorbed by keeping the platform alive rather than improving it.
- Security and audit posture
- Evidence that stands up in front of an auditor, produced on request rather than assembled over a fortnight.
- Risk with your name on it
- Every integration, environment and bespoke item is a risk you carry, regardless of who built it or how long ago they left.
Written for: CIO · CTO · IT Director · Director of Enterprise Applications · Head of EAM Platform
Estate specification
What a CIO pack has to settle before a board number is given
What a board upgrade number needs
- Measured on
- One non-production environment, your real data, a real cutover sequence, run deliberately early.
- Output
- What carried, what broke, which bespoke items need a decision, and which interfaces need an owner named.
- Firm price follows
- The trial upgrade, not a template. A shape and range are available immediately. See Maximo to MAS upgrade.
- Internal checklist
- Maximo to MAS upgrade checklist, published in full and free.
What stays yours under a managed estate
- Design authority
- What the platform should do, and which bespoke items the business still needs.
- Sign-off
- Your change governance, security review and procurement route.
- Counterpart calendars
- Integrations whose upstream system is mid-programme. Their release calendar stays with its own team.
- Comparison
- Managed hosting compared with an internal team, including when keeping it in house is the better answer.
If the live question is run cost
- Managed hosting
- MaxIron Cloud: what a managed estate covers and where responsibility stops.
- Estate view
- MaxIron Cloud Manager: environments, releases and health without a monthly paraphrase.
- Inherited estate
- Maximo Health Check and Heal: a structured read when you need to know what you are holding.
- Bespoke load
- Customisation modernisation for the items that make an upgrade hard to price.
If governance or integrations are the question
- Trust pack
- Security at MaxIron: certifications, sub-processors and how the platform is operated.
- Change evidence
- MaxIron Change Control: an evidence pack written as each change happens.
- Interfaces
- Maximo integrations: ownership, observability, retry behaviour and credential rotation.
- Promotion
- MaxIron Pipelines: repeatable promotion so a cutover is a rehearsed procedure.
Paid twice when these are missing: once in the contingency on every estimate, and again when a support horizon turns a deferred decision into an unscheduled programme. Case references: UK ferry operator, MAS 9 on OpenShift and UK industrial joint venture, service transition.
Conditions on a long-running estate
Five conditions, coded so a scoping paper can cite them
What a decade of reasonable, urgent decisions leaves behind, described by the people who inherited it.
| Ref | Condition | What it looks like from your chair | How the estate pays |
|---|---|---|---|
| C1 | A support horizon forces a date onto a roadmap before the estate has been inventoried. | Scoping against bespoke edges nobody has named since the last change of team. | Contingency on every estimate, then an unscheduled programme when the horizon arrives. |
| C2 | Patching, certificate rotation, environment refreshes and the annual recovery test absorb the engineers hired to improve the estate. | Platform care consumes the change budget. | Run cost paid twice: once as support, again as lost design capacity. |
| C3 | Integrations outlive the org chart that commissioned them. | The first hour of a month-end failure goes on establishing whose interface it is. | Incident time spent on ownership before repair. |
| C4 | Each bespoke item made sense when written; together they are why every change carries contingency. | Every upgrade starts with an archaeology exercise. | Unknown customisation priced as programme risk. |
| C5 | Security questionnaires, sub-processor lists and audit requests arrive without warning. | The trust story has to be evidence assembled while something else is already on fire. | A fortnight of senior time reconstructing what the record should already hold. |
Codes C1 to C5 are stable. Cite them in an internal brief the same way a bid writer cites a requirement.
Terms as we use them
Supported, upgradeable, and the boundary between them
Most estates buy the first and assume it includes the second. They are separate properties, bought at different times, and only one of them is visible in a monthly service report.
- Supported estate
- Incidents are handled, backups run, patches land and availability is reported inside an agreed response time. Measured by incident volume, response times, availability and ticket ageing. Decided in the support contract, and changeable at renewal.
- Often read as A guarantee that the next MAS version can be priced from a monthly service report.
- Upgradeable estate
- The next version can be rehearsed on your real data before anybody commits to a date in public. Measured by how much bespoke code stands between you and the current release, and who owns each item by name. Decided years earlier in how configuration, customisation and environments were engineered.
- Often read as Something that appears automatically because support tickets are clearing.
- Trial upgrade
- One non-production environment upgraded on production data with a real cutover sequence. The estimate for the board is built from what that run measured: what carried, what broke, and which items still need an owner.
- Managed service boundary
- Hosting, patching, monitoring and incident response run as a service, with the estate visible to your own team. Your regulator, board and auditor still hold you; what changes is the quality of the evidence available when any of the three asks.
The procedure
Five gates a platform engagement passes through
The second gate is why the rest of the numbers are worth anything. At each gate: what is allowed, what is refused, and who signs.
-
Gate 1 Read the estate
Signed by Your platform owner with the MaxIron engagement lead
Passes
Versions, environments, database platform, integration inventory, bespoke items and the change history that explains why each one exists.
Held back
A board number assembled from a rule of thumb before the inventory exists.
-
Gate 2 Rehearse before estimating
Signed by CIO or IT director accountable for the board commitment
Passes
One non-production environment, your real data, a real cutover sequence. Scope conversation against a result.
Held back
A firm delivery price quoted from a template estate.
-
Gate 3 Decide the customisations
Signed by Business process owner for each item
Passes
Every bespoke item kept, retired, or re-expressed as configuration or an automation script, recorded against a named owner.
Held back
Carrying unexplained customisations into the upgrade as unowned risk.
-
Gate 4 Put change behind a gate
Signed by Your change authority
Passes
Promotion through governed approval and repeatable pipelines, with evidence before an auditor asks.
Held back
Weekend promotions that leave no pack behind.
-
Gate 5 Hand over an operated estate
Signed by Service owner and MaxIron delivery lead
Passes
Hosting, patching, monitoring and incident response as a service, visible to your team rather than described once a month.
Held back
A monthly paraphrase of estate health as the only view your engineers receive.
Write these into the board paper
Five tests a board upgrade number has to pass
None of them favours MaxIron. They favour any supplier prepared to measure the estate before committing a date.
- CIO1
The number was measured on this estate, not inferred from a template.
- Passes when
- A trial upgrade on production data produced the list of what broke before the commitment was given.
- Witnessed by
- Your programme board
- CIO2
Every bespoke item that can move the number has a named owner.
- Passes when
- The customisation register names a person against each item still in scope.
- Witnessed by
- Your platform owner
- CIO3
Support and upgradeability are scored as separate properties.
- Passes when
- The pack states what the support line covers and what the upgrade rehearsal still has to prove.
- Witnessed by
- Procurement and the service owner
- CIO4
Change reaches production with an evidence pack already written.
- Passes when
- A recent production change can be reconstructed from the record without a fortnight of archaeology.
- Witnessed by
- Internal audit or your security reviewer
- CIO5
Interfaces have owners and observable failure behaviour.
- Passes when
- Each critical interface names an owner, a retry path and a credential rotation story.
- Witnessed by
- The operations lead who inherits the first month-end failure
Positions we hold before procurement
Three positions that shape what a fixed price can cover
Each one is stated the same way to every buyer.
The firm price follows the trial run
A shape, a range and the drivers behind both are available immediately. The firm figure comes from a trial upgrade measured on your estate, because a number produced before that is a template.
A managed service moves the work and sharpens the evidence
It takes the accountability for running the platform. Your regulator, your board and your auditor still hold you, and what changes is the quality of the evidence available when any of the three asks.
The interface boundary is made observable and owned
Where an ERP, GIS or historian is unstable or mid-programme, we make the boundary observable, the failure obvious and the ownership explicit. The counterpart release calendar stays with its own team.
CIOs and IT directors, questions we are asked first
- Do we have to move to MAS now?
- Not necessarily this year, but the decision has a clock attached to it because support horizons do. The useful step is to measure what the move costs on your estate before the date is forced. See extended support options if you need time, and the upgrade service for how the trial run works.
- Can you work alongside our incumbent partner?
- Yes, and it is a common arrangement, particularly where an incumbent runs application support and we take the platform, the upgrade or a specific capability. What matters is that the boundary is written down: who owns which environment, who approves a production change, and who is called first at three in the morning.
- What does a trial upgrade need from us?
- A copy of production data, one non-production environment or the ability to stand one up, and access to the people who know why the awkward customisations exist. From your side it is measured in days of involvement rather than weeks, and the output is the list of what breaks, which is the input to every number that follows.
- We have an internal platform team. Where does a managed service leave them?
- Doing the work you hired them for. In the estates we run, the internal team keeps design authority, business relationships and the decisions about what the platform should do, and stops doing patching, certificate rotation and the overnight recovery test. The comparison guide is honest about when keeping it in house is the better answer.
- How do you handle our security review?
- With current documentation rather than a bespoke response. MaxIron holds ISO/IEC 27001:2022 and ISO 9001:2015 certification through ISOQAR, a UKAS-accredited certification body, and maintains a documented sub-processor list. The detail is on the security page and the certificates are verifiable independently, which is usually the point of the question.
Ask us for the rehearsal, not the estimate.
Send what you have about the estate, however incomplete, and we will describe what a trial upgrade week on it would look like: which of your items we expect to stop the first run, what we would need from your team, and what the output would let you tell your board.
Have this to hand
- Your current Maximo or MAS version, database platform and rough database size
- The environment list, including the ones nobody refreshes
- Whatever integration inventory exists, and the interface with no obvious owner
- The date the board currently thinks is achievable