The migration from Maximo 7.6 to the IBM Maximo Application Suite (MAS) represents both a significant technical undertaking and a strategic opportunity. Organizations that plan and execute this migration well emerge with a modernized, cloud-native CMMS/EAM platform that is easier to upgrade, more capable on mobile devices, and ready for AI-powered predictive maintenance capabilities. Those that underestimate the complexity face extended timelines, budget overruns, and adoption challenges. This guide provides the framework for a successful migration.
MAS Deployment Options
The first strategic decision in a MAS migration is where to run OpenShift, the Kubernetes platform that MAS requires. Four deployment options are available, each with different cost structures, operational characteristics, and organizational implications.
IBM Cloud (ROKS — Red Hat OpenShift on IBM Cloud): IBM’s managed cloud option, where IBM manages the OpenShift infrastructure while the customer manages MAS application configuration. This option has the lowest infrastructure management overhead and the clearest upgrade path, as IBM handles OCP version upgrades. It is the most suitable option for organizations without existing OpenShift or Kubernetes expertise.
AWS (via Red Hat OpenShift Service on AWS or self-managed OCP on EC2): AWS provides flexible pricing models including reserved instances and spot workers for non-critical workloads. Organizations already using AWS services benefit from the ability to integrate MAS with existing AWS data stores, messaging services, and analytics platforms.
Azure (via Azure Red Hat OpenShift or self-managed OCP on VMs): similar to AWS but preferred by organizations standardized on Microsoft Azure. Azure Active Directory integration with RHSSO/Keycloak is straightforward in this environment.
On-premise OCP: running OpenShift on bare-metal servers or VMware in the organization’s own data center. This option provides the highest degree of control and may be required for data sovereignty, classified data, or air-gapped network requirements. It also requires the most operational expertise, as the organization manages OCP upgrades, storage provisioning, and cluster health monitoring.
Hardware sizing guidance: IBM publishes minimum and recommended hardware specifications for MAS deployments. At minimum, a production MAS Manage deployment requires 48 cores, 192 GB RAM, and approximately 1 TB of storage across the OCP worker nodes. Larger deployments with Monitor, Health, and Predict add-ons require proportionally more resources. These requirements are substantially higher than a typical Maximo 7.6 WebSphere deployment, making a thorough understanding of the MAS application suite components essential before infrastructure sizing begins.
Assessment Phase: Know Before You Migrate
The assessment phase is the highest-return-on-investment activity in any MAS migration. Organizations that skip or rush this phase inevitably discover complexity mid-migration that causes schedule delays and budget increases.
Customization audit: catalog every customization in the Maximo 7.6 environment. The categories to evaluate are: Java class customizations (PSDI class extensions, custom business rules in Java), application designer changes (custom application layouts, new fields added to standard applications), database additions (custom tables, custom columns), automation scripts (if already adopted in 7.6, these migrate cleanly to MAS), and workflow configurations.
For each Java class customization, assess: Does this customization address a business requirement that MAS Manage now handles natively? (Many 7.6 customizations were workarounds for functionality that is now standard in MAS.) Can it be replaced by an Automation Script? Is it still needed at all?
Integration inventory: document every inbound and outbound integration connected to Maximo 7.6. For each integration, record the interface mechanism (MIF Publish Channel, Enterprise Service, SOAP web service, direct database query), the external system, the data flow direction, the volume, and the criticality. Direct database queries against the Maximo database from external systems must be migrated to MIF or REST API before going to MAS — direct DB access is not supported in a containerized architecture.
Data volume assessment: measure the size of the Maximo 7.6 database, including work order history, asset history, and audit logs. Large databases (>1 TB) require careful data migration planning. Organizations with 15+ years of Maximo history may consider archiving historical data before migration rather than migrating everything, reducing migration time and MAS storage costs.
License assessment: review current Maximo 7.6 license types (limited, base, premium) and estimate the equivalent MAS AppPoints consumption. This frequently reveals licensing surprises — some organizations discover that their MAS subscription cost will increase due to the consumption model, while others find it decreases because the AppPoints model allocates resources more efficiently across their user mix.
Data Migration Strategy and Tools
Data migration is the most technically complex phase of a MAS migration. The Maximo database schema in MAS Manage is largely compatible with Maximo 7.6, but there are schema differences, technology stack changes (if moving between database platforms), and data quality issues to address.
IBM Maximo Application Suite Data Manager: IBM provides a set of data migration tools specifically for Maximo-to-MAS migrations. The Data Manager includes schema comparison utilities, data validation scripts, and migration execution tools that handle the technical translation between 7.6 and MAS data formats. These tools are the recommended approach over custom ETL development.
Database platform migration: if the migration also involves changing database platforms (from Oracle to Db2, for example), an additional database migration step is required before or during the MAS data migration. IBM supports Db2 and Oracle as production databases for MAS.
Staged data migration: rather than migrating all historical data, many organizations adopt a staged approach: migrate master data (assets, locations, item master, vendors, contracts) first, then operational data (open work orders, active PMs, open purchase orders), then historical work orders from the past 2-5 years, then archive the older history in a separate read-only system.
Data quality remediation: the data migration process almost always surfaces data quality issues that have accumulated in the Maximo 7.6 database over years: duplicate asset records, orphaned work orders referencing deleted assets, inventory records with negative balances, and classification structures with inconsistent hierarchies. These issues must be resolved before migration or they will corrupt the MAS data model.
Customization Migration: From Java to Automation Scripts
The migration of Java class customizations to MAS is the aspect of migration that most frequently surprises organizations with hidden complexity.
Maximo 7.6 allows deep platform customization through Java class extensions: extending IBM’s PSDI business classes to add custom business logic, validation rules, and field calculations. This capability gave organizations tremendous flexibility but created a coupling to specific Maximo API versions that makes upgrading the platform difficult.
MAS deprecates Java class customization in favor of Automation Scripts — server-side scripts written in JavaScript or Jython that run within the MAS application server using a published, version-stable scripting API. Automation Scripts can implement the same business logic as Java class customizations but without the binary compatibility requirements that make Java customizations fragile across versions.
The migration approach for each Java customization is:
Step 1 — Understand the intent: read the existing Java code and document what business requirement it addresses. Never migrate code without understanding its purpose.
Step 2 — Check for native functionality: review whether MAS Manage now provides the required functionality natively. Many 7.6 Java customizations were workarounds for missing features. If MAS handles it natively, the customization can be retired.
Step 3 — Reimplement in Automation Script: for customizations that still serve a valid business need, reimplement the logic in JavaScript or Jython using the MAS Automation Script API. Test against the same scenarios as the original Java code.
Step 4 — Integration testing: verify that the Automation Script implementation produces identical outcomes to the Java implementation across all edge cases, including error conditions and boundary values.
The Maximo Integration Framework also requires review during migration. HTTP end points referencing external systems need to be updated if the external system URLs have changed. JMS queue configurations need to be recreated in the new messaging infrastructure.
Testing Strategy
A rigorous testing program is essential for a MAS migration. The testing pyramid for a Maximo migration consists of:
Unit testing: testing individual Automation Scripts and workflows in isolation against a MAS development environment loaded with representative test data. Each script should be tested against the business rules it enforces, including both positive cases (valid input produces expected result) and negative cases (invalid input produces the correct error).
System integration testing (SIT): testing end-to-end process scenarios in a MAS environment connected to test instances of integrated external systems. SIT validates that the full integration chain works: a work order completed in MAS correctly posts costs to SAP, a PO approved in MAS correctly transmits to the procurement platform, a sensor alert from the IoT platform correctly generates a work order in MAS.
User acceptance testing (UAT): real Maximo users — maintenance planners, supervisors, buyers, technicians — test the MAS application using the new interface against representative scenarios from their actual workload. UAT is the primary mechanism for identifying usability issues with the MAS UI compared to the familiar Maximo 7.6 interface.
Performance testing: load testing the MAS environment under expected peak concurrent user counts and transaction volumes. MAS on OpenShift can scale horizontally, but the scaling configuration needs to be validated before production go-live to avoid performance degradation during peak periods.
Data validation testing: comparing record counts, field values, and data relationships in the migrated MAS database against the source Maximo 7.6 database. Automated data comparison scripts should verify that no records were lost or corrupted during migration.
Go-Live Cutover and Rollback Planning
The cutover from Maximo 7.6 to MAS production is the highest-risk moment of the migration. A well-planned cutover sequence minimizes risk and reduces the time that both systems are in a transitional state.
Pre-cutover checklist (completed in the final days before cutover weekend):
- All critical integrations tested and verified in MAS production environment
- All user accounts created and security groups configured
- All Automation Scripts deployed and validated
- Help desk briefed on common MAS UI questions
- Hypercare support team scheduled for the first two weeks post-go-live
- Rollback procedure documented, tested, and distributed to the technical team
Cutover sequence (typically executed over a weekend to minimize business impact):
- Freeze all transactions in Maximo 7.6 (announce transaction freeze to all users)
- Run final delta data migration to capture changes since the last full migration
- Execute data validation scripts to confirm migration completeness
- Switch DNS and application URLs from Maximo 7.6 to MAS
- Validate MAS production functionality with a smoke test script (10-15 critical scenarios)
- Announce go-live to users
Rollback plan: the rollback trigger condition should be defined before cutover begins. If the smoke test fails on more than N critical scenarios within the first X hours of go-live, the team rolls back to Maximo 7.6. The rollback procedure includes switching DNS back to the 7.6 environment and communicating the delay to users. Having a clean rollback option provides the confidence to proceed with cutover even when some non-critical issues remain open.
Post-Migration Validation
The first 30 days post-migration are the highest-risk period for discovering issues that were not caught in testing. Establishing a structured post-migration validation program catches and resolves these issues before they affect business operations.
Hypercare support: a dedicated technical support team available for immediate escalation during the first two weeks. This team should include MAS technical experts (not just the regular help desk), and should have a direct escalation path to IBM support for platform-level issues.
Daily operational validation: for the first two weeks, run a daily check of: work orders created and processed (volume consistent with pre-migration baseline?), integrations transmitting successfully (no error queues accumulating?), scheduled processes running (PM generation, reorder generation, report distribution?).
Performance monitoring: OpenShift provides native monitoring through Prometheus and Grafana. Monitor application response times, JVM memory usage, database query latency, and pod resource utilization during the post-migration period. Early identification of performance issues — before they affect users — is much easier to resolve than reactive troubleshooting after users have reported slowness.
For organizations that have adopted MAS Monitor and Predict as part of their migration strategy, the post-migration period also involves training the AI models on historical maintenance data from the migrated work order history — a process that takes 4-8 weeks to produce actionable failure predictions on new equipment.
The successful completion of a Maximo to MAS migration positions the organization to take full advantage of IBM’s ongoing investment in the MAS platform, including regular monthly updates with new features, the expanding AI capabilities in Health and Predict, and the growing ecosystem of pre-built integrations in App Connect. The Industrie du Futur initiative documents how leading manufacturers are using cloud EAM platforms to accelerate their digital transformation programs.