At 09:30 on a Monday, an integration architect on an MAS 9.1 estate opens an IBM download that arrived over the weekend: IBM Maximo Enterprise Connector for SAP S_4HANA by IBM.zip. Their SAP counterpart gave notice the previous week that the shared PI 7.5 tenant is being decommissioned during 2027 as part of the group’s SAP BTP consolidation. The Maximo-SAP integration for purchase requisitions, purchase orders, goods receipts and vendor invoices has been running on SAP PI/PO since 2019. The IBM archive is IBM’s answer to the middleware question: the same connector packaged for a different middleware. Understanding what is inside the archive, and what stays on the Maximo Manage side, is the difference between a scoped migration and a re-implementation dressed as one.
What actually ships in the CPI package
IBM published the modernised Maximo Connector for SAP in the February 2026 MAS Feature Channel for non-production use, and confirmed production readiness with MAS 9.2 GA on 25 June 2026. The middleware layer moves from SAP PI/PO to SAP Cloud Platform Integration (SAP CPI, delivered through the SAP Integration Suite on SAP BTP). IBM’s own note is explicit: existing business scenarios, mappings and integration patterns continue to function without modification. What has changed is where the messages hop between Maximo Manage and SAP.
The archive is imported into an SAP BTP tenant with an Integration Suite subscription. IBM’s documentation names the prerequisites plainly: access to SAP BTP Cockpit, an Integration Suite subscription, and a CPI tenant with the Design role. The package contains the integration flows (iFlows) and the value mappings that were previously delivered as PI/PO objects. Each iFlow implements one direction of one business scenario: item master out to SAP, purchase order out to SAP, goods receipt in from SAP, invoice status in from SAP, and so on. Deployment is standard SAP Integration Suite work: import the package, configure the destination and credentials, deploy the artefacts, monitor from CPI’s message monitor.
What stays on the Maximo Manage side
The Maximo Manage side of the integration is unchanged in shape. The Integration Framework has been in Maximo since version 6 (2008), and the same artefact families still carry the load: Object Structures define the payload shape, Publish Channels push data outbound, Enterprise Services receive data inbound, and Invocation Channels handle synchronous calls. The Maximo Connector for SAP installs a defined set of these interfaces in Maximo Manage, together with interface controls that translate Maximo values to SAP values and back.
Nothing in that inventory needs a rewrite for the CPI move. The endpoints and cryptomaterial that Publish Channels and Enterprise Services point at change, because the middleware address changes; the interfaces themselves do not. Custom automation scripts that decorate the outbound message, custom cross-object rules, and any bespoke object structure extensions carry across on the same terms they had before. This is the point IBM’s release note is making when it says interface logic is preserved: the MIF side of the contract is stable.
Where each part actually runs
The connector spans three runtimes, and each carries a distinct ownership contract once CPI is live.
| Runtime | Artefacts | Owner |
|---|---|---|
| Maximo Manage on OpenShift | Object Structures, Publish Channels, Enterprise Services, Invocation Channels, interface controls, automation scripts | MAS platform team |
| SAP BTP Integration Suite tenant | iFlows from IBM’s CPI package, value mappings, credential material, message monitor | SAP integration team |
| SAP S/4HANA or ECC | BAPIs and IDoc handlers targeted by the iFlows | SAP applications team |
The move sharpens a boundary that PI/PO tended to blur, because the middleware now sits on the SAP side of the fence rather than on shared infrastructure. On most estates that is a governance improvement: message monitoring, iFlow versioning and BTP entitlements go where the rest of the SAP integration landscape already lives. On a few, where PI/PO was run by the Maximo team, it is a re-allocation of ownership that needs to be agreed before the cutover, not after it.
Migrating a live PI/PO integration, in order
For an estate with a working production PI/PO integration, four steps carry most of the risk.
- Confirm the Maximo Manage version is on MAS 9.1 or MAS 9.2 and that the Maximo Connector for SAP add-on is at the current fix level. IBM supports the CPI-capable package from MAS 9.1 forward.
- Stand up a non-production BTP tenant with an Integration Suite subscription, import the IBM package, and wire it against a non-production Maximo Manage and a non-production SAP client. This is the minimum footprint that will tell you whether message-level parity holds.
- Run each business scenario end-to-end and reconcile against the same scenario on PI/PO: item, PR, PO, goods receipt, invoice, and any custom flows layered on top. Value mappings are where quiet regressions hide, particularly for company code, plant, storage location and unit of measure.
- Plan a cutover window per interface, not for the whole connector. The middleware endpoints on the Maximo side change one Publish Channel or Enterprise Service at a time, which lets the operator run PI/PO and CPI in parallel until the last interface is cut over.
What stays hard
The CPI migration lives on the middleware side, and the effort follows it there. SAP BTP Integration Suite is a paid subscription with its own runtime, licence unit and operating cadence; a Maximo-side estimate that ignores the BTP entitlement conversation is not an estimate. Interface owners still have to reconcile every value mapping against production behaviour, because functional parity is a property that is verified interface by interface, not asserted by the vendor. Error handling and retry patterns move with the middleware: the CPI message monitor is not the PI/PO runtime monitor, and the alerting integration into whatever the SAP operations team uses has to be rebuilt on the CPI side. On estates where PI/PO was quietly the Maximo team’s responsibility, the CPI move raises an operating-model question the programme has to settle before go-live: who is on call for the middleware at 02:00 on the night the month-end invoice run fails.
The position to take into the meeting
For an MAS 9.1 or 9.2 estate with a live SAP integration on PI/PO, the CPI-capable Maximo Connector for SAP is the destination, and the migration is a scoped middleware move rather than a re-implementation. The scope conversation belongs primarily with the SAP integration team, because the new artefacts live in their BTP tenant. The Maximo Manage side carries a certified add-on upgrade, an endpoint reconfiguration, and an interface-by-interface parity test. Programmes that treat this as a Maximo project will under-scope the BTP work; programmes that treat it as an SAP project will miss the interface controls and object structures on the Manage side that decide whether functional parity actually holds. Both teams sitting in the same governance forum, with one integration inventory covering both sides, is the operating condition this migration needs.
For teams working through the wider MAS 9.2 upgrade decisions, the note on what landed with MAS 9.2 GA sits alongside this, and the MaxIron managed MAS service is where the operational side of MIF integration governance actually lives day to day.