MAS 9.2 Integration Architecture: MCP Server, REST APIs, and the Future of Connected Assets

The release of Maximo Application Suite 9.2 in June 2026 marks a turning point in how organizations connect their enterprise asset management systems to the broader technology landscape. For years, Maximo integrations were built around the Maximo Integration Framework (MIF), a capable but aging stack that traced its roots back to SOAP-based web services and XML data exchange. MAS 9.2 does not discard that foundation, but it builds something fundamentally new on top of it: an integration architecture designed for AI agents, real-time APIs, and event-driven workflows.

The headline feature is the MCP Server, which allows organizations to bring their own AI agents and connect them directly to Maximo Manage APIs. This is not a bolt-on integration. It is a native capability that lets external AI systems participate in operational processes, reading and writing Maximo data through a governed, authenticated channel. Around that, IBM has hardened the REST API surface, expanded OSLC support, and introduced agentic workflows that coordinate decisions across previously siloed enterprise systems.

For integration architects and developers, this release changes the calculus on how to design, build, and maintain connections between Maximo and the rest of the enterprise. The old patterns still work, but the new patterns are significantly more powerful. This article breaks down what MAS 9.2 delivers, how the integration architecture has evolved from the MIF era, and what practical steps you should take to modernize your integration landscape.

The Evolution from MIF to Modern APIs

The Maximo Integration Framework was originally built around XML-based SOAP web services. Organizations would publish channels, define object structures, and expose enterprise services that external systems could consume. The architecture was solid for its time, but it carried significant overhead. Every integration required XML parsing, WSDL management, and often complex XSLT transformations to map between systems. Development cycles were long, testing was laborious, and making changes to an active integration often meant redeploying the entire Maximo application.

With Maximo Application Suite, IBM has embraced a fundamentally different approach. The modern MIF stack now supports multiple integration protocols side by side:

Protocol Format Use Case Maturity

REST API JSON/XML Real-time CRUD operations, mobile apps Primary (MAS-native)

OSLC JSON/RDF Linked data, cross-system resource linking Core (MAS-native)

SOAP Web Services XML Legacy integrations, batch processing Maintained

Flat File / CSV Delimited Bulk data loads, ETL pipelines Maintained

Kafka JSON Event streaming, real-time data pipelines Growing

MCP Server JSON AI agent integration, agentic workflows New in 9.2

JMS Messaging XML/JSON Asynchronous, queue-based processing Maintained

The key architectural change in MAS is that REST and OSLC are no longer bolt-on additions. They are the native integration surface. Every Maximo object, from work orders to assets to purchase orders, is exposed through consistent REST endpoints that follow OpenAPI conventions. The legacy REST API (/maxrest/rest) from the 7.1/7.5 era still exists for backward compatibility, but IBM documentation and community guidance consistently recommend against using it for new development. The modern API surface is not just a different protocol; it is a different design philosophy, one that treats integrations as first-class citizens rather than afterthoughts.

At the heart of MIF lies the concept of object structures. An object structure defines the shape of data that flows through an integration, specifying which Maximo Business Objects (MBOs) are included, their relationships, and which fields are exposed. In MAS 9.2, object structures remain the building block, but they are now accessible through a cleaner REST surface that supports JSON natively, with enhanced querying capabilities including subselects, related object queries, multi-attribute text search, and custom queries via Java and automation scripts.

The authentication model has also evolved significantly. Where earlier versions relied on basic authentication with username and password, MAS requires API keys for all machine-to-machine integrations. API keys are generated through the Administration Work Center and can be scoped, rotated, and revoked independently of user accounts. This aligns Maximo with modern security practices and makes it easier to audit and control integration traffic. Additionally, MAS supports OAuth 2.0 for scenarios where delegating access to third-party applications is required, providing a standards-based authorization framework that integrates with enterprise identity providers.

Another important evolution is the addition of Apache Kafka support for event-driven integrations. In the MIF era, real-time event notifications typically required JMS messaging or polling patterns that introduced latency and complexity. Kafka integration in MAS enables true event streaming, where asset status changes, work order completions, and meter reading updates can be published to Kafka topics and consumed by downstream systems in real time. This is particularly valuable for organizations building operational dashboards, data lakes, or AI pipelines that need to react to Maximo events as they happen.

REST API and OSLC: The Native Integration Surface

The REST API in MAS follows a consistent, predictable pattern. Every resource is accessible through a URL structure that mirrors the object hierarchy. Here is a practical example of querying work orders:

GET /maximo/oslc/os/mxwo?_where=status%3D%22WAPPR%22&_orderby=reportdate%20desc
Headers:
  api-key:
  Accept: application/json

This query retrieves all work orders with a status of "WAPPR" (Waiting Approval), ordered by report date descending. The OSLC query syntax supports complex filtering, pagination, and field selection, allowing clients to retrieve exactly the data they need without over-fetching. The _maxitems parameter controls page size, and the _page parameter enables pagination through large result sets:

GET /maximo/oslc/os/mxwo?_where=status%3D%22WAPPR%22&_maxitems=50&_page=1

For creating or updating records, the API accepts JSON payloads that match the object structure definition:

{
  "siteid": "BEDFORD",
  "assetnum": "PUMP-101",
  "description": "Quarterly inspection of cooling pump",
  "status": "WAPPR",
  "priority": 2,
  "wplabor": [
    {
      "laborcode": "SMITH",
      "laborhrs": 2.5,
      "craft": "MECHANIC"
    },
    {
      "laborcode": "JONES",
      "laborhrs": 1.0,
      "craft": "ELECTRICIAN"
    }
  ],
  "wpmaterial": [
    {
      "itemnum": "FILTER-001",
      "itemqty": 2
    }
  ]
}

This payload creates a work order with associated labor and material plans in a single API call. The nested structure demonstrates how object structures handle related MBOs, allowing complex records to be created atomically rather than through multiple sequential calls.

The REST API and OSLC share the same code base in MAS, which means improvements to one benefit the other. The practical difference is that OSLC follows the Open Services for Lifecycle Collaboration standard, which includes resource linking (RDF-style), discovery, and preview capabilities. OSLC is particularly useful when integrating with other IBM products or third-party tools that implement the OSLC standard, such as IBM Engineering Lifecycle Management tools. For straightforward CRUD operations and data exchange, the REST JSON API is simpler and more widely adopted.

One important distinction for developers: the newer REST API (context path /api) supports API key authentication directly, while the OSLC API (context path /oslc) historically used basic authentication and now also supports API keys. For new integrations, use the /api context path with API key authentication. Reserve OSLC for scenarios where cross-system resource linking is explicitly needed.

The metadata API is another capability that deserves attention. MAS exposes JSON schema metadata for all object structures, which means integration developers can programmatically discover available fields, relationships, and data types. This is invaluable for building dynamic integrations that adapt to configuration changes without code modifications:

GET /maximo/oslc/os/mxwo?_lidata=true

This returns the schema definition for the MXWO object structure, including all included objects, their attributes, and relationship paths. Tools like Postman can import this metadata directly to generate collection skeletons for testing and development. For teams building integration middleware, the metadata API enables automatic schema validation and documentation generation, reducing the manual effort required to keep integration documentation current.

Error handling in the MAS REST API follows standard HTTP status codes with detailed JSON error responses:

{
  "Error": {
    "errorCode": "BMXAA0021E",
    "message": "Value PUMP-999 for assetnum does not exist in the ASSET table.",
    "reasonCode": "OBJECT_NOT_FOUND",
    "statusCode": "400"
  }
}

This structured error format allows integration code to programmatically handle errors, retry when appropriate, and provide meaningful feedback to users or upstream systems. The errorCode maps to Maximo's internal error catalog, while reasonCode provides a categorization that can drive automated retry or escalation logic.

MCP Server: Bringing AI Agents into Maximo Workflows

The Model Context Protocol (MCP) Server is the most significant integration capability introduced in MAS 9.2. It enables organizations to connect external AI agents directly to Maximo Manage APIs, allowing AI to participate in operational processes without manual coordination between disconnected tools.

To understand why this matters, consider the traditional AI integration pattern in enterprise systems. A data scientist builds a predictive model, exports predictions to a file or database, and a Maximo automation script or cron job imports those predictions as meter readings or custom fields. The loop is closed, but it is brittle, latency-prone, and requires custom code at every step. Any change to the model output format, the Maximo configuration, or the data pipeline breaks the integration, and debugging requires expertise across multiple systems.

The MCP Server eliminates that friction. An AI agent can query Maximo for asset data, work order history, and inspection results, analyze that data, and write recommendations or create work orders directly through the Maximo API. All of this happens through a governed, authenticated channel that respects Maximo's security model.

The architecture works as follows:

• MCP Server runs as a component within the MAS cluster, exposing a standard MCP interface that AI agents can connect to.
• AI Agent (external, built by the organization) connects to the MCP Server using standard MCP protocol, authenticating with an API key.
• Maximo Manage APIs are called by the MCP Server on behalf of the agent, using the same REST/OSLC endpoints described above.
• Governance and logging are handled at the MCP Server level, ensuring that all agent actions are auditable and controlled.

This architecture means organizations can build custom AI agents using any framework (LangChain, CrewAI, IBM watsonx, or custom code) and connect them to Maximo without building bespoke integrations for each agent. The MCP Server handles the protocol translation, authentication, and routing.

Practical use cases for MCP-enabled agents include:

• Reliability agents that monitor asset health scores, query work order history, and automatically generate work orders when degradation patterns are detected. For example, an agent could check all pumps in a plant every hour, compare vibration data against historical failure patterns, and create a work order with priority 1 when readings exceed thresholds.
• Procurement agents that track inventory levels against work order demand and generate purchase requisitions when stock falls below calculated thresholds. The agent can factor in lead times, seasonal demand patterns, and current supplier performance data.
• Safety agents that review upcoming work orders for hazard patterns, cross-reference them with historical incident data, and flag high-risk jobs for additional safety review. The agent could append safety precautions to the work order plan and notify the safety officer.
• Scheduling agents that optimize work order assignments based on technician skills, location, availability, and asset criticality. The agent can run what-if scenarios to evaluate different scheduling strategies and recommend the optimal assignment plan.

The key architectural principle is that the MCP Server does not replace the REST API. It sits on top of it. Every action an agent takes flows through the same Maximo APIs that human users and traditional integrations use. This means existing security policies, workflow rules, and data validation all apply equally to AI-driven actions. A work order created by an AI agent goes through the same status change rules, same approval routing, and same field validation as a work order created by a human technician.

Containerization and the OpenShift Architecture

MAS runs on Red Hat OpenShift, and the integration architecture reflects this containerized foundation. Unlike the WebSphere era, where Maximo ran as a monolithic application on a single JVM, MAS is deployed as a suite of containerized microservices. Each application (Manage, Monitor, Health, Predict, Visual Inspection, Mobile) runs in its own container set, with shared services for authentication, routing, and data access.

This architecture has direct implications for integration design:

Service discovery is handled by OpenShift's built-in DNS and service mesh. Internal integrations between MAS applications (for example, Manage sending asset data to Monitor for IoT data correlation) use cluster-internal networking, which is faster and more secure than external API calls. The service mesh also provides automatic retries, circuit breaking, and distributed tracing, which significantly simplifies integration resilience engineering.

Scaling is independent per application. If your integration generates heavy load on the REST API, OpenShift can scale the Manage pods horizontally without affecting Monitor or Mobile. This is a significant improvement over the WebSphere model, where all applications shared the same JVM resources and a spike in integration traffic could degrade UI performance for all users.

API routing is handled by the OpenShift router, which terminates TLS and routes requests to the appropriate service. The router provides built-in rate limiting, circuit breaking, and health checking, which means integration developers get production-grade resilience without custom code.

For organizations building integrations, the practical implication is that you should design for the containerized architecture. Use the external API surface for cross-system integrations, but take advantage of internal service mesh capabilities where available. If you are running custom integration services on the same OpenShift cluster, use the internal service URLs to avoid routing through the external load balancer. This reduces latency, eliminates external network dependencies, and keeps integration traffic within the cluster's security boundary.

The containerized architecture also changes how you handle high availability for integrations. In the WebSphere era, HA typically meant clustering multiple Maximo instances behind a load balancer. In MAS, HA is built into the platform through OpenShift's pod scheduling and replication controllers. Your integrations need to be designed for stateless operation, since any given API call might be handled by a different pod than the previous one. Use the API's pagination and filtering capabilities to design integrations that can be interrupted and resumed without data loss.

Migration Strategies for Legacy Integrations

For organizations moving from Maximo 7.6.x to MAS 9.x, integration migration is often the most complex part of the project. Here is a structured approach based on patterns observed across multiple migrations.

Phase 1: Inventory and Assessment

Catalog every existing integration, including:

• Protocol (SOAP, REST, flat file, JMS, direct database)
• Authentication method (basic auth, Maximo token, LDAP)
• Object structures and enterprise services involved
• Frequency and volume (real-time, batch, event-driven)
• Business criticality and downtime tolerance
• Owner and support team for each integration
• Documentation status (up to date, outdated, missing)

This inventory becomes the foundation for your migration plan. Most organizations find that 60-70% of existing integrations can be migrated with minimal changes, 20-30% require moderate rework (usually authentication or protocol updates), and 5-10% need complete rebuilds. The rebuilds are typically integrations that were built against internal Maximo database tables directly, bypassing MIF entirely, and need to be rearchitected to use proper APIs.

Phase 2: Protocol and Authentication Updates

The most common migration task is updating authentication from basic auth to API keys. In MAS, API keys are required for all machine-to-machine integrations. The API key is passed in the api-key HTTP header:

import requests
import json

class MaximoIntegration: def __init__(self, base_url, api_key): self.base_url = base_url self.session = requests.Session() self.session.headers.update({ "api-key": api_key, "Accept": "application/json", "Content-Type": "application/json" })

def get_work_orders(self, status="WAPPR", max_items=100): """Retrieve work orders filtered by status.""" url = f"{self.base_url}/maximo/oslc/os/mxwo" params = { "_where": f'status="{status}"', "_orderby": "reportdate desc", "_maxitems": max_items } response = self.session.get(url, params=params) response.raise_for_status() return response.json()

def create_work_order(self, payload): """Create a new work order with associated labor and materials.""" url = f"{self.base_url}/maximo/oslc/os/mxwo" response = self.session.post(url, json=payload) if response.status_code == 201: return response.json() else: error = response.json().get("Error", {}) raise Exception(f"Create failed: {error.get('message', 'Unknown error')}")

For SOAP-based integrations, the WSDL endpoints still work in MAS, but the context path may have changed. Test each endpoint against the new MAS instance and update binding configurations as needed. Consider whether SOAP integrations should be rebuilt as REST integrations during the migration, since REST offers better performance, easier debugging, and better tooling support.

Phase 3: Testing and Validation

MAS introduces behavioral changes in how MIF processes certain data types and handles edge cases. Common issues include:

• Date/time handling differences between WebSphere and OpenShift (timezone handling in particular can cause subtle bugs)
• Changes to default field values for newly created records
• Differences in workflow initiation behavior via API vs. UI
• Updated error response formats and HTTP status codes
• Changes to the behavior of automation scripts triggered by integration events

Build a test suite that exercises every integration endpoint with representative data, and validate the responses against expected behavior. Automated testing is strongly recommended, as manual testing of integration suites is time-consuming and error-prone. Tools like Postman collections, Pytest for Python integrations, or JUnit for Java integrations can be automated into CI/CD pipelines.

Phase 4: Cutover and Rollback

Design your cutover plan with rollback capability. Run the old and new integrations in parallel for a defined period, comparing outputs and identifying discrepancies. Use feature flags or configuration switches to control which integration path is active, so you can switch back quickly if issues arise. A typical parallel run period is 2-4 weeks, depending on integration volume and complexity.

Practical Implications

For organizations currently on MAS 8.x or earlier, the 9.2 release is a strong signal to accelerate integration modernization. The MCP Server capability alone justifies upgrading for any organization investing in AI-driven asset management. The REST API maturity in 9.2, combined with the containerized OpenShift architecture, provides an integration surface that is significantly more capable than anything available in the 7.6.x era.

For organizations still on Maximo 7.6.x, the path is longer but the direction is clear. Start by cataloging your integrations and assessing which ones can move to REST/JSON with minimal changes. Begin building new integrations against the REST API even before migrating to MAS, using the REST capabilities available in 7.6.1 and later. When you do migrate, your integration landscape will be partially modernized, reducing the migration effort.

For development teams, the key skills to invest in are REST API design, JSON data modeling, OpenShift container networking, and increasingly, AI agent development. The MCP Server opens a new category of integration that blends traditional API engineering with AI orchestration, and teams that build expertise in both areas will be well positioned for the next wave of Maximo implementations.

Security teams should review the API key management model and establish rotation policies, scoping rules, and monitoring procedures. The MCP Server introduces a new authentication path that needs to be incorporated into security operations, including agent identity management and action auditing. Consider implementing automated alerts for unusual API patterns, such as unexpected bulk reads, off-hours write operations, or repeated authentication failures.

Bottom Line

MAS 9.2 represents the most significant integration architecture update in Maximo's history. The MCP Server brings AI agents into the operational workflow natively, the REST API provides a mature, consistent surface for system-to-system integration, and the containerized OpenShift foundation delivers the scalability and resilience that modern enterprises require. Organizations that invest in modernizing their integration landscape will be positioned to take advantage of AI-driven asset management capabilities that were not possible with previous versions. The migration path is well-defined, the tools are mature, and the business value is clear. The question is not whether to modernize, but how quickly you can get there.