This is the point in the series where the new MAS 9 environment meets the Maximo 7.6 system that contains your operational history.

The good news is that IBM’s supported path is a database upgrade, not a conventional data migration.

Manage connects to a copy of the existing Maximo database and upgrades its schema in place. Data is not exported, transformed, mapped, or reloaded. Data, configurations, workflows, automation scripts, BIRT reports, escalations, saved queries, and start centers remain in the database and come across with it.

That does not make the work effortless; it makes preparation more important. This article covers:

• Choosing the migration path – direct database upgrade versus a fresh start with selective migration
• Preparing the 7.6 database – the integrity checks that prevent mid-upgrade failures
• Packaging customizations – what carries over automatically and what needs the customization archive
• Running the upgrade – configuring Manage activation against your existing database
• Post-upgrade validation and cutover – users, attachments, reports, integrations, the smoke test, and the production cutover

Choose the Migration Path

There are two legitimate approaches.

Path A: Direct database upgrade. Point the Manage activation at a copy of the 7.6 database. The process upgrades the schema and brings over the data, history, configurations, and customizations. This is IBM’s supported upgrade path and will suit most organizations with a functioning 7.6 environment.

Path B: Fresh install with selective migration. Activate Manage against a new database, then bring over only the data and configuration you choose. Migration Manager can handle configurations; the integration framework or tools such as MxLoader can handle data. This takes more work—often weeks to months—but can be appropriate for a heavily customized or troubled environment where leaving old, unused material behind is worth the effort.

Consideration	Path A: Direct Upgrade	Path B: Fresh Start
Effort	Days to weeks	Weeks to months
History	Complete work order and asset history preserved	Only selected history is brought over
Unused legacy material	Carried over with the database	Left behind by design
Old customizations	Carry over, then retest	Rebuild or consciously retire
Risk	Concentrated in one upgrade event	Spread across many smaller moves
Best fit	Most organizations with a functioning 7.6	Heavily customized or troubled environments

For most teams, use the direct upgrade unless the existing environment has extensive abandoned customizations, unfinished integrations, or serious data-quality problems. A technical upgrade followed by improvement is usually less risky than combining both projects. The rest of this article follows Path A; much of the preparation also applies to Path B.

Prerequisites

Before you begin, confirm the following:

• The MAS 9 environment is healthy. The cluster and MAS Core should be running, and SMTP should be configured. If Manage was already activated against an empty database, plan to deactivate and reactivate it against the 7.6 copy, or use a workspace where Manage has not yet been activated.
• Maximo is at a supported version. The source must be Maximo 7.6.0.10, 7.6.1.2, or 7.6.1.3 for the direct upgrade described here. Apply the required fix pack first if it is older. IBM Control Desk follows a Maximo IT path with its own requirements.
• You have a restored copy of the production database. The first upgrade must be a rehearsal against a copy, not production.
• You have the 7.6 maximo.properties crypto values: mxe.security.crypto.key and mxe.security.cryptox.key. Without them, encrypted properties in the database cannot be decrypted.
• You have an inventory of Java classes, database scripts, modified deployment descriptors, XSL files, and other customizations.
• You have a web server that the cluster can reach. Manage downloads the customization archive over HTTP or HTTPS.

Step 1: Build your Data Inventory

Most of what matters lives in the database. The table below sets out how each category migrates: most items come across with the database, while a few sit outside it and need deliberate handling.

Item	How it migrates
Data (assets, work orders, history)	In the database. Comes over automatically.
Configurations, screens, workflows	In the database. Comes over automatically.
Automation scripts	In the database. Come over automatically.
BIRT reports	In the database. Come over automatically.
Java class customizations	Customization archive (Step 3). Retest each customization.
LDAP / VMMSYNC / LDAPSYNC setup	Does not migrate. Identity is handled at the MAS level (Part 5).
Attachments (doclinks)	Files must be moved; paths must be updated (Step 5).
System properties with URLs/paths	Migrate, but URLs and paths may still point to the old environment. Update post-upgrade.
Integration endpoints	Migrate, but external systems need new URLs, network access, and testing.
Industry solutions / add-ons	Must be selected during activation to match the 7.6 installation.

Two items deserve a closer look. First, add-ons: Scheduler, Linear, Calibration, and Mobile are included capabilities in MAS 9, so verify the current licensing and bundling for your MAS version before assuming an add-on must be purchased. Second, Java customizations: they are supported through the archive, but each one increases the work required for later updates. Identify candidates for conversion to automation scripts, even if that work is deferred.

Reality Check

If an inventory item cannot be explained, do not quietly remove it. Document it, carry it over during the rehearsal, and schedule its retirement once the dependent business process is understood.

Step 2: Prepare the 7.6 Database

The activation process can fail partway through if the source database has unresolved configuration or integrity problems. Run these checks on 7.6, in order.

Clear Pending Configuration Changes

Apply or discard pending database configuration changes before the upgrade. Both queries should return zero:

SELECT count(*) FROM maxobjectcfg WHERE changed != ‘N’; SELECT count(*) FROM maxsysindexes WHERE changed != ‘N’;

If either query returns a nonzero value, use Database Configuration in 7.6—admin mode and configdb—until the pending changes are resolved.

Run the Integrity Checker

Run the integrity checker from the 7.6 administrative workstation:

rem On the 7.6 administrative workstation cd install_home\maximo\tools\maximo integrityui.bat

• Start in Report mode with Repair Mode unchecked, and review the log it writes to the tools log directory.
• If it reports errors, run it again in Repair mode and then run configdb.
• Repeat the report/repair cycle until the report is clean. Do not carry known integrity errors into the upgrade.

Disable Custom Database Machinery

Disable customer-created database triggers, stored procedures, and views before the upgrade. The schema changes can cause old triggers to fire at the wrong time. Re-enable and retest each item individually after the upgrade.

Back Up and Create the Rehearsal Copy

Take a full production backup, then restore a copy to the SQL Server, Db2, or Oracle instance reachable by the MAS cluster. Upgrade this copy first, not production. Keep production running untouched while you rehearse.

The Copy Rule

The first time MAS touches your Maximo database, it must be a disposable copy. The schema upgrade is one-way: there is no downgrade script, only your backup. Rehearse on a copy, time it, record every prompt and decision, and only then schedule production.

Step 3: Package Customizations

Java customizations move to MAS in a customization archive, a ZIP that mirrors the relevant folder structure of the old SMP directory. During activation, Manage downloads it and builds it into the application images, replacing the role that rebuilding maximo.ear played in the WebSphere deployment.

The archive should include, in the proper package hierarchy:

• Custom Java class files in the same businessobjects/classes-style paths used in SMP
• Customer database scripts driven by a_customer.xml
• Modified web.xml, ejb-jar.xml, or webservices.xml, but only when you actually changed them
• XSL customizations and other custom resources

Zip the archive and host it on a web server the cluster can reach over HTTP or HTTPS; use an appropriately secured hosting method for production, and confirm the cluster itself can retrieve the URL, not just the bastion host. For a development rehearsal, this is enough:

# Quick-and-dirty archive hosting for a dev rehearsal (bastion host) cd /opt/ibm/mas9/customizations zip -r manage-customization-archive.zip businessobjects/ maximouiweb/ tools/ python3 -m http.server 8080 # Archive URL: http://[bastion-ip]:8080/manage-customization-archive.zip

web.xml Warning

Do not place the old 7.6 web.xml directly in the archive; the Manage version differs. IBM’s guidance is to deploy once without the customization, extract the new web.xml, reapply your changes to that version, and then include it in the archive.

Step 4: Configure Manage and Run the Upgrade

This resembles the Manage activation from Part 5, with three differences: the database you point at, the encryption keys, and the customization archive.

The Database Configuration

Create the JDBC configuration as in Part 5, but point it at the restored 7.6 database copy. Then, in the Manage deployment configuration:

• Deselect “System managed” in the database section; you are supplying an existing schema.
• Specify the schema, tablespace, and index space used by 7.6, rather than the values a fresh installation would create.
• Provide the old encryption keys – set MXE_SECURITY_OLD_CRYPTO_KEY and MXE_SECURITY_OLD_CRYPTOX_KEY to the values of mxe.security.crypto.key and mxe.security.cryptox.key from the old maximo.properties. Manage must decrypt existing values before it can re-encrypt them with new keys.

Components and the Archive

In the same configuration screen, provide the customization archive URL and select the components and industry solutions that match the 7.6 installation. The upgrade runs update scripts for the selected components; omitting one that exists in the database can produce a failed or inconsistent upgrade.

Activate and Watch

Activate Manage and monitor the workload:

# Watch the activation do its work oc get pods -n mas-sno-manage -w oc logs -f -n mas-sno-manage -l mas.ibm.com/appType=maxinstPod

Duration depends on database size and the number of releases crossed. A small database may finish within two hours; a large database with years of history may take considerably longer, which is why the rehearsal on a copy gives you a defensible estimate. If the upgrade fails, the logs should identify the script or object involved; pending configuration changes, custom triggers, and integrity errors are the common causes.

Step 5: Validate Before Inviting Users

The pipeline completing is not the end of the work. Complete these checks before any user signs in.

Check Integrity Again

Run the integrity checker from within Manage after the upgrade and confirm it is clean. This is evidence that the upgraded schema is coherent.

Validate Users and Authentication

Authentication now belongs to MAS rather than application-server security. The upgrade creates corresponding MAS entries for existing Maximo users, and MAS pushes users and groups into Manage. Three consequences follow:

• Retire the old VMMSYNC and LDAPSYNC cron tasks; directory synchronization is configured at the MAS level, using the identity provider from Part 5.
• Every migrated user needs a Base, Premium, or Self-Service entitlement, and entitlements consume AppPoints. Dormant accounts can therefore become a licensing issue, so clean them up before go-live or at least understand the numbers.
• Manage security groups and authorizations should remain intact; the change is how users reach the login screen, not what they can do after signing in.

Move Attachments

Doclinks previously pointed to a file system visible to WebSphere; your Manage pods cannot see it. Move the files to storage mounted by the cluster, such as a persistent volume, or to object storage. Update mxe.doclink.path01 and related properties to the new location, then test downloads and uploads.

Review Properties, Reports, and Integrations

• System properties – review them for URLs and paths that still reference the old environment; mxe.oslc.webappurl and related properties should point to the new Manage URL.
• BIRT reports – they come over with the database. Run the five most-used reports and check output, fonts, and logos.
• Integrations – publish channels, enterprise services, and endpoints migrate as configuration, but external callers need the new URL, and outbound endpoints need network access from the pods, not merely from the bastion. Test every interface end to end.

Run a Business Smoke Test

Using copied data, work through the inventory from Step 1: create and approve a work order, issue parts against it, close it, generate a PM, enter time, and exercise every customization on the list. Include two or three actual end users; they often find problems quickly and can become useful go-live advocates.

Production Cutover

Once the rehearsal upgrade validates cleanly, cutover is a controlled runbook:

• Freeze 7.6 configuration and data entry, and disable cron tasks and integrations.
• Take the final production backup and restore it to the MAS-reachable database server.
• Run the upgrade using the rehearsal notes.
• Execute the essential validation checks and business smoke tests.
• Repoint DNS, bookmarks, mobile apps, and integrations at the new environment.
• Keep 7.6 read-only for an agreed fallback window, as the rollback plan and the reference system.

Rollback Honesty

Be explicit with stakeholders about what rollback means: returning to 7.6 with the pre-cutover backup, and losing anything entered into MAS since the cutover. That is why the validation window before opening the doors matters.

Final Checklist

• Maximo is at 7.6.0.10, 7.6.1.2, or 7.6.1.3, with a full production backup taken
• Pending-configuration queries return zero
• Integrity checker clean in Report mode on the source database
• Custom triggers, procedures, and views disabled and documented
• Customization inventory complete; archive built, hosted, and reachable from the cluster
• Old crypto keys (mxe.security.crypto.key / cryptox) available and mapped correctly
• Rehearsal upgrade completed on a database copy, with timing and notes recorded
• Activation selections match the 7.6 components and industry solutions
• Post-upgrade integrity clean; users synced and entitled; AppPoints impact understood
• Attachments moved and doclink paths updated
• Key reports and every integration tested end to end
• Real users sign off on core business flows
• Cutover runbook written, including the rollback plan and fallback window

Conclusion

The supported database-upgrade path keeps the valuable part of 7.6 which is the data, history, workflows, and configuration all while moving Manage into a containerized, operator-managed MAS environment.

The upgrade command is only one part of the project. The inventory, the database cleanup, the rehearsal, the customization packaging, the validation, and the cutover plan are what make it reliable.

The next part of the series covers day-to-day administration of Maximo Manage, including admin mode, database configuration, server bundles, logging, and the settings new MAS administrators usually need.

The old 7.6 servers can be retired once the agreed fallback window closes.

Resources

• IBM: Migrating from Maximo Asset Management to Maximo Manage (PDF): https://www.ibm.com/docs/en/SSRHPA_cd/pdf/migrating-pdf.pdf
• IBM: Upgrading from Maximo Asset Management to Maximo Manage: https://www.ibm.com/docs/en/masv-and-l/cd?topic=upgrading-from-maximo-asset-management-maximo-manage
• IBM MAS documentation: https://www.ibm.com/docs/en/mas
• Maximo Manage FAQ: https://ibm-mas-manage.github.io/faq/

Next in the series: Part 7, Administering Maximo Manage Day to Day.