Post-Entitlement Field Mobility: Rebuilding the Maximo Mobile Budget After the 7.6 Deadline

Extended support for Maximo 7.6.1.x ended on September 30, 2026. The deadline passed. Nothing stopped working. That sentence is the most useful thing anyone can say to a field organisation on October 1, and it is also the sentence most likely to be misread.

Maximo 7.6 will not stop functioning. Licenses persist, logins persist, work orders persist, and a large population of environments will run into 2027 and beyond. What ended was the entitlement: problem management records for newly discovered defects, fixes for those defects, and the predictable upgrade path that made an aging mobile deployment defensible. A field technician on a five-year-old device with a five-year-old app build has not lost access. The organisation has lost the ability to get that technician a fix if something breaks.

That distinction lands hardest on mobile, and it lands there for a structural reason. Mobile is the layer of a Maximo estate with the shortest hardware refresh cycle, the widest dependency surface, and the least tolerance for a two-week regression. A back-office screen that renders slightly wrong is a ticket. A mobile screen that fails to capture labor, drops a meter reading, or blanks a work-order queue during a storm event is a crew standing still in a truck. Field mobility is where the abstract language of "support entitlement" becomes a concrete operational risk.

This article is about the period that starts now. It covers what post-entitlement actually means for Maximo Mobile specifically, why the licensing conversation and the migration conversation keep producing incompatible answers, how to build a mobile budget that survives contact with a real fiscal year, and how to sequence the work so that field crews are never the ones absorbing the transition cost. It is written for mobility leads, field operations managers, and the program owners who have to sign the number.

The headline for this cycle, reported in the September Technical Touchpoint (community.ibm.com, 2026-09-22), is that the mobile and field-execution story continues to move on the MAS 9.2 line. The direction of travel is clear even where the specifics are still filling in. The open question for most estates is not whether to move the mobile layer. It is when, in what order, and paid for out of which budget line.

What Actually Changed on October 1, and What Did Not

Start with the parts that did not change, because the field organisation is going to hear the opposite from someone. The Maximo Mobile application that a crew is using today continues to authenticate, continue to synchronise, and continue to write work-order transactions back to the same database. The mobile server components keep running. The devices keep working. If the estate was stable on September 29, it is stable on October 1.

What changed is the support contract behind that stability. During extended support, an organisation could file a problem management record against a newly discovered defect in the 7.6.1.x line and expect a fix. That path is closed. A defect discovered today in a 7.6 mobile authentication handler, or in the offline synchronisation layer, or in the labor-capture transaction logic, no longer has a vendor fix routed to it. The organisation owns the remediation, either through a workaround, a custom patch, or an acceleration of the migration.

For mobile, the practical consequence of that closure is a narrowing of acceptable failure modes. Consider the failure classes that mobile uniquely produces. There is the authentication regression class: a device build or an OS update invalidates a token or a certificate and users are locked out. There is the connectivity class: a sync conflict surfaces in a low-signal environment and the resolution path is ambiguous. There is the labor-capture class: a timer or a timesheet transaction silently fails to post, and the error is discovered at payroll. There is the identity class: a role change does not propagate to the device and a technician sees the wrong work queue.

Every one of those classes used to have an escalation path. Each of those paths now ends at the organisation's own engineering capacity. That is what a support entitlement actually buys, and it is worth naming precisely because the alternative framing, "7.6 is dead," produces the wrong response. The wrong response is a panic migration that ships a broken mobile cutover. The right response is a risk-managed transition that keeps the existing mobile deployment running while the replacement is proven.

There is a second change that receives less attention and matters more over a twelve-month horizon: the drift between the mobile app and the platform it talks to. In a supported estate, the vendor keeps the client and the server in step. In an unsupported estate, the client is frozen while everything around it moves. Device operating systems update. Browsers inside hybrid containers update. TLS policies at a load balancer tighten. A certificate authority rotates. The frozen client does not know. Each of these is a slow-moving fuse, and the fuse length is measured in months, not weeks. The field organisation has time. It does not have unlimited time.

The Licensing Arithmetic That Rarely Matches the Migration Arithmetic

Here is where post-entitlement planning goes wrong most often. A field organisation asks two questions that sound like the same question and are not. The first is "what does it cost to keep doing what we are doing." The second is "what does it cost to move." Leadership tends to compare the second number against the first as if they are commensurable. They are not, and the mismatch produces both bad decisions and bad arguments.

The keep-doing number is misleadingly small in the short term. An unsupported 7.6 estate has no license uplift, no migration project cost, no retraining line, and no integration rework. On a one-year view it looks cheap, sometimes dramatically cheap compared with a MAS project. This is the number that gets quoted in the room where the budget is decided.

The keep-doing number is also incomplete, in three ways that compound. First, it excludes the cost of the workarounds an unsupported estate starts accumulating. Every defect that used to get a fix becomes a custom intervention. Those interventions have a cost, and the cost is not linear, because each workaround adds a branch that makes the next upgrade harder. Second, it excludes the cost of the mobile refresh cycle that cannot be deferred forever. Devices age out regardless of the platform decision. When the hardware refresh happens on a frozen client, the organisation is rebuilding the mobile layer anyway, without the benefit of a supported target. Third, it excludes the optionality cost. An unsupported estate cannot adopt the capabilities that are being built on the current line, and the field organisation that most needs modern mobile tooling is precisely the one that pays for that exclusion.

The move number has its own distortion, in the opposite direction. It is quoted as a peak number, the full project cost, and it is compared against a single year of the keep-doing number. Spread the project over its actual amortisation and the comparison changes. More importantly, the project number usually bundles things that would have to be spent anyway. Device refresh. Network hardening. Identity remediation. Integration cleanup that everyone has been deferring. A meaningful share of a mobile migration budget is not a new cost. It is existing deferred cost with a project wrapper.

The honest framing, and the one that survives scrutiny, is this: post-entitlement does not create a cost. It converts a hidden cost into a visible one. The estate was always going to pay for the mobile refresh, the identity cleanup, and the integration rework. The deadline moves them from a future unbudgeted surprise to a present planned spend. An organisation that frames the decision that way tends to get a better outcome, because it stops arguing about whether to spend and starts arguing about sequencing and risk.

Four Field-Mobility Failure Modes the Deadline Activates

Not every estate faces the same risk. The failure modes cluster, and knowing which cluster an organisation is in determines what the first ninety days should look like.

The first cluster is the frozen custom client. Some organisations built a custom mobile experience on top of the Maximo mobile framework or a third-party wrapper. Those clients are the most exposed, because they have the deepest dependency surface and the least support. A custom client that imports an SDK generation removed from the current platform, or that depends on a server-side API contract that has since changed, is not merely unsupported. It is unsupported and irreplaceable without a rewrite. These estates need the shortest possible transition timeline and should not be spending the next quarter on analysis.

The second cluster is the standard client, aged estate. These organisations run the vendor mobile app against a 7.6 backend with limited customization. Their risk is lower and their time horizon is longer, but their constraint is different: they have little internal mobile capability, so a migration is a capability build as much as a technical project. Their first ninety days should be spent on capability assessment and on locking a device strategy, not on a technical cutover plan they cannot yet staff.

The third cluster is the partial migration. These are the estates that have moved the back office to MAS and left the mobile layer behind, either deliberately or by drift. This is the most common shape in the market right now, and it is the one with the most confusing risk profile. The backend is supported. The mobile layer is not. The two are connected by an integration that has been running on borrowed time. These estates need to test that integration immediately, because the failure will surface as a mobile-side symptom of a backend-side change, and it will be diagnosed wrong the first time.

The fourth cluster is the regulated estate. Utilities, transit, public sector, and any organisation with a labor-record or safety-record obligation carries a compliance dimension on top of the technical one. For these estates, an unsupported mobile client is not only an operational risk. It is an audit finding waiting for a date. A labor-capture defect that silently drops a transaction is a payroll-compliance question. A safety-observation form that fails to post is a records question. These estates should treat the mobile transition as a compliance project with a technical component, which changes who owns it and what the tolerance for slippage is.

Building a Mobile Budget That Survives a Fiscal Year

The budget question is where most mobility plans fail, and it fails not because the numbers are wrong but because the structure is wrong. A single-year line item for a multi-year transition is a plan that will be re-litigated three times. The structure that survives contact with a real fiscal year has four distinct components.

The first component is the stabilisation budget. This is the money spent to keep the current mobile deployment healthy through the transition. It funds a monitoring capability for the frozen client, a defined set of pre-approved workarounds for the failure classes listed above, and a device-management baseline that catches OS and certificate drift before it becomes an outage. This line is small, it is defensible, and critically, it is the line that buys the time the rest of the plan needs. An organisation that funds stabilisation is buying an orderly transition. An organisation that skips it is gambling that nothing breaks during the project window.

The second component is the capability budget. This funds the people, not the platform. Mobile transitions fail on capability far more often than they fail on technology. A standard client to a modern platform is a modest technical change and a substantial skills change, because the modern line assumes a level of mobile-specific expertise that many 7.6 estates never needed. This budget funds training for existing staff and, increasingly, external capability while internal capability is built. The market signal this cycle, with Maximo 9.x skills supply showing up as an active buying criterion rather than a background concern, is a direct warning that this line cannot be deferred.

The third component is the transition budget. This is the project itself: the mobile configuration migration, the integration rework, the testing, the pilot, and the cutover. Structure it by phase, not by year, and attach a device-refresh phase explicitly, because device refresh is the one component that cannot be squeezed and is the one most often left out of the initial ask.

The fourth component is the run budget. This is the number that replaces the keep-doing number, and it should be built from the target state, not from the current state plus an uplift. It funds the ongoing platform cost, the mobile licensing at the new tier, and a support model that matches the new line. Building this number honestly is what makes the whole comparison real, because it converts an abstract "future cost" into a concrete line that a finance partner can reason about.

The ordering matters as much as the components. Stabilisation first, because it buys time. Capability in parallel, because it gates everything downstream. Transition on a phase schedule driven by capability readiness, not by a calendar date. Run budget locked before the transition begins, so the decision is made once rather than re-opened mid-project.

Sequencing the Transition Without Breaking the Crews

The failure that a well-budgeted mobile transition still produces is a cutover that breaks the field organisation. The technology moves cleanly, the project closes on time, and the crews absorb a month of friction that nobody budgeted for. Avoiding that outcome is not about the platform choice. It is about sequencing.

The first principle is to never migrate the mobile layer and the back office in the same window. If the back office has already moved, the mobile layer migration should be a discrete, isolated change. If the back office has not moved, the mobile layer should not lead. Two simultaneous changes to a field workflow produces failures that cannot be attributed, and unattributable failures are what turn a project into a crisis.

The second principle is to pilot on the crews with the highest tolerance and the most instrumentation. The instinct is to pilot on the simplest crew. The better choice is a crew that generates high-quality feedback and whose work can be measured. A pilot on a crew that will not report friction is a pilot that produces false confidence.

The third principle is to keep the old mobile path live through the transition, not as a fallback that nobody tests, but as a genuinely exercised parallel path for at least one full operating cycle. A fallback that has not been used is not a fallback. A parallel path that runs one real week of work is a control.

The fourth principle is to sequence the identity and device work ahead of the application work, because identity and device issues are the ones that produce a total field outage rather than a degraded experience. A configuration issue is a bad day. An identity issue is a crew that cannot log in. Order the work so the total-outage risks are retired first.

The fifth principle is to budget the friction explicitly. Every field transition produces a productivity dip. A plan that assumes zero dip is a plan that will be reported as a failure even when it succeeds. Naming the dip in advance, with a duration and a measurement, converts an apparent failure into a forecast. Field leadership accepts a forecast. They do not accept a surprise.

Practical Implications

For most organisations, the practical work of the next ninety days is not a migration plan. It is a risk register with owners and dates.

Start by classifying the estate against the four clusters above and writing down which one applies. That single classification determines the timeline, the budget shape, and the tolerance for slippage. An organisation that skips this step will build a plan for a cluster it is not in.

Next, build the stabilisation capability before anything else. That means a defined monitoring path for the frozen mobile client, a pre-approved workaround catalogue for the four failure classes, and a device-management baseline that tracks OS and certificate drift. This is the cheapest line in the plan and it protects every other line.

Then test the integration between the mobile layer and whatever backend the estate is actually running. Do this before the migration planning, not after, because the test result changes the plan. A partial-migration estate that discovers a broken integration in month one has options. One that discovers it in month five has a crisis.

Finally, lock the run budget against the target state and get it acknowledged by the finance partner before the transition begins. The number that gets re-litigated is the number that was never agreed in the first place. Post-entitlement planning is a multi-quarter exercise, and the organisations that execute it cleanly are the ones that made the budget conversation happen once, early, and in full.

Bottom Line

October 1 was not a cliff. It was a line in a support contract, and the field organisation on the other side of it is still operating. The mobile layer keeps running, the crews keep working, and the estate keeps producing.

What changed is that the estate now owns its own remediation, and mobile is the layer where that ownership is most expensive to get wrong. The organisations that handle the post-entitlement period well will not be the ones that moved fastest. They will be the ones that stabilised the existing deployment, funded the capability before the project, sequenced identity and device work ahead of application work, and converted a hidden future cost into a planned present one. The deadline did not create that work. It simply removed the option to keep deferring it.