conarum Frames RFC-to-RAP OData Migration as an Architecture Governance Decision

conarum, a consultancy positioning itself as a strategic partner for digital transformation on SAP S/4HANA and SAP BTP, has published architectural guidance on when to replace RFC integrations with RAP-based OData APIs and when to retain RFC, IDoc, or messaging instead. The guidance frames the decision around factors such as interaction pattern, consumer landscape, and transaction semantics, rather than treating newer protocols as an automatic upgrade path. conarum states that the same discipline governs how it develops proconarum, its SAP BTP procurement platform built to replace SAP Supplier Workplace, a component no longer part of SAP S/4HANA.

How conarum Weighs RFC Against RAP OData Migrations

RFC has moved data between SAP systems for decades and remains fast, SAP-native, and well suited to many stable SAP-to-SAP scenarios. Its long history does not make RFC obsolete, and it does not make RAP OData an automatic replacement. The decision should instead weigh interaction patterns, the consumer landscape, and transaction semantics, along with how well an integration performs and how its lifecycle will be managed over time.

conarum’s architectural guidance distinguishes between adopting a new protocol and achieving lasting compatibility. RAP and OData do not create compatibility automatically; stability comes from deliberate contract design, release governance, versioning, and disciplined change control, since protocol choice alone does not guarantee API stability. A custom RAP service that depends directly on unreleased SAP objects, leaks internal structures, or changes its schema without governance remains technical debt regardless of the newer programming model underneath.

The firm recommends keeping RFC where integrations are SAP-to-SAP, where low latency or high throughput matters, or where tRFC, qRFC, or bgRFC semantics are required, provided the callable API is released and supported. RAP-based OData becomes the better fit when browser, SAP BTP, or partner consumers need standard HTTP and OAuth access, or when SAP has published a released RAP successor. conarum points to events, IDocs, or messaging as more appropriate tools for asynchronous replication, high-volume distribution, or durable, ordered processing, since an OData request-response API is not a like-for-like replacement for tRFC, qRFC, or IDoc processing.

conarum cites one recent product data management program in which custom RFC-based processes for materials, bills of material, and engineering change data were progressively replaced with RAP-based or Gateway OData services. IDoc-based flows were retained in that program where asynchronous processing or distribution semantics remained the better fit. SAP’s broader clean core strategy encourages custom extensions in S/4HANA Cloud and BTP environments to rely on governed, released APIs instead of direct access to unreleased objects.

The Same Governance Discipline

conarum applies a parallel governance standard to its own product line. The company states that the same governance principle guiding its RFC-to-RAP decisions also shapes how it develops proconarum, its procurement platform on SAP BTP: public contracts stay explicit and stable, extensions run through supported APIs and extension points, and implementation details stay hidden so that neither side of an integration is forced to change in lockstep with the other.

conarum positions proconarum as a replacement for SAP Supplier Workplace, a component no longer part of SAP S/4HANA, citing a deployment at a customer in the automotive supply industry. SAP has removed several classic transactional tools from S/4HANA in recent release cycles, part of a broader shift toward BTP-based and Fiori-based alternatives. That shift shortens the window affected customers have to evaluate replacement platforms, since the underlying transactional capability disappears from the core product rather than gradually aging in place.

conarum recommends a strangler pattern for migrations in this category: preserve the existing integration, introduce a new public API for selected consumers or capabilities, and retire the old interface only once the business and operational case is proven. This staged approach, a widely used general software migration technique, lets a team validate a new platform against production traffic before a full cutover. Conarum’s broader BTP-based portfolio also includes ProSustain and ProRequest, extending the same procurement focus into sustainability risk scoring and supplier workflow automation.

What This Means for SAPinsiders

Stable RFC connections don’t need forced migration. Teams running governed, released RFC or BAPI links for SAP-to-SAP traffic can leave them in place rather than migrating on protocol age alone. Migration budgets are better spent where consumer reach or lifecycle needs actually change.

API stability requires governance investment beyond the protocol itself. Adopting RAP OData without contract design, versioning, and release governance simply relocates technical debt into a newer interface. Architecture teams should budget for compatibility checks and change control alongside any RAP rollout.

Deprecated SAP components force faster platform evaluation. When SAP retires a classic tool like Supplier Workplace, procurement and IT leaders face a shortened window to vet replacement platforms. That evaluation should apply the same contract and governance scrutiny used for custom integration decisions.