The Modern Maximo ERP Integration Playbook: SAP CPI, Oracle Cloud, and ACE in 2026

The integration landscape around IBM Maximo has shifted dramatically in 2026. For years, Maximo teams built fragile point-to-point connections between Maximo Integration Framework (MIF) and their ERP systems using aging middleware that nobody wanted to maintain. SAP PI/PO adapters, custom BAPI wrappers, and Oracle interface table patterns were the norm. They worked, but they were never built for the cloud-native, containerized world that Maximo Application Suite (MAS) now operates in. The technical debt from these legacy patterns has been accumulating for years, and the cost of maintaining them grows with every MAS release.

Two developments have changed the calculus. First, IBM modernized the Maximo Connector for SAP Applications to support SAP Cloud Platform Integration (SAP CPI) as its middleware layer, replacing the legacy SAP PI/PO adapter. Second, IBM and Oracle announced a new connector between Oracle Fusion Cloud ERP and MAS, expanding the Oracle integration footprint beyond the traditional E-Business Suite connector. Together with the bundled IBM App Connect Enterprise (ACE) entitlement that ships with every MAS license, Maximo teams now have three legitimate, supported paths to ERP integration that did not exist in this form two years ago.

This article breaks down each path, the architectural patterns they enable, and the practical decisions Maximo teams need to make in 2026. Whether you are running Maximo 7.6.x with legacy integrations or already on MAS and looking to modernize, the guidance here applies.

The SAP Connector Modernization: From PI/PO to CPI

In March 2026, IBM released a significant update to the Maximo Connector for SAP Applications. The connector has been modernized to support SAP Cloud Platform Integration (SAP CPI) as the middleware layer, replacing the legacy SAP PI/PO adapter. This is a major architectural shift that aligns Maximo with SAP's current cloud integration direction. The update was announced on the IBM Community platform by Hari Krishna Mandalapu and has been available in the MAS February Feature Channel since that release.

The key point for existing Maximo-SAP integrations: all existing interface logic, business scenarios, mappings, and integration patterns continue to function without modification. The transition from SAP PI/PO to SAP CPI is transparent to existing Maximo-SAP integrations. Your object structures, publish channels, invocation channels, and enterprise services remain the same. What changes is the middleware layer that sits between Maximo and SAP.

The updated connector is available now in the MAS February Feature Channel for non-production use, supported for MAS 9.1 and all forward MAS versions. Production readiness is planned with MAS 9.2 GA. This gives teams a window to validate CPI-based integration in sandbox environments before committing to production.

The integration pattern remains straightforward:

Maximo Manage --> MIF --> SAP CPI --> SAP ECC/S4HANA

What SAP CPI brings to the table that PI/PO did not:

• Cloud-native deployment with no on-premise middleware servers to maintain or patch
• Native REST and OData API support, aligning with SAP S/4HANA's API-first architecture
• Built-in message monitoring and error tracking through SAP Integration Suite dashboards
• Pre-packaged integration flows (iFlows) that can be customized without starting from scratch
• Support for SAP BTP (Business Technology Platform) services, enabling event-driven architectures
• Reduced infrastructure footprint: no more maintaining a dedicated SAP PI/PO server with its own database, Java stack, and patching cycle

For Maximo teams currently running SAP PI/PO, the migration path is incremental. You do not need to move all integration flows at once. Start with a single flow, validate it in CPI, run it in parallel with the legacy PI/PO flow, and switch over when you have confidence. The connector handles the Maximo side of the equation; your SAP CPI team handles the SAP side.

A practical example: consider a purchase order integration flow. In the legacy PI/PO pattern, Maximo publishes a PO via an enterprise service, PI/PO transforms the XML, and SAP creates the PO via a BAPI call. In the new CPI pattern, Maximo publishes the same enterprise service, CPI receives it, transforms it using an iFlow, and SAP creates the PO via an OData API call. The Maximo configuration does not change. The enterprise service, object structure, and publish channel all remain the same. Only the endpoint URL and the middleware processing change.

The practical impact: Maximo teams that have been delaying SAP S/4HANA migrations because of integration concerns now have a supported, documented path forward. The connector modernization removes one of the most common blockers for MAS upgrade projects.

The Oracle Fusion Cloud ERP Connector: A New Frontier

In May 2026, IBM and Oracle announced an expanded partnership that includes a new connector between Oracle Fusion Cloud ERP and MAS. This is significant because the existing Maximo Connector for Oracle Applications was built for Oracle E-Business Suite (EBS), not Oracle Cloud ERP. Organizations migrating from EBS to Oracle Cloud ERP previously had to build custom integrations or rely on generic MIF REST calls with no vendor support.

The new connector aims to provide the same level of out-of-the-box integration that the SAP connector offers: pre-built business flows, data mappings, and supported templates that reduce custom development. While the connector is still in development, the architectural direction is clear and the partnership announcement provides a roadmap for teams planning Oracle Cloud migrations.

For teams currently integrating Maximo with Oracle EBS, the existing connector remains supported. It uses MIF invocation channels and Oracle's REST endpoints. A common pattern that has been documented in the IBM Community involves:

• Creating custom attributes in MATUSETRANS to track integration status (ERPSENT boolean, ERPMSG ALN)
• Building an escalation on MATUSETRANS that triggers an invocation channel when issuetype is ISSUE or RETURN and ERPSENT equals 0
• Setting up an invocation channel named INVENTORYOUT with the appropriate object structure including itemnum, siteid, binnum, quantity, issueunit, and gldebitacct
• Creating a REST handler pointing to the Oracle ERP URL with POST method, Basic Auth, and application/xml content type
• Using an autoscript as a User Exit to parse and transform data before sending

The field mapping between Maximo and Oracle is well-established through community documentation:

Maximo Field Oracle Parameter Notes

SITEID PORGANIZATIONCODE Via SITEXREF crosswalk

ITEMNUM PINVENTORYITEM Direct mapping

BINNUM PSUBINVENTORYCODE Parse locator code

QUANTITY PQUANTITY Direct mapping

ISSUEUNIT PUOMCODE Direct mapping

GLDEBITACCT PACCOUNTCCID Resolve externalrefid

For teams migrating to Oracle Cloud ERP, the new connector will handle the translation between Maximo's data model and Oracle Cloud's REST API structure. The MXGLTXN object in Maximo remains the foundation for inventory transaction integration. All inventory transactions are locked into this table through MATUSETRANS, MATRECTRANS, and INVTRANS. The new connector will map those transactions to Oracle Cloud's account transaction APIs without requiring custom XSL transformations or manual field mapping.

The strategic message is clear: IBM is investing in Oracle Cloud ERP integration, and Maximo teams planning Oracle migrations should monitor the connector roadmap rather than building custom integrations from scratch.

App Connect Enterprise: Your Bundled Integration Engine

Here is the truth that most Maximo teams do not realize: if you run MAS, you already have a powerful integration engine included in your license. IBM App Connect Enterprise (ACE) is bundled with MAS under a restricted-use entitlement. It is licensed. It is supported. And it can replace a lot of the fragile middleware complexity that teams typically build from scratch or purchase separately.

ACE is a full-featured integration runtime that supports message transformation, routing, protocol mediation, and API orchestration. It is the evolution of IBM Integration Bus (IIB) and is designed for cloud-native and containerized deployments running on Red Hat OpenShift. The terms of the bundled entitlement are straightforward: if one side of the integration is MAS, you are covered. This means no extra ACE license, no mandatory SAP middleware for non-SAP flows, and no custom BAPI gymnastics for edge-case integrations.

What ACE enables in practice:

• Protocol mediation: ACE can receive messages from Maximo via MIF over HTTP, JMS, or MQ, transform them, and forward them to any target system using a different protocol entirely.
• Data transformation: ACE includes a rich mapping toolkit for converting between XML, JSON, CSV, COBOL copybooks, and industry-standard formats like EDI and SWIFT.
• API orchestration: ACE can compose multiple API calls into a single integration flow, handling error compensation and retry logic that would require significant custom code in MIF alone.
• Content-based routing: Messages can be routed to different targets based on payload content, headers, or environmental conditions. A single MIF publish can fan out to multiple downstream systems.
• Error handling and dead letter queues: ACE provides robust error handling with retry policies, dead letter queues, and alerting that goes far beyond what MIF's built-in error logging offers.

A typical architecture using ACE looks like this:

Maximo Manage --> MIF Publish Channel --> HTTP/JSON --> ACE Flow --> Target System
                                                        |
                                                        +--> SAP S/4HANA (via CPI or direct)
                                                        +--> Oracle Cloud ERP
                                                        +--> Data Lake (S3 / Azure Blob)
                                                        +--> Salesforce CRM
                                                        +--> Kafka Topics for event streaming
                                                        +--> ServiceNow for work order sync

The ACE flow handles transformation, enrichment, error handling, and delivery confirmation. Setting up ACE to receive messages from Maximo involves several key steps. First, you create an Object Structure in Maximo Manage that defines the data you want to publish. Then you configure a publish channel with the appropriate endpoint pointing to your ACE flow. ACE receives the message, applies transformation rules defined in a message flow, and delivers it to the target system using the appropriate protocol.

For teams running multiple ERP integrations, ACE becomes the central hub. Instead of maintaining separate integration paths for SAP, Oracle, and other systems, you build one MIF-to-ACE flow and let ACE handle the fan-out to multiple targets. This simplifies monitoring, error handling, and governance. A single ACE dashboard can show you the status of every integration flow across all your connected systems.

A practical scenario: a manufacturing company runs Maximo on MAS with SAP for finance and Oracle EBS for inventory. Instead of maintaining two separate integration paths, they use ACE as the central hub. MIF publishes work order completion events to ACE. ACE routes financial data to SAP via CPI, inventory transactions to Oracle via REST, and operational data to a Snowflake data lake for analytics. All flows are monitored from a single ACE dashboard, and error handling is centralized.

Architectural Patterns for 2026: What to Use When

With three supported integration paths, Maximo teams need clear guidance on when to use each one. The decision tree is simpler than it looks.

Use the SAP Connector with CPI when: You are integrating with SAP S/4HANA or SAP ECC and want pre-built, supported integration templates. The connector handles the SAP-specific complexities (BAPIs, IDocs, OData services) so you do not have to. This is the recommended path for any Maximo-SAP integration in 2026.

Use the Oracle Connector when: You are integrating with Oracle EBS (existing connector) or Oracle Cloud ERP (new connector when available). For EBS, the existing connector with MIF invocation channels and REST endpoints remains the supported approach. For Oracle Cloud ERP, wait for the new connector rather than building custom REST integrations that will need to be rebuilt when the connector ships.

Use ACE for everything else: When you need to integrate Maximo with non-ERP systems (IoT platforms, data lakes, Kafka topics, custom applications, Salesforce, ServiceNow), ACE is your tool. It handles the protocol mediation, transformation, and routing that would otherwise require custom code or third-party middleware.

Use ACE alongside the connectors: The connectors and ACE are not mutually exclusive. You can use the SAP connector for core ERP flows and ACE for supplementary integrations. For example, a common pattern is using the SAP connector for purchase order and invoice flows, while using ACE to push Maximo work order data to a data lake for analytics or to synchronize asset data with a GIS system.

The pattern to avoid in 2026: direct database-to-database integration. MAS's sealed container architecture does not support direct database access to ERP interface tables. The interface table pattern requires network-level database connectivity that violates MAS's security model. Both SAP and Oracle have deprecated interface tables in favor of REST/OData APIs in their modern ERP versions. If you are still using this pattern, it is time to plan your migration.

The Maximo Enterprise Adapter (MEA) is also not supported in MAS. The Java adapter classes depend on server-side Maximo internals that do not exist in the containerized MAS architecture. If you have custom MEA adapters, they need to be rewritten as MIF integration flows or ACE message flows.

Migration Strategy: Phased, Parallel, and Reversible

You do not modernize your ERP integration in a single big-bang cutover. You do it in phases, starting with the lowest-risk flows and building toward the most complex. Here is the proven approach used by Maximo implementation teams:

Phase 1: Master Data Synchronization. Start with the least risky flows: material master, equipment master, and GL account synchronization. Build the middleware flows for each master data type. Run the modern flows in parallel with the legacy flows. Compare outputs daily using reconciliation reports. When outputs match for five consecutive days, decommission the legacy flow. Success criteria: MAS has a complete, accurate copy of all ERP master data, refreshed daily via modern API-mediated flows.

Phase 2: Transactional Flows. Move to purchase requisitions, purchase orders, and goods receipts. Build the real-time event-driven flows for PR creation and PO receipt. Implement the goods receipt flow. Run in parallel with legacy flows, comparing every transaction. Reconcile daily: every PR in MAS should have a corresponding PR in the ERP, and vice versa. Discrepancies must trigger automated alerts, not wait for month-end reconciliation.

Phase 3: Financial Flows. Finish with the highest-risk flows: invoices, cost allocations, and financial reporting. These flows have the strictest reconciliation requirements and the highest business impact if they fail. Run parallel for a full accounting period before switching over. This means 30 to 45 days of parallel processing for most organizations.

The critical rule: never decommission a legacy flow until you have validated the modern flow in parallel for a minimum of two weeks. For financial flows, run parallel for a full accounting period. Document rollback procedures so you can revert to the legacy pattern within hours, not days, if the modern integration fails.

A checklist for SAP integration modernization:

• Inventory all existing MIF-to-SAP flows. Document every enterprise service, publish channel, and invocation channel that touches SAP. Include direction, frequency, volume, and business criticality of each flow.
• Identify SAP OData API equivalents for each legacy flow. Not every BAPI or RFC has a direct OData equivalent. Document gaps early and plan workarounds.
• Assess middleware readiness. Determine whether you are migrating to SAP Integration Suite or IBM App Connect. This decision drives your transformation logic approach.
• Map Maximo-to-SAP data model differences. Create a complete mapping document covering sites/plants, items/materials, locations/functional locations, and financial hierarchies. Identify where crosswalk tables are needed.
• Test with SAP sandbox environment. Never test ERP integrations against production. Run volume tests at 2x your expected peak load.
• Define reconciliation reports. Build reports that compare record counts and key values between MAS and SAP on a daily basis. Discrepancies must trigger alerts, not wait for month-end close.
• Plan the parallel run. Run old and new integrations simultaneously for a minimum of two weeks, ideally four. Compare outputs daily.
• Document rollback procedures. If the modern integration fails, you need to revert to the legacy pattern within hours, not days.

Practical Implications

For Maximo architects, the 2026 integration landscape means you can stop building custom middleware and start using supported connectors and the bundled ACE entitlement. The SAP CPI connector modernization removes the most common blocker for SAP S/4HANA migration projects. The Oracle Fusion Cloud ERP connector signals that IBM is committed to supporting Oracle Cloud migrations, not just EBS. And ACE gives you a general-purpose integration engine that can handle non-ERP integrations without additional licensing.

The practical impact on procurement cycles is significant. Teams that previously needed budget for SAP PI/PO middleware, custom Oracle integration development, or third-party integration platforms can now redirect that budget toward implementation services and data quality improvements. The ACE entitlement alone can save organizations tens of thousands of dollars annually in middleware licensing fees.

For teams currently running Maximo 7.6.x with legacy integrations, the message is clear: plan your migration now. The patterns that worked in the WebSphere and on-premise era do not translate to MAS's containerized architecture. The connectors and ACE are designed for the cloud-native world; your legacy integrations are not. Budget time for integration modernization as part of your MAS upgrade project, not as an afterthought discovered during implementation.

The risk of inaction is real. Organizations that delay integration modernization face increasing maintenance costs, shrinking support for legacy middleware, and growing technical debt that makes future upgrades harder. Every quarter you wait, the gap between your integration architecture and IBM's supported patterns grows wider.

Bottom Line

The Maximo ERP integration story in 2026 is no longer about building custom middleware. It is about choosing the right supported connector and leveraging the bundled ACE entitlement. The SAP connector with CPI support is available now for non-production use, with production readiness in MAS 9.2. The Oracle Fusion Cloud ERP connector is in development with a clear roadmap. ACE is available today in every MAS license. If your Maximo-to-ERP integration still relies on PI/PO, interface tables, or custom BAPI wrappers, 2026 is the year to start your migration. The tools are ready and supported. The question is whether your team has the budget and bandwidth to execute.