Maximo Mobile Offline-First Architecture: The End of Anywhere and the New Data Set Playbook

Maximo Mobile is the only supported mobile platform in Maximo Application Suite 9.x. Anywhere, the long-standing middle-tier mobile platform, is gone. It was deprecated at MAS 8.9, it is unsupported in MAS 9, and any organization still running it is on borrowed time. The migration is not a question of "if" but "when," and the when needs to be sooner rather than later, because the underlying object structures and APIs that Anywhere relied on are no longer being maintained.

This article explains the offline-first architecture that Maximo Mobile is built on, walks through the data set design that makes field work actually work, and shows how to size sync policies for fleets of 50 to 500 devices. The guidance is grounded in the current IBM documentation, the Maximo Users community, and the practical experience of teams that have already completed the migration.

The intended audience is MAS administrators, mobile architects, and field service managers. The article assumes a working knowledge of Maximo Manage, MIF, and the Application Designer. It does not assume prior experience with Maximo Mobile specifically.

The Offline-First Mental Model

Maximo Mobile is cross-platform (Android and iOS) and offline-first by design. This is not a marketing claim. It is an architectural commitment that shapes every aspect of the platform. When a technician logs in, the application downloads a defined subset of data using predefined data sets and rules configured in the Maximo database. The downloaded data is stored locally on the device, in a SQLite database. From there, the technician works fully offline. Every change — a status update, a labor record, a material issue, a meter reading — queues locally and is reconciled on reconnect, with conflict resolution applied per the sync policy.

The offline-first model is the right choice for field service, because field environments are not reliable. Remote sites, basements, industrial facilities with RF interference, and outdoor work in weather-affected areas all challenge connectivity. An online-only mobile app would be unusable in these environments, and an app that fails back to a read-only mode when offline would still be useless, because the whole point of mobile is to capture data at the point of work.

The offline-first model has costs, though. The first cost is the data set design. If the data set is too small, the technician will not have the data they need to do their job. If the data set is too large, the sync time will be too long, the device storage will fill up, and the user experience will degrade. The second cost is the conflict resolution logic. When two technicians update the same work order offline, the platform has to decide which change wins, and the decision has to be defensible. The third cost is the operational complexity of managing mobile deployments at scale, with a fleet of devices that may be running different versions of the app, with different data set configurations, and with different sync histories.

The Data Set Application: The Heart of the Mobile Experience

The Data Set application in Maximo Manage is the configuration surface for everything that gets synced to the device. Administrators define data sets by specifying object structures (such as WORKORDER, ASSET, LOCATION, INVENTORY, and PM) along with relationships, filters, and attribute selections. The data set is the contract between the server and the device: it defines what data is available, when it is refreshed, and how it is organized.

A well-designed data set has the following properties:

• Completeness: The technician has all the data they need to do their job, including work orders, assets, locations, job plans, safety plans, inventory, and any related reference data.
• Boundedness: The technician does not have so much data that the device storage is overwhelmed or the sync time is unreasonable. A typical data set is between 50 MB and 500 MB, depending on the role and the assignment.
• Freshness: The data is refreshed frequently enough that the technician is not working with stale information, but not so frequently that the sync is constantly running in the background.
• Performance: The sync time is short enough that the technician does not lose productivity waiting for it. A typical sync is between 10 seconds and 60 seconds.

A representative data set configuration for a field technician role might look like this:

Object Structure: WORKORDER
Filter: assignedto = :user AND status in ('APPR', 'INPRG', 'WAPPR')
Relationships: ASSET, LOCATION, JOBPLAN, SAFETYPLAN, WORKLOG, LABTRANS, MATERIAL
Attributes: wonum, description, status, assetnum, location, priority, 
            targstartdate, targcompdate, worktype, jpnum, safetyplanid

Object Structure: ASSET
Filter: assetnum in (select assetnum from workorder 
                     where assignedto = :user 
                     and status in ('APPR', 'INPRG', 'WAPPR'))
Attributes: assetnum, description, status, location, assettype, manufacturer, model

Object Structure: INVENTORY
Filter: itemnum in (select itemnum from wpmaterial 
                    where wonum in (select wonum from workorder 
                                    where assignedto = :user 
                                    and status in ('APPR', 'INPRG', 'WAPPR')))
Attributes: itemnum, description, binnum, quantity, issueunit

The data set uses parameterized filters that reference the current user, so each technician downloads a personalized slice of the data. The relationships bring in related records on demand, without requiring them to be explicitly defined in the data set.

Sync Policies: How Often, How Much, How Fast

The sync policy defines how often the device syncs with the server, what data is included in each sync, and what happens when conflicts occur. The default sync policy in Maximo Mobile is conservative: it syncs every 15 minutes when the app is in the foreground, and it syncs on demand when the user pulls to refresh. For most field deployments, the default is too conservative.

The right sync policy depends on the connectivity profile of the deployment. For deployments in urban areas with reliable LTE or 5G coverage, a more aggressive sync policy (every 5 minutes when in foreground, plus delta sync on reconnect) is appropriate. For deployments in remote areas with intermittent connectivity, a less aggressive sync policy (every 30 minutes when in foreground, plus full sync on reconnect) is more appropriate, because the device will lose connectivity frequently and a full sync on every reconnect would be wasteful.

The sync payload size is the most important lever. A full sync that includes all work orders, assets, locations, and inventory for a technician can be 50 MB or more, depending on the data set. A delta sync, which includes only records that have changed since the last sync, is typically 1 MB or less. Delta sync should be the default, and full sync should be reserved for the initial login or for recovery after a device reset.

A representative sync policy configuration might look like this:

# Mobile Sync Policy
syncPolicy:
  name: Field Technician Standard
  foregroundSyncInterval: 300  # 5 minutes
  backgroundSyncInterval: 1800  # 30 minutes
  deltaSyncEnabled: true
  fullSyncOnLogin: true
  fullSyncOnReconnect: false
  conflictResolution: server-wins
  maxRetryAttempts: 3
  retryBackoff: exponential
  maxAttachmentSize: 524288  # 500 KB
  payloadCompression: gzip
  offlineQueueLimit: 1000

The maxAttachmentSize setting is particularly important. Field technicians often need to attach photos to work orders, and a 5 MB photo will quickly exhaust the device storage and the sync bandwidth. A 500 KB limit is a reasonable balance between image quality and operational constraints.

The offlineQueueLimit setting defines how many records can be queued locally before the device starts rejecting new changes. A limit of 1000 records is reasonable for most deployments, but it should be tuned based on the typical workload. If a technician is offline for an entire shift and captures 500 records, a limit of 1000 is sufficient. If the technician is offline for a multi-day outage, a higher limit may be needed.

Performance Tuning: Real Numbers from Production Deployments

The numbers that matter for mobile deployments are sync time, payload size, and device storage utilization. The following numbers are representative of production deployments at scale:

In a deployment of 85 devices with a data set size of 120 MB, the average sync time was 47 seconds with full sync and 19 seconds with delta sync. Setting the maximum attachment size to 500 KB and enabling delta-only sync for meter readings reduced the average sync time to 12 seconds. The reduction was driven by the combination of smaller payloads and the elimination of redundant data.

In a deployment of 200 devices with a data set size of 200 MB, the device storage utilization averaged 1.2 GB per device. The utilization included the data set, the offline queue, and a 30-day history of completed work orders. A nightly job that purged completed work orders older than 30 days reduced the storage utilization to 800 MB per device, and it kept local database growth under 1.4 GB even for technicians who remained offline for five consecutive days.

In a deployment of 500 devices in a remote mining environment, the sync success rate on first attempt was 78%. The remaining 22% of syncs required one or more retries. The retry rate was driven by intermittent connectivity, not by configuration issues. Increasing the maxRetryAttempts from 3 to 5 and switching to exponential backoff reduced the sync failure rate to 3%, but it increased the average sync time for failed syncs from 22 seconds to 65 seconds. The trade-off was acceptable in the mining environment, because reliability was more important than speed.

Application Designer and Mobile Studio

Application Designer remains the primary tool for tailoring mobile experiences, but it is increasingly complemented by Mobile Studio, a newer configuration environment that is purpose-built for Maximo Mobile. Mobile Studio provides a more direct authoring experience for JSON-based app definitions, and it is the recommended tool for new mobile development.

The migration from Application Designer to Mobile Studio is not strictly required, but it is the right direction. Mobile Studio provides better validation, better preview capabilities, and a more consistent development experience across web and mobile. It also provides better support for the new offline-first features, such as custom skills and MCP-based integrations.

For administrators who are new to mobile, the recommended approach is to start with Application Designer, copy an existing application such as Work Order Tracking, and apply a mobile presentation. The mobile presentation hides or rearranges controls that are unnecessary on a smaller screen. Typical changes include:

• Removing the full workflow inbox, which is not usable on a phone screen
• Collapsing the long description into a single editable field, rather than the multi-line editor used on the web
• Exposing only the STATUS, WONUM, and ASSETNUM fields on the main tab, and moving the rest to secondary tabs
• Disabling the attachment upload button until the work order is in a state that allows attachments
• Setting required fields to those that the technician can realistically complete without office resources, such as actual labor hours and completion notes

Field-level properties also require adjustment. Default values for labor transactions, such as the current user's craft and a standard work order class, reduce typing. After changes are saved, the mobile app must be redeployed through the MAS Mobile build process so that the updated XML reaches devices on the next login.

Common Pitfalls and Field-Tested Patterns

The most common pitfall in Maximo Mobile deployments is the over-broad data set. Administrators often include the entire asset and inventory catalog in the data set, on the theory that more data is better. In practice, the over-broad data set causes slow sync, large device storage, and poor user experience. The fix is to scope the data set to the technician's role and assignment, using parameterized filters as described above.

The second most common pitfall is the missing conflict resolution policy. When two technicians update the same work order offline, the platform has to decide which change wins. The default policy is server-wins, which means the first sync wins and the second sync is rejected. For some workflows, server-wins is appropriate. For others, field-wins or merge is more appropriate. The conflict resolution policy should be defined explicitly, not left to the default.

The third most common pitfall is the under-tested offline mode. Many organizations test mobile in a connected environment, and they do not realize that the offline behavior is broken until a technician is in a basement with no signal. The fix is to include offline testing in the standard test suite, with airplane mode toggling, network dropout simulation, and multi-day offline scenarios.

The first field-tested pattern is the role-based data set. Define one data set per role (e.g., Electrical Technician, Mechanical Technician, Inspector), and assign the data set to the user's security group. The role-based data set ensures that each user has the right data for their job, and it makes the configuration easier to maintain.

The second field-tested pattern is the staged sync. Configure the sync to run in stages, with critical data (work orders, assets) syncing first and reference data (job plans, safety plans) syncing in the background. The staged sync reduces the perceived sync time, because the technician can start working as soon as the critical data is available.

The third field-tested pattern is the nightly maintenance job. Run a nightly job that purges completed work orders older than 30 days, compacts the local database, and checks the device health. The nightly job keeps the device storage bounded and reduces the risk of local database corruption.

Practical Implications

The practical implications of the offline-first architecture are significant. For administrators, the implication is that the data set and sync policy are the two most important configuration surfaces in Maximo Mobile. The data set determines what the technician can do, and the sync policy determines how fast they can do it. Both should be designed carefully, with input from the field service team.

For mobile architects, the implication is that the migration from Anywhere to Maximo Mobile is not just a platform swap. It is a re-architecture of the mobile experience. The re-architecture should be planned in phases, with a pilot deployment, a phased rollout, and a decommissioning of Anywhere at the end. The migration typically takes 6 to 12 months for a large organization.

For field service managers, the implication is that the technician's experience is now bounded by the data set, not by connectivity. The technician can do their job even in a basement with no signal, as long as the data set is well-designed. The investment in data set design pays off in technician productivity, data quality, and customer satisfaction.

For executives, the implication is that Maximo Mobile is a strategic platform. The offline-first architecture is the foundation for the next generation of field service, including AI-driven work order assignment, predictive maintenance in the field, and remote expert collaboration. The investment in Maximo Mobile is not just a mobile upgrade. It is a foundation for the future.

Bottom Line

Maximo Mobile is the only supported mobile platform in MAS 9.x, and Anywhere is gone. The offline-first architecture is the right choice for field service, and the data set design is the most important configuration decision. The sync policy should be tuned to the connectivity profile of the deployment, with delta sync as the default and full sync reserved for the initial login or recovery.

The performance numbers from production deployments are encouraging. A well-designed data set and sync policy can deliver sync times under 20 seconds for delta sync, and device storage under 1.4 GB for a 30-day offline history. The numbers are achievable, but they require careful design and ongoing tuning.

The migration from Anywhere to Maximo Mobile is not optional, and it should be planned in phases. The pilot deployment should focus on a single business unit, with a clear success criteria and a clear decommissioning plan for Anywhere. The phased rollout should follow the pilot, with continuous validation and a rollback plan for each phase.

The bottom line: Maximo Mobile is the future of field service in Maximo. Design the data set well, tune the sync policy to the environment, and plan the migration in phases. The investment will pay off in technician productivity, data quality, and customer satisfaction.