NEWSROOM

Migrating from Maximo 7.6.1.x: 5 Considerations for Life Sciences Teams

A migration plan needs more than a target platform and a date. It needs a defined scope, evidence that the design meets that scope, and named owners for the transition and the system that follows.

Use these five workstreams whether you are evaluating Maximo Application Suite (MAS) or another platform. Begin with the support timeline to establish contractual constraints.

Automated conveyors sorting products in a high-tech factory

What You’ll Take Away

  • Define intended use and the evidence your team needs.
  • Assign owners across data, functional mapping, cutover, and integrations.
  • Establish completion evidence before committing to go-live.

Jump to Section

Who This Is For

Quality should define the requirements and evidence needed for the system’s intended use. IT should establish architecture, integrations, access, and operational responsibilities. Maintenance and Metrology should define the real work, records, exceptions, and training requirements. Each group needs a place in scope decisions before the project estimates its critical path.

1. Define GxP Scope and Assurance Strategy

Begin with intended use and the reasonably foreseeable effect of failure on product quality, patient safety, record integrity, and decisions made from the system. Then select appropriate assurance activities: scripted, unscripted, automated, or a combination. A feature name does not determine risk or testing method.

FDA’s February 2026 Computer Software Assurance guidance addresses medical-device production and quality management system software under 21 CFR Part 820, as amended by the Quality Management System Regulation. Pharmaceutical manufacturers should not describe that guidance as directly governing their Part 211 systems. Quality should document the applicable requirements and any use of the guidance’s principles within the organization’s own quality system. FDA CSA guidance

Supplier evidence can support the assessment when it is relevant, current, and traceable. It does not replace the customer’s assessment of intended use or verification of configuration, data migration, interfaces, access control, and operating procedures.

Document where the system supports regulated records or decisions. Include the process, users, inputs, outputs, dependencies, and reasonably foreseeable failure conditions. Assess the impact before choosing an assurance method.

For example, a report used to support a quality decision needs an assessment of that intended use. Calling it a dashboard does not make it low risk. Similarly, identifying a function as calibration does not, by itself, prescribe one testing method.

Determine how your quality system uses practitioner guidance such as GAMP 5. Agree on deliverables, evidence acceptance, deviation handling, and sign-off responsibilities. The extent of qualification or re-validation must follow that assessment; this guide does not prescribe it from the software brand or hosting model.

Deliverable: an approved intended-use and assurance plan with supplier and customer responsibilities, evidence acceptance criteria, and decision owners.

2. Migrate, Reconcile, and Retain Data

Build a migration object inventory before estimating conversion effort. Include asset records and hierarchies, work and calibration history, results, standards, meters, job plans, roles, audit information, signatures, reports, and document links. Identify attachments and records held outside the main database.

Assign each data class a disposition: migrate, retain elsewhere, or exclude under approved rules. Record the purpose, retention obligation, access method, owner, and evidence needed to demonstrate the disposition worked. Preserve the context needed to interpret a result or decision after migration.

Define acceptance criteria before the first trial load. Reconcile counts and the fields, relationships, units, and historical context that matter. Track failures and exceptions through resolution. Select methods such as field-level checks, transaction testing, sampling, or interface reconciliation based on the questions they need to answer.

If you use the bundled Maximo Archiving with InfoSphere Optim offering, investigate that dependency explicitly. IBM records the withdrawal of the bundled offering, and its migration overview says Maximo Archiving is not supported in MAS. This does not establish that all archiving options are unavailable: separately licensed Optim is a distinct consideration. Confirm licensing, compatibility, retrieval, and retention requirements for the specific design. IBM EOS announcement, IBM migration overview

Plan Legacy Access Alongside License Conditions

For customers with a MAS license obtained by trade-up, IBM describes “dual support”: EAM 7.6.1.x and MAS may run in any combination up to the total MAS entitlements. That arrangement ends April 30, 2027. Once technical migration to Maximo Manage is complete, the customer must discontinue EAM use. Confirm how the agreement applies to your deployment before scheduling coexistence or cutover. IBM dual support statement

Do not make read-only legacy access the default retention strategy without checking those conditions. Establish a permitted and tested retrieval method for records needed after EAM use stops. Any coexistence or parallel operation should have a defined purpose, duration, reconciliation process, and contractual basis.

Deliverable: a data-disposition register, mapping specification, reconciliation evidence, exception log, and tested retrieval plan.

3. Map Maximo Functionality to the Target

Separate required outcomes from local workarounds. For each requirement, identify the target release, proposed design, evidence of capability, commercial scope, configuration work, and customer verification. Keep unresolved fields visible.

Requirement areaWhat the team should prove
CalibrationRequired master data, standards, tolerances, data sheets, readings, as-found/as-left results, traceability, reverse traceability of standards, and the handling of exceptions.
MaintenanceThe agreed planning and execution processes, asset relationships, required records, and review steps.
Records and accessThe required permissions, signature configuration, audit information, attachments, retrieval, and historical context.
Local processesThe reports, applications, scheduled processes, scripts, escalations, and approvals in your inventory.
Supplier documentationThe deliverables actually offered, their scope and currency, and their relevance to your intended use.

This is an evaluation checklist, not a claim that every item is included in either product. A demonstration of one part of a process does not establish the entire process. In particular, evaluate exception detection and the subsequent routing, review, approval, and escalation requirements separately.

Use representative transactions and exception cases in demonstrations and acceptance work. Do not retire a required control merely because it was implemented as a customization in the old system. Equally, do not reproduce every workaround without checking the underlying requirement.

Deliverable: a requirement-to-design-and-evidence map, with configuration decisions and unresolved items assigned to owners.

4. Plan Cutover, Continuity, Training, and Stabilization

Specify freeze windows, the final data-load sequence, go-live acceptance criteria, and sign-off authority. Identify the work orders, calibrations, and reviews that may fall due during the transition and how those activities will be captured and reconciled.

Write the rollback plan before the cutover rehearsal. Define the triggers, decision maker, last controlled recovery point, and treatment of transactions created during the attempted cutover. Test the assumptions the organization relies on to resume operation.

Train by role using the approved processes. Technicians, planners, Metrology, Quality, and administrators need different tasks and evidence of readiness. Update operating procedures and access assignments alongside training.

Set a stabilization period with named owners, escalation routes, issue priorities, and exit criteria. Go-live and stable operation are distinct project milestones; define both.

Deliverable: an approved cutover and continuity plan, rehearsal results, training records, rollback criteria, and stabilization ownership.

5. Verify Integrations and Define Lifecycle Ownership

  • If you use RMI: IBM states that RMI is not supported in MAS and identifies REST as the replacement for custom extensions and external applications. Inventory the affected integrations and plan their redesign and verification.
  • If you use Service Integration buses: IBM states that these clients “must migrate to Apache Kafka or another supported JMS provider.” Identify the affected messaging flows and establish the target provider, configuration, and acceptance criteria.

These requirements apply to the named integration patterns. They do not establish that every Maximo migration requires integration redevelopment. IBM migration overview

An environment already using REST and a supported messaging provider does not acquire those specific redevelopment requirements simply because it moves to MAS. Other interfaces, configurations, and dependencies still need assessment.

For each interface, record its data contract, authentication, transformation rules, error handling, retries, reconciliation, owner, and recovery procedure. Verify representative normal and failure scenarios against agreed acceptance criteria. Do not infer unchanged behavior for custom applications or automation from a general migration statement.

For customer-managed MAS 9.2, define who operates OpenShift and confirm entitlement for the cores used. Bundled Red Hat rights apply only in support of MAS and while IBM Subscription and Support is in effect; Reserved entitlements are excluded.

For a hosted proposal, obtain the service’s own responsibility model and commercial terms. Identify who monitors, investigates incidents, restores data, approves changes, provides evidence, and communicates releases. Then assign the customer’s operational and quality responsibilities explicitly.

Deliverable: an integration verification record and a responsibility matrix covering the platform’s operation, support, changes, and periodic review.

Where Blue Mountain RAM May Fit

If RAM is on your shortlist, bring this inventory and these requirements to Blue Mountain. Ask for a demonstration, a written delivery scope, and the evidence your Quality and IT teams need to evaluate the proposal. Apply the same questions to the IBM path and other candidates.

The Five Workstreams at a Glance

WorkstreamCompletion evidence
GxP scope and assuranceApproved intended use, assessment, methods, evidence criteria, and owners.
Data and recordsApproved disposition, mappings, reconciliation, exception closure, and retrieval evidence.
Functional mappingRequirements traced to design, demonstration, commercial scope, and acceptance evidence.
Cutover and adoptionRehearsal, acceptance and rollback criteria, continuity arrangements, training, and stabilization ownership.
Integrations and lifecycleVerified interfaces, operational ownership, incident responsibilities, and change review.

Plan Your Next Step

Assign owners and record evidence across the five workstreams. Explore the Post-EOS Migration Guide for additional migration planning context.

This material is a planning framework, not legal or regulatory advice, an IBM entitlement determination, or a guarantee of compliance. Confirm contractual terms with IBM or the relevant supplier and approve the assurance approach through your quality system.