Utilities that started an augmented reality programme on SAP now have a date to work against. SAP’s mobile services documentation carries a deprecation notice for the platform’s AR feature, with removal scheduled for the fourth quarter of 2026. The notice is short, easy to miss, and it does not mean what most summaries of it claim. This piece separates what is actually going away from what is not, sets out the integration paths that remain, and gives a replan checklist for anyone with a pilot in flight.
Key takeaways
- SAP states that “the Augmented Reality (AR) feature in SAP Mobile Services is deprecated and will be removed from the mobile services cockpit UI in Q4 2026”, and advises customers to plan for alternative solutions before that date.
- The scope is the platform configuration surface, not augmented reality on SAP data. Field applications and partner AR extensions are unaffected.
- The durable integration contract was never the AR feature. It is the OData service layer over SAP IS-U and S/4HANA Utilities, which is what every remaining path depends on.
- Partner extensions now carry the richest utility workflows. TeamViewer Frontline, for example, routes a live AR call from the work order a technician is executing and returns session recordings, images, and chat transcripts into SAP document management.
- Utilities with a running pilot should audit which surface it depends on this quarter, not next year. Most pilots were scoped before the notice existed.
What SAP actually deprecated
The notice appears in the SAP Mobile Services documentation, in the administration guide for Fiori UI configuration. Its wording is unambiguous:
“The Augmented Reality (AR) feature in SAP Mobile Services is deprecated and will be removed from the mobile services cockpit UI in Q4 2026.”
The guidance attached to it is equally short: plan for alternative solutions before Q4 2026. SAP does not name a successor. The feature remains functional during the notification phase, which is normal for a deprecation of this type and is also why it is easy to leave unattended until the removal lands.
What this covers is the AR capability administered from the mobile services cockpit: the platform surface where AR content was configured for SAP mobile applications. That is a narrow slice of any real deployment. It is not the field application, not the device layer, and not the data path into your ERP.
What the deprecation does not touch
Three things survive intact, and they account for most of what a utility AR programme actually consists of.
SAP Service and Asset Manager. The mobile field application for maintenance and service work is a separate product with its own roadmap. Crews keep the same work order, notification, and confirmation flows they use today.
Partner AR extensions. Independent AR platforms integrate with SAP through their own certified extensions rather than the deprecated cockpit feature. TeamViewer Frontline is the clearest example in asset management: its xAssist extension provides augmented reality remote assistance calls from smart glasses or a mobile device, its xInspect extension drives AR-assisted inspection workflows, and the integration detects the SAP user and tracks the work order being executed so the session stays traceable. Session recordings, meter readings, troubleshooting images, call records, and chat transcripts pass back into SAP document management.
The OData layer. Everything of consequence in an AR integration flows over OData services, typically brokered through SAP Business Technology Platform. That contract is untouched.
The three integration paths that still hold
Once the cockpit feature is out of the picture, a utility has three architectures to choose between. They differ less in what the technician sees than in who owns the integration.
Path one: field application plus a partner AR extension. SAP Service and Asset Manager stays the system the crew works in, and an AR extension is triggered in context from the work order. The vendor owns the integration and the round trip of captured media back into SAP. This is the shortest route to a working deployment and the most constrained, because the workflows available are the ones the extension supports.
Path two: a direct OData integration to IS-U or S/4HANA Utilities. The AR client reads equipment, functional location, work order, and service notification records straight from the ERP, and writes back confirmations, measurement documents, and attachments. You own the service definitions and the mapping. This is the right path when the AR workflow is specific to your operation and no packaged extension models it, and it is the path that ages best, because the integration surface is a standard interface rather than a product feature.
Path three: a standalone AR platform with a middleware layer. The AR vendor never talks to the ERP directly. An integration layer on SAP Business Technology Platform mediates, holds the mapping, and manages offline reconciliation. It costs more to build and it is the only sensible design when several AR tools, or several plants with different SAP releases, have to be served at once.
The choice is a maintenance decision, not a technology decision. Path one puts the burden on the vendor, path two on your integration team, path three on your platform team.
What this means for a utility specifically
Utility AR work does not fail on the AR. It fails on the data the overlay draws from, which is why the deprecation is a useful prompt.
The objects that matter are the ones already carrying your field work: equipment and functional location records, service notifications, work orders, and, for metering, the order and measurement document chain. If those records are incomplete or the functional location hierarchy does not match what a crew finds on site, no AR front end improves the outcome. It surfaces the gap faster, which is valuable, but that is a data programme rather than an AR programme. Our overview of what a utility CIS actually covers sets out where those records live in an IS-U landscape.
Connectivity is the second constraint, and substations are the reason. An AR workflow that assumes a live session fails in exactly the locations where hands-free guidance is most useful. Offline capture with deferred sync is the requirement, and it needs to be tested in the worst site you have, not the best.
Third, safety approval sits outside the software. Anything worn or held during switching or energised work goes through the same review as any other field equipment, and that review runs on its own calendar. Utilities that treat it as a procurement afterthought lose a quarter.
A replan checklist before Q4 2026
- Identify the dependency. Determine whether any live or piloted AR workflow is configured through the mobile services cockpit. If it is, it has a removal date.
- Inventory the workflows, not the tools. List the specific tasks AR supports today: inspection rounds, remote expert calls, guided replacement procedures. Tools are replaceable; the workflow list is what you are protecting.
- Pin the integration contract. Document the OData services each workflow reads and writes. This is the artefact that makes a vendor change a configuration exercise instead of a rebuild.
- Re-test offline behaviour. Deferred sync paths tend to be the least exercised part of a pilot and the first to break under a new integration path.
- Decide the ownership model. Vendor extension, in-house OData integration, or a platform middleware layer. Pick deliberately, because it determines who is on call when a sync fails at a substation.
- Set a measurable success metric before you migrate. Inspection completion time and first-time-fix rate are objective and available in the same systems the AR workflow already touches.
Our longer treatment of SAP augmented reality in utility field service covers the deployment scoping question, and the AR plus ERP asset management piece covers the work order integration point in more depth.
Where AR still does not pay
The deprecation is a reasonable moment to cut the parts of a programme that were never tied to a task. AR remains hard to justify for general field work where a rugged tablet showing the same record performs identically, for training scenarios that a well-made video covers, and for any workflow where the underlying asset data is known to be unreliable. It earns its place on repeatable, high-consequence tasks: substation inspection, complex switching, and first-time-fix support on equipment a crew sees rarely.
The verdict
The removal of an admin feature from a cockpit UI is a small event that happens to be well timed. It forces the question most AR programmes never answered, which is what the integration actually rests on. If the answer is a clean OData contract over IS-U or S/4HANA Utilities and a short list of workflows with measurable outcomes, the deprecation costs you a configuration change. If nobody can answer it, that is worth knowing in 2026 rather than in the quarter the feature disappears.
If you want a second set of hands on that audit, the AvanSaber team works on SAP utility integrations case by case.