Designing Maximo Mobile 9.1 for the Real Field: The Offline Data Contract, Sync Interruptions, and What 'Works Offline' Actually Means

Designing Maximo Mobile 9.1 for the Real Field: The Offline Data Contract, Sync Interruptions, and What "Works Offline" Actually MeansMaximo Anywhere is not deprecated. It is not in extended support. It is not available as a compatibility option. It is gone. The Maximo Mobile that ships with Maximo Application Suite 9.0 and 9.1 is the only mobile client, and it is built on a fundamentally different architecture: React.js on the front end, the Maximo Application Framework under the hood, a local SQLite database on the device, and a sync engine that is engineered to be offline-first rather than offline-tolerant.

That difference matters more than any individual feature. Anywhere needed persistent connectivity. If a technician lost signal, they were dead in the water. The new Maximo Mobile is designed for the field the way the field actually is: spotty coverage, dead zones inside containment, intermittent network during travel, and a workday that does not stop when the network does. But the offline-first design only delivers on that promise if you configure it correctly. Out of the box, the data contract is generic. To make the offline experience actually work for your technicians, you have to engineer the data contract for each persona, separate initial load from delta refresh, govern preloaded databases, and test sync interruptions in a way that mirrors the reality of the field.

This article walks through the design decisions, the configuration patterns, and the test procedures that turn Maximo Mobile from a deployed app into a field-ready tool.

The Persona-Driven Data Contract

The first design decision is the data contract. Offline capability is not a binary state where "the app works without a network." It is a distributed data contract that defines which records live on the device, how they get there, how long they stay, and what happens when the device reconnects. The contract is different for every persona. A corrective maintenance technician, an inspector, a supervisor, a warehouse worker, and a service request reporter do not need the same data, and trying to give them the same data is the single most common cause of poor mobile performance.

Start with the personas. For each persona, map a typical shift from login through travel, work execution, attachments, meter readings, inspections, status changes, and final synchronization. Mark every step that must work offline. Mark every step that can require connectivity. The output of this exercise is a list of which records each persona needs locally and which records can be fetched on demand.

Translate the persona analysis into four data groups. The first is assigned transactional data: work orders, service requests, and any other records that the technician is actively working on. The second is supporting transactional children: tasks, labor records, work logs, attachments, inspection results, and similar records that hang off the assigned work. The third is reference data: domains, classifications, assets, locations, job plans, labor codes, and failure codes. The fourth is optional context: history, maps, documents, broad asset search, and similar records that are useful but not essential.

The goal is not to put Maximo on the device. The goal is to provide the smallest complete set that supports the persona. Excess data increases initial download time, increases local storage, increases query cost, increases refresh duration, and increases the exposure if a device is lost. A typical corrective maintenance technician persona might need 250 to 400 work orders, up to 1,200 linked asset and location records, a rolling two-week inventory cache of around 800 line items, and the reference data needed to populate picklists. That is a meaningful dataset, but it is a fraction of the full Maximo database.

Define the scope rules in business language before implementing the queries. "The technician sees work orders assigned to them, in their primary craft, with a status of Approved or in progress, scheduled to start in the next 14 days or with a status that has not changed in the last 7 days." That kind of rule is testable. It is communicable to the business. It is portable across upgrades. Implement the same rule in the Maximo data set configuration, and you have a contract that survives the next platform upgrade.

Initial Load, Delta Refresh, and the Preload Decision

The second design decision is the sync architecture. Maximo Mobile supports three patterns, and the right choice depends on the persona, the dataset size, and the network conditions in the field.

The first pattern is initial load at first login. When the technician logs in for the first time, the sync engine downloads the scoped dataset defined in the data set configuration. The download can take a few minutes for a 10,000 record dataset on a fast network, and significantly longer on a slow field network. After the initial load, the sync engine handles delta refresh on every subsequent login, downloading only the records that have changed since the last sync.

The second pattern is initial load plus a separate preloaded database. For personas where the dataset is large, where many users need similar reference data, or where field connectivity makes the first synchronization impractical, you can generate a preloaded database on a server, copy it to the device through a device management system, and have the technician log in to a pre-populated local store. The first login is effectively instantaneous, because the data is already on the device. The preloaded database is then refreshed through the normal delta sync.

The third pattern is hybrid. Some personas start with a preloaded reference dataset, and receive a small assigned dataset through the initial load. The reference data is the same for every technician, and it does not change frequently. The assigned data is per-technician, and it changes daily. Hybrid is the right answer for most large enterprises, because the reference data dominates the dataset size but changes slowly, and the assigned data is small but changes quickly.

Engineer each of these patterns separately. Initial load and delta refresh have different performance characteristics, different failure modes, and different test plans. Preload has its own lifecycle. The preloaded database is a release artifact. It should be generated from a known source environment, with a recorded generation date. It should be signed and versioned. It should be governed like any other release artifact, with a clear owner, a clear cadence, and a clear rollback path if the next preload has an issue.

For most enterprises, the right cadence is a weekly preload of the reference data, with a daily delta sync of the assigned data. The weekly preload keeps the reference data fresh without requiring every technician to download the full reference dataset every morning. The daily delta keeps the assigned data current without waiting for the next preload. The combination is operationally manageable and field-tested.

The Sync Interruption Test Suite

The third design decision, and the one that most teams skip, is the interruption test suite. Out of the box, the sync engine handles network interruptions correctly. The question is whether your configuration, your data scope, your authentication, and your attachment handling all behave correctly when the network fails at the worst possible moment.

Build the test suite around the realistic failure modes of the field. The first scenario is interrupted initial load. Kill the network connection halfway through the initial sync. Verify that the download resumes from the same point on reconnection, that no records are duplicated, and that no records are lost. The second scenario is interrupted delta refresh. The technician is partway through a delta refresh when they enter a dead zone. Verify that the partial refresh rolls back cleanly, and that the next delta refresh includes the records that were missed.

The third scenario is interrupted local upload. The technician has been working offline, has updated several work orders, and is uploading the changes when the connection drops. Verify that the upload resumes correctly, that no work order is uploaded twice, and that conflicts are surfaced for human review. The fourth scenario is interrupted attachment transfer. A 200 MB attachment is uploading when the connection drops. Verify that the partial transfer is discarded, and that the full attachment is re-uploaded on reconnection.

The fifth scenario is closed app during sync. The technician closes the app while a sync is in progress. Verify that the sync resumes when the app is reopened, and that no work is lost. The sixth scenario is device restart during sync. The device is restarted while a sync is in progress. Verify that the sync resumes cleanly, and that any partial state is recovered correctly. The seventh scenario is expired authentication. The technician has been offline long enough that their authentication has expired. Verify that the app prompts for re-authentication on the next sync, that the re-authentication works against the configured identity provider, and that the sync resumes after re-authentication.

The eighth scenario is battery failure mid-sync. The device dies during a sync. Verify that the local state is recoverable, and that the next charge and login resumes cleanly. Run each scenario in a repeatable way, with a documented expected outcome and a documented actual outcome. The test suite is the only way to know that your configuration actually delivers offline-first behavior in the field, and it is the only way to catch the regressions that platform upgrades can introduce.

Attachments, Location, and the 200 MB Question

The fourth design decision is the attachment policy. Attachments are the largest single source of mobile performance and storage issues. A 10 MB photo on a 50-photo job is 500 MB, and a typical technician might be working on multiple jobs in a day. The naive approach of "sync everything" runs into the wall quickly.

The right approach is an attachment policy by work type, defined in business language, and enforced in the configuration. Define the acceptable media types. Define the preferred resolution. Define the maximum operational size. Define the metadata requirements. Define the retention. Define the malware controls. Define whether download is automatic or user initiated. Test the complete storage path: device, Manage attachment configuration, file or object storage, ingress limits, proxies, and retrieval. Maximo Mobile 9.1 supports files up to 200 MB on supported iOS and Android devices, but the supported is doing a lot of work in that sentence. Validate the specific device models in your fleet before you commit to a 200 MB attachment policy.

For location, the policy needs to cover GPS accuracy, GPS spoofing prevention, travel time capture, and the conditions under which location is recorded. Maximo Mobile 9.1 includes GPS spoofing prevention capabilities, which are critical for compliance-driven industries where the recorded location must be trustworthy. The Start Travel button can be configured to display regardless of the current distance of the GPS location from the store, which is a small change but a useful one for organizations that need to record travel time for billing or compliance purposes.

For technicians creating work orders in the field, the ability to create a work order using GIS coordinates from a map is a meaningful productivity gain. The technician long-clicks on a location on the map, the work order is created with the GIS coordinates, and the assignment is automatically routed to the appropriate planner. This requires GIS integration in the back end, but the mobile capability is built in.

What Goes Away: Maximo Anywhere Compatibility

For teams still running Maximo Anywhere, the move to Maximo Mobile is not optional. Anywhere is not supported in MAS 9.0 or later. The Anywhere artifacts — the Work Execution, the Asset List, the Inspection Form, the customized applications — must be rebuilt in the Maximo Application Framework. This is a real project. The Anywhere customization patterns do not translate directly to the MAF patterns, and the MAF patterns are more capable but also more demanding in terms of design and testing.

The replacement pattern is to identify the Anywhere applications that are still in use, identify the personas that depend on them, and design the Maximo Mobile data contract and configuration to deliver the same persona journeys. In some cases, the replacement is a direct mapping. In other cases, the replacement is an opportunity to retire customizations that were workaround for capabilities that MAF delivers natively.

The inspection form capability is a useful example. In Anywhere, inspection forms were a custom build on top of the Anywhere platform. In Maximo Mobile, inspection forms are a first-class capability, and the form definitions are downloaded once at login and cached on the device. The technician opens an inspection, and the form renders instantly from local cache. If the form definition is updated on the server, the new definition syncs at the next login. The result is faster inspection execution, less reliance on the network during the inspection, and simpler form maintenance.

Practical Implications

The Maximo Mobile 9.1 design is a real engineering exercise. The data contract, the sync architecture, the interruption test suite, and the attachment policy are all decisions that require technical judgment, business input, and field validation. The teams that treat this as a deployment exercise and skip the design phase will end up with an app that works in the office and fails in the field. The teams that treat it as a design exercise, with persona analysis, scoped data sets, and a tested interruption suite, will end up with a mobile capability that actually delivers on the offline-first promise.

For organizations still on Maximo Anywhere, the implication is that the replacement project cannot be deferred indefinitely. Anywhere is not supported, the platform underneath it is not supported, and the longer you wait, the more you are carrying customization debt that will have to be retired eventually. Plan the Maximo Mobile deployment as a project, not a deployment. Identify the personas. Design the data contracts. Rebuild the inspections. Test the interruptions. Pilot with a small fleet. Roll out by persona, not by site.

For organizations already on Maximo Mobile, the implication is that the configuration work is not finished. The data contract should be reviewed quarterly. The interruption test suite should be re-run on every platform upgrade. The preloaded databases should be governed as release artifacts. The attachment policy should be validated against the actual devices in the fleet. The offline-first promise is delivered by the configuration, not by the platform, and the configuration needs the same care as any other production system.

Bottom Line

Maximo Mobile 9.1 is the most capable mobile client that has ever shipped with Maximo. The offline-first architecture, the scoped data contract, the configurable sync, the inspection form engine, and the 200 MB attachment support are all real improvements over Anywhere and over earlier versions of the mobile client. The capability is there. The configuration is the work. The teams that do the configuration work carefully will deliver a mobile experience that actually works in the field. The teams that skip the work will discover the gaps in production, on a Tuesday afternoon, when a technician is three hours into a job and cannot get the work order to sync. Design the data contract. Test the interruptions. Pilot with real users. Then roll out.