Maximo Mobile 9.1 and MX-Edge: The Offline-First Restructure That Changes Field Workflow Economics

In June 2026, two changes hit Maximo Mobile that, taken together, change the economics of field service deployments more than anything since the original Mobile rewrite. The first is the official launch of MX-Edge, IBM's offline-first mobile platform that is now generally available as a MAS 9.1 managed capability. The second is the meter reading restructure in Maximo Mobile 9.1, which moves meter data from a work-order-attached model to an asset-and-location-attached model with a single source of truth. Together, these changes shift field teams from "sync when you can" to "work when you must, sync when you can." That distinction is not semantic. It is the difference between a 6-hour daily route and a 4-hour daily route, between a 12% rework rate and a 2% rework rate, and between a field service operation that scales linearly with crew size and one that scales sublinearly.

This article walks the architecture and field-tested patterns for both changes. The article assumes Maximo Mobile 9.1.x deployed with the standard MAS 9.1 managed topology, with field users on iOS 17+ or Android 13+ devices, and with intermittent or no connectivity in 30-60% of the service area.

MX-Edge: What It Actually Is

MX-Edge is not a new application. It is an offline-first data architecture that the Maximo Mobile 9.1 client uses to maintain a local, queryable replica of the work, asset, location, and meter data the field technician needs to complete a route. The replica is synchronized bidirectionally with the Maximo Manage backend using a delta-sync protocol that runs over HTTPS, mTLS-secured by default, and that handles the conflict resolution rules that the application defines.

The architecture has three components that matter operationally. The local data store is a SQLite database on the mobile device, encrypted at rest using the iOS Data Protection or Android EncryptedFile APIs. The sync engine is a background process that runs when connectivity is available, processes the outbound delta queue, and pulls the inbound delta from the backend. The conflict resolution layer applies site-defined rules (typically last-writer-wins for status fields, merge for collection fields, and human-review for meter readings and signatures).

The economic impact comes from the elimination of the "connectivity tax." In the pre-MX-Edge architecture, every work order transition (start, pause, complete) required a round-trip to the Maximo Manage backend. In a coverage hole, the technician could not start a work order, could not record labor, could not record a meter reading, and could not close out a work order. The technician was effectively offline and unproductive until coverage returned. In an area with 30-60% coverage holes, the lost productivity was 30-60% of route time.

With MX-Edge, the technician works against the local replica. Transitions are recorded locally and queued for sync. When connectivity returns, the sync engine drains the queue. The technician's productivity in coverage holes is now 90-100% of normal, limited only by data that is not yet replicated to the local store (e.g., a newly created work order that the backend has not yet pushed).

# Maximo Mobile 9.1 configuration for MX-Edge
# maximo.mobile.edge.properties (deployed via manage Custom Resource)
mxe.mobile.edge.enabled=true
mxe.mobile.edge.replication.workorder=true
mxe.mobile.edge.replication.asset=true
mxe.mobile.edge.replication.location=true
mxe.mobile.edge.replication.meter=true
mxe.mobile.edge.replication.sr=true
mxe.mobile.edge.conflict.workorder.status=lww
mxe.mobile.edge.conflict.meter.actual=human-review
mxe.mobile.edge.conflict.attachment=lww
mxe.mobile.edge.sync.batchsize=200
mxe.mobile.edge.sync.idleinterval=30
mxe.mobile.edge.sync.forceretry=300

The configuration fragment above is a representative subset of the MX-Edge settings. The replication.* flags determine which business objects are replicated to the local store. The conflict.* flags determine how conflicts are resolved when the same record is modified on the device and on the backend. The sync.* flags control the batch size, the idle interval between sync attempts, and the forced retry interval when sync has been failing.

The 9.1 Meter Reading Restructure: Why It Matters

The 9.1 meter reading restructure is a quieter change than MX-Edge but it has equal or greater operational impact. In Maximo Mobile 8.x and 9.0.x, meter readings were recorded against the work order. The technician would open a work order, navigate to the meter section, enter the reading, and submit. The meter reading was stored as a child of the work order, which meant that a single asset with multiple work orders over time could have multiple meter records that needed to be reconciled in the asset history.

In Maximo Mobile 9.1, meter readings are recorded against the asset or location, with the work order acting as the transaction that authorized the reading. The asset's meter history is now a single source of truth. The work order still references the meter reading (for labor and cost accounting), but the reading itself lives on the asset. The implication for reliability and PM generation is significant: PMs that are meter-based now have a single, consistent meter history to draw from. PMs that were meter-based but worked against a fragmented history in pre-9.1 deployments will start generating work orders at the correct frequency immediately after the upgrade.

The architecture change is small in code but large in workflow. The meter's LASTREADING, LASTREADINGDATE, and LASTREADINGBY fields are now on the asset, not on the work order. The meter's reading history is a child collection of the asset. The work order records the reading as a transaction reference. PM generation reads from the asset's meter history directly.

// Maximo Mobile 9.1 - Asset-level meter reading (JavaScript automation script)
// Triggered when a meter reading is submitted on the Technician app
// Replaces the work-order-level meter recording pattern

importPackage(Packages.psdi.server);
importPackage(Packages.psdi.mbo);

var assetMbo = meterMbo.getOwner();  // assetMbo is now an Asset, not a WorkOrder
var currentReading = meterMbo.getDouble("READING");
var lastReading = assetMbo.getDouble("METERLASTREADING");
var rollover = assetMbo.getBoolean("METERRESETATZERO");

if (rollover && currentReading < lastReading) {
    // Handle rollover: new reading = (10^precision) + currentReading - lastReading
    var precision = assetMbo.getInt("METERROLLOVERPRECISION");
    var newReading = Math.pow(10, precision) + currentReading - lastReading;
    meterMbo.setValue("READING", newReading);
}

// Update asset-level meter history (single source of truth)
assetMbo.setValue("METERLASTREADING", currentReading);
assetMbo.setValue("METERLASTREADINGDATE", mxServer.getDate());
assetMbo.setValue("METERLASTREADINGBY", userInfo.getUserName());

// PM generation trigger
var pmCron = mxServer.getMboSet("CRONTASKINSTANCE", "PMWGEN");
pmCron.setWhere("crontaskname = 'PMWGEN' and instancename = 'PMWGEN-PROD'");
pmCron.reset();
// Insert manual trigger here in production

The JavaScript above is the asset-level meter recording pattern that replaces the work-order-level pattern from Maximo Mobile 8.x. The rollover handling is the part that bites teams most often. When a meter's METERRESETATZERO flag is true and the new reading is numerically smaller than the last reading, the meter has rolled over and the new reading needs to be adjusted by adding the rollover precision (10 to the power of the meter's decimal precision). The pre-9.1 pattern handled this in the work order's automation script; the 9.1 pattern handles it in the asset's automation script, which means the rollover logic now runs once per reading rather than once per work order.

Field-Tested Patterns: Site Connectivity and Sync Strategy

The connectivity profile of a field service site is the single largest determinant of the MX-Edge configuration. The four patterns that cover most production sites:

Pattern 1: Urban coverage (95%+ connectivity). The default MX-Edge configuration works as-shipped. The sync engine runs in the background, drains the outbound queue, and pulls the inbound delta within seconds. The local store is small (the most recent 30 days of work orders for the technician's crew) and the sync payload is correspondingly small. The device memory pressure is minimal; an iPhone 14 or Pixel 7 with 128 GB of storage can hold the local store plus the OS plus the application plus the standard mobile data footprint with comfortable headroom. The battery impact of continuous background sync is the operational consideration that matters here: the sync engine should be configured to use wifi-only when the device is on battery and the battery is below 50%, and to throttle the sync interval to 5 minutes when the device is in low-power mode.

Pattern 2: Suburban coverage (60-90% connectivity). The local store needs to be larger (90-180 days of work orders) to handle multi-hour coverage gaps. The mxe.mobile.edge.replication.window parameter should be extended. The conflict resolution rules should bias toward device-side writes because the technician is more likely to be the source of truth in this connectivity profile. The operational pattern is that technicians will sync opportunistically: at the start of the day in the depot (Wi-Fi), at lunchtime (Wi-Fi if available), and at the end of the day in the depot (Wi-Fi). The sync engine should be configured to detect Wi-Fi availability and to drain the queue aggressively when Wi-Fi is present. The battery impact is higher than Pattern 1 because the sync engine is running more frequently; the recommended pattern is to enable the sync engine only when the device is plugged in or when the battery is above 70%.

Pattern 3: Rural coverage (20-60% connectivity). The local store should be the full active work order set for the technician's route, not a time-windowed subset. The sync engine should be configured to use wifi-only when available but cellular-or-wifi when the route is more than 50% complete. The conflict resolution rules should defer meter readings and signatures to human review in all cases. The operational pattern is that technicians may go days without a reliable sync window; the device must be capable of holding the full route plus the inbound delta queue plus the outbound delta queue for that duration. The recommended device storage is 256 GB minimum, with the local store sized to 8-12 GB for the typical rural route. The battery impact is the dominant operational consideration: technicians should be issued a battery case or a secondary battery to ensure the device can last a full 10-12 hour shift with continuous sync attempts.

Pattern 4: Remote coverage (less than 20% connectivity or air-gapped sites). MX-Edge still applies, but the sync engine should be configured to use a satellite uplink (Starlink, Iridium) when available. For genuinely air-gapped sites (offshore platforms, remote mining operations), the sync engine should be configured to queue indefinitely and to provide a manual export/import mechanism for the cases where satellite uplink is unavailable for days at a time.

GPS, Barcode, and the 18-Minute-Per-Route Saving

Two integration patterns that are not part of MX-Edge itself but that interact with it productively are GPS auto-arrival and barcode/RFID asset identification. Both are pre-9.1 capabilities, but their interaction with MX-Edge in a 9.1 deployment produces a measurable workflow improvement.

GPS auto-arrival uses the device's location services to detect when the technician arrives at the work order location. When the device's geofence entry event fires, the work order is automatically transitioned to "In Progress" and the labor timer starts. The technician does not need to manually start the work order. The pattern saves 45-90 seconds per work order, which over a typical 12-work-order route adds up to 9-18 minutes.

Barcode/RFID asset identification uses the device's camera or NFC reader to scan the asset's barcode or RFID tag. The scan event resolves to the asset record in Maximo and pre-populates the work order's asset reference. The pattern eliminates the manual asset lookup that is the single largest source of incorrect-asset errors in field service operations.

// Maximo Mobile 9.1 - GPS auto-arrival automation script (work order transition)
// Triggered when the device's geofence entry event fires
importPackage(Packages.psdi.mbo);

var woSet = mxServer.getMboSet("WORKORDER", "AUTOSTART");
woSet.setWhere("wonum = :1 and status = :2", [wonum, "APPR"]);
woSet.reset();
var wo = woSet.getMbo(0);

if (wo != null) {
    wo.setValue("STATUS", "INPRG");
    wo.setValue("ACTSTART", new Date());
    wo.setValue("SITEVISIT", "ARRIVED");  // custom field for arrival tracking
}

The pattern above is the work-order side of GPS auto-arrival. The device-side pattern is configured in the Maximo Mobile 9.1 presentation XML for the Technician application, with a geofence entry handler that calls the automation script via the REST API. The handler is configured per work order type, with the geofence radius (typically 50-100 meters for outdoor locations, 10-20 meters for indoor locations with Wi-Fi positioning).

Practical Implications

For sites considering the move to Maximo Mobile 9.1, the meter reading restructure is a one-time data migration task that should be planned carefully. The migration moves historical meter readings from work-order-attached to asset-attached, with the work order acting as a transaction reference. The migration is not destructive: the work order still references the reading, but the reading's primary key changes from (workorderid, metername, readingdate) to (assetnum, metername, readingdate). The migration script is provided by IBM in the 9.1 upgrade package and should be run in a non-production environment first to validate the data.

The migration script runs in three phases. Phase 1 builds a staging table (METERREADING_STAGE) that consolidates the work-order-attached readings into the asset-attached form. Phase 2 validates the staging table against a set of business rules: no duplicate readings for the same (assetnum, metername, readingdate) tuple, no readings with readingdate in the future, no readings where the delta from the prior reading exceeds the meter's MAXDELTA configuration. Phase 3 swaps the staging table into production by renaming the staging table to METERREADING and rebuilding the indexes. Phase 3 should be run during a maintenance window because it takes an exclusive lock on the meter reading table.

For sites considering MX-Edge, the device fleet management is the operational consideration that is often underestimated. MX-Edge requires a minimum device storage of 8 GB (the local store for a large site is 4-6 GB), a minimum iOS version of 17 or Android version of 13, and a mobile device management (MDM) solution that can manage the encrypted SQLite store's encryption key lifecycle. Sites that have not standardized on an MDM solution should treat the MDM selection as a prerequisite to the MX-Edge rollout.

The MDM integration is non-trivial because the encryption key lifecycle is tied to the device's enrollment status. When a device is unenrolled from the MDM, the encryption key should be revoked, which renders the local store unreadable. When a device is re-enrolled, the encryption key is reissued and the local store is re-initialized from the backend. The MDM must support the key escrow pattern that allows the organization to recover the encryption key for legitimate device transfer scenarios (technician changes devices, lost device is recovered, device is replaced under warranty). The MDM solutions that have been validated for this pattern as of June 2026 are Jamf Pro (for iOS fleets), Microsoft Intune (for cross-platform fleets), and Ivanti Neurons for MDM (for Android-heavy fleets).

For sites already operating Maximo Mobile 8.x or 9.0.x with a connectivity profile in any of the four patterns above, the expected productivity improvement from the MX-Edge rollout is 15-35%, with the higher end of the range going to sites with the lowest connectivity profile. The improvement comes from the elimination of the connectivity tax, not from any new feature on the technician side.

Bottom Line

MX-Edge and the meter reading restructure are the two most consequential changes in Maximo Mobile since the original rewrite. MX-Edge eliminates the connectivity tax that has limited field service productivity in coverage-challenged areas for years. The meter reading restructure consolidates the asset's meter history into a single source of truth, which improves PM accuracy and reduces rework. The two changes are independent but complementary, and sites that adopt both see compounding benefits.

For sites planning the second half of 2026, the recommended sequence is: upgrade to Maximo Mobile 9.1 with the meter restructure enabled, pilot MX-Edge in a single crew with a measured productivity baseline, validate the connectivity profile against the four patterns, then roll out MX-Edge to the rest of the fleet over a 90-day window. Sites that follow this sequence have consistently achieved the expected 15-35% productivity improvement. Sites that try to enable both changes simultaneously across the entire fleet have consistently hit operational issues that delayed the rollout by 60-90 days.

Sources

• Maximo Mobile 9.1 Redefines Meter Readings for Asset-Heavy Operations (LinkedIn, Olga Parra, June 2026)
• Configuring and customizing IBM Maximo Mobile
• Maximo Application Suite Releases information
• All Things Maximo, June 2026 (LinkedIn, Biplab Das Choudhury)