Why are S/4HANA customers still running 2017 mobility decisions in 2026?

The assumptions we carry are older than the platform we run

Ask an SAP customer why they chose a third-party framework for their mobile field applications five or eight years ago, and the answers are remarkably consistent: SAP’s mobile tooling was immature, offline was hard, the developer experience was poor, and the business could not wait. Those were fair judgments — at the time they were made.

The problem is that architecture decisions tend to outlive the facts that justified them. While organisations were busy running the solutions they bought in 2017, SAP’s mobile and offline stack went through several generations of evolution. SAP Mobile Platform gave way to SAP Mobile Services on BTP. The Mobile Development Kit (MDK) matured from a promising experiment into a production-grade, metadata-driven framework running on native SDKs. Offline OData grew into one of the most sophisticated mobile synchronisation engines in the enterprise market. And the surrounding platform — identity, lifecycle, monitoring, AI — consolidated around BTP in a way no point solution can replicate.

For S/4HANA customers planning the next decade, the question is no longer “can SAP do mobile?” It is “what do we gain by bringing mobility home to the platform we have already committed to?” The answer turns out to be substantial — especially in the three areas where field applications live or die: offline robustness, security, and operational quality.

Offline is a synchronisation problem — and synchronisation is where the platform shines

Every experienced mobility architect knows the dirty secret of offline projects: showing cached data is trivial; getting changes reliably back and forth between thousands of devices and a transactional core system is brutally hard.

Conflict handling, ordering guarantees, partial failures, flaky networks, datasets that grow tenfold after go-live — this is where field projects stall, and this is precisely the layer SAP has industrialised.

The Offline OData engine at the heart of SAP Mobile Services is not a cache. It is a full OData client running against an encrypted relational store on the device, capable of executing the same queries the backend would answer — filtering, paging, aggregating — entirely offline, against disk rather than memory. For applications with large working sets, such as plant maintenance with tens of thousands of work orders and attachments, this architectural choice is decisive. The device’s constraint becomes storage, which modern hardware has in abundance, rather than application memory, which it does not.

For applications with large working sets — plant maintenance with tens of thousands of work orders and attachments — the device’s constraint becomes storage, not application memory. That single architectural choice is decisive. It changes what is even possible in offline scenarios.

On top of that store sits a transactional synchronisation model that treats every offline change as a queued request. Uploads push the queue to the backend in order; downloads refresh the local store; upload categories allow selective synchronisation of business-critical changes ahead of bulk data. Failed requests land in an error archive where they can be inspected and resolved rather than silently lost, and pending changes can be undone locally before they ever reach the backend. None of this has to be designed, coded, or maintained by the project team. It is the platform.

Delta tracking deserves special mention, because data volume is where many offline rollouts quietly bleed money and battery. With delta-enabled services, only entities that changed since the last synchronisation travel over the network — and where the backend service cannot provide deltas, Mobile Services computes them in the middleware on the application’s behalf. The result is sync windows measured in seconds rather than minutes, and network consumption that scales with change rates rather than dataset size. For workforces on satellite links, vessels, mines, or congested industrial sites, this is the difference between a tool people trust and a tool people work around.

Security and quality are built in, not bolted on

Field devices are the most exposed endpoints in an SAP landscape. They leave the building, they get lost, and they carry transactional business data. The security posture of an offline solution therefore cannot be an afterthought assembled from application-level workarounds — it has to be a property of the system.

On the SAP stack, it is. The offline store is encrypted at rest by design. Device onboarding, authentication, and policy enforcement are managed centrally through Mobile Services, integrated with the same identity infrastructure that governs the rest of the BTP and S/4HANA landscape. Certificate lifecycles, app configuration policies, and the ability to lock or wipe application data follow the device through its lifetime. For the security organisation, this means one coherent model to audit instead of a patchwork; for the architect, it means the CISO conversation gets shorter every year instead of longer.

Because MDK applications are defined as metadata executed by native SDK runtimes, the heavy engineering — rendering, persistence, sync, crash resilience — is SAP’s responsibility and is hardened across SAP’s entire customer base. Business logic and UI definitions update over the air without app-store cycles. The underlying client remains a tested, supported artefact.

Quality follows the same pattern. Central monitoring in the Mobile Services cockpit gives operations teams visibility into sync behaviour, usage, and errors across the fleet, turning field support from forensic guesswork into routine operations.

The gap-closing process: how SAP platforms mature

It is worth being honest about the pattern, because recognising it helps with the next decision too. SAP platform capabilities often start behind best-of-breed point solutions. Early Fiori was behind contemporary web frameworks; early BTP integration was behind dedicated iPaaS vendors; early SAP mobility was behind specialised mobile platforms. Customers filled gaps with third-party tools, and rightly so — businesses cannot wait for roadmaps.

But SAP’s platform investments compound. Each generation absorbs the lessons of the gap-fillers, integrates with the rest of the stack in ways outsiders structurally cannot, and arrives with roadmap commitments that match the lifespan of an S/4HANA investment. Today’s mobile stack connects to the same destinations, the same identity provider, the same transport and lifecycle discipline, and increasingly the same AI layer — Joule and the business AI capabilities emerging across S/4HANA and BTP — as everything else the organisation runs. A field application built on this foundation is not an island; it is a citizen of the landscape, eligible for every platform capability that arrives after it.

Point solutions are evaluated on what they do today. Platforms are evaluated on what they pull your applications into tomorrow. An offline work order app on the SAP stack will inherit AI-assisted experiences, evolving security standards, and new device capabilities as platform features. The same app on an isolated framework inherits only what its vendor can build and what your budget can fund.

A concrete reference for what BTP-native looks like in production: S5 designed and delivered a custom Fiori Plant Maintenance Master App for Aker BP, one of Europe’s largest independent oil and gas operators. The app consolidates more than 15 SAP GUI transactions into a single integrated set of Smart Reports, runs on the BTP stack, and works across the company’s five Norwegian Continental Shelf assets. That is the platform compounding effect made tangible — one application, one identity layer, one lifecycle, surfaced through SAP’s evolving UX layer rather than locked into a parallel ecosystem.

Where productised partner solutions still belong

The argument above is not “everything must be MDK.” Productised partner solutions on top of SAP remain valid for specific frontline use-cases where speed-to-value matters more than platform consolidation — pre-built mobile maintenance and warehouse experiences that customers can deploy in weeks rather than build over quarters.

S5 has delivered exactly those, including a packaged mobile plant maintenance solution now used across more than fifty plants worldwide, where maintenance workers and supervisors spend roughly 10% more time on-site because the administrative burden has been removed from the device.

The point is not to pick a religion. It is to make the choice with current facts. For greenfield mobile development on the SAP stack today, the MDK / Offline OData / Mobile Services path is no longer the harder option — it is the one that compounds. For specific frontline workloads where a productised solution already covers the scope, taking the productised path remains the right answer. What is no longer defensible is choosing a custom third-party framework on the assumption that SAP cannot do mobile.

What customers should actually do

Revisiting does not mean ripping out what works. It means three concrete moves.

• Baseline the current state honestly. Measure sync volumes, sync durations, failure rates, device incidents, and the engineering hours spent maintaining custom synchronisation logic in existing mobile solutions. These numbers are usually surprising, and they are the real cost of yesterday’s gap-filling.
• Pilot the hardest scenario — not the easiest — on MDK with Offline OData. The largest dataset, the worst connectivity, the most demanding user group. Offline platforms reveal themselves under stress, not in demos.
• Set a portfolio principle. New mobile development defaults to the SAP stack unless a documented capability gap says otherwise, and existing solutions are reassessed at their natural renewal points against the platform’s current state rather than its remembered one.

The era when enterprise mobility on SAP required going around SAP is ending. The platform has done what platforms eventually do: it closed the gap, and then it kept building. For S/4HANA customers, the highest-performing, most secure, most operationally sustainable path for offline mobile applications now runs through the stack they already own. The only thing standing in the way is an assumption that expired several releases ago.

Frequently asked questions