Move your business with SAP S/4HANA Implementation

If you are in the middle of planning or executing a SAP S/4HANA Implementation, there is a very real chance the data pipeline strategy you sketched out six months ago no longer works the way you intended. The go-to method for pulling delta data out of SAP S/4HANA and landing it in a third-party lake — Databricks, Snowflake, Amazon S3, or Azure Data Lake Storage — relied on a framework called ODP-RFC. As of June 9, 2026, that framework is not just unsupported; it is technically blocked. SAP ships a security patch that validates incoming ODP-RFC calls and rejects the ones that are not SAP-internal. If your connector was built on it, your pipeline goes silent the next time your system applies its support package.

This guide is written for architects, data engineers, and IT decision-makers who need a clear, current picture of what is happening, why it happened, which extraction paths are still legitimate, and what the real licensing bill looks like across each option. Whether you are running on-prem S/4HANA, planning a move to SAP S/4HANA Cloud, or sitting somewhere in between, the information below will help you make an informed architecture decision before you find out the hard way.

What Is ODP-RFC and Why Did It Dominate SAP Data Lake Integration?

The Operational Data Provisioning framework, abbreviated as ODP, was designed by SAP to enable delta-capable data extraction. When called over the Remote Function Call (RFC) protocol, it gave third-party tools a fast, efficient mechanism to read changed records without pulling full data sets every time. For teams running hourly or near-real-time SAP data lake integration workloads, this was enormously valuable. A connector could ask, “Give me everything that changed in the last hour,” and ODP-RFC would return exactly that.

Azure Data Factory’s SAP CDC connector, Qlik Replicate, Fivetran’s SAP module, and most enterprise ETL tools built their SAP connectivity on top of this interface. It was fast, delta-native, and broadly supported. For years it was simply the default way data engineers moved SAP data to a lake.

The ODP-RFC Enforcement Timeline: How We Got Here

SAP has been signalling its intent to close off this access route for several years. The escalation followed a staged path that many organizations treated as warnings rather than deadlines — which is exactly why the June 2026 enforcement caught so many pipelines off guard.

•   2022 — SAP Note 3255746 first appeared, describing third-party ODP-RFC usage as “unsupported.” Most teams filed it under “things to monitor” and moved on.
•   February 2024 — The language in the note hardened significantly, changing from “unsupported” to “not permitted.” Still a policy statement, not an enforcement mechanism.
•   April 2026 — Version 11 of the note removed any remaining ambiguity. Any use of ODP-RFC by customer or third-party applications, whether on-premises or in private cloud, is explicitly prohibited.
•   June 9, 2026 — Enforcement goes technical. A security patch embedded in SAP support packages now validates incoming ODP-RFC calls and blocks those that are not originating from SAP-internal processes. This is the live enforcement date.

One important nuance: the block is specifically on the ODP Data Replication API over RFC. Plain RFC or BAPI table reads, BW OpenHub extraction, and DeltaQ are untouched by this change. SAP ships a self-assessment tool (Note 3439624) that allows you to check your current landscape for exposure before the next support package lands.

What Still Works for Hourly SAP Data Lake Integration

The good news is that hourly extraction to a third-party lake remains entirely achievable. The bad news is that each alternative comes with trade-offs in speed, cost, vendor dependency, or implementation effort. Here is a clear-eyed breakdown of every viable path.

Approach	How It Works	Fit for Hourly
Datasphere Replication Flows	SAP’s recommended path — pushes data directly to a lake as Parquet files. No ODP-RFC involved.	GOOD — fastest to deploy
Business Data Cloud / Delta Sharing	Zero-copy, governed sharing pattern. SAP’s strategic long-term direction for external data access.	GOOD — built for the long haul
ODP via OData	Same delta mechanism as ODP-RFC, but over the compliant OData transport layer. Roughly 10x slower.	WORKS — watch volume carefully
SLT (Trigger-Based Replication)	Not ODP-RFC, so technically unaffected. Lake writes usually need a staging layer or middleware.	VIABLE — extra middleware required
Native CDS / OData Rebuild	Most build effort but never touched the deprecated interface. Future-proof by design.	GOOD — most vendor-independent
Direct HANA DB Reads	Bypasses the application layer entirely. Technically possible but creates significant licensing exposure.	RISKY — licensing exposure

 

Datasphere Replication Flows: The Recommended Fast Path

For most organizations running a SAP S/4HANA Implementation who need to move to compliant lake extraction quickly, Datasphere replication flows are the fastest route to production. SAP designed this specifically as the replacement for ODP-RFC-based connectors. Data lands in Parquet format directly in your lake — no ODP-RFC involved, no prohibited interface, and the delta handling is native.

The trade-off is that Datasphere itself carries capacity-unit licensing, and the cost scales with data volume. Teams that are extracting large tables hourly will need to model out their capacity consumption before signing off on this path. That said, for the majority of hourly use cases, Datasphere replication flows represent the best balance of compliance, speed, and operational simplicity.

Business Data Cloud and Delta Sharing: The Long-Term Strategic Path

SAP’s Business Data Cloud (BDC) with Delta Sharing is the company’s long-term answer to governed data access from SAP S/4HANA Cloud and on-prem systems alike. The pattern is zero-copy, meaning the data does not physically move to your lake — instead, you access it through a shared, governed layer. This eliminates the replication overhead entirely, which matters if you are dealing with large tables or strict data sovereignty requirements.

BDC is still maturing as a product, and not every customer will have access to it today depending on their contract and SAP landscape. But for organizations planning a net-new architecture or going through a SAP S/4HANA Cloud migration, it is worth evaluating seriously. This is the direction SAP is investing in, and building your architecture around it now will age better than any workaround.

ODP via OData: Compliant but Slow

OData-based ODP extraction uses the same underlying delta mechanism as the old ODP-RFC path, but over a compliant transport layer that SAP has not restricted. The catch is throughput: teams moving from ODP-RFC to ODP-OData can expect roughly a 10x reduction in extraction speed. For organizations running low-volume hourly jobs against narrow data sets, this is workable. For teams pulling full transactional history from large tables like BKPF, BSEG, or VBAK at scale, OData will create a bottleneck that is difficult to engineer around.

Before committing to OData as your extraction layer, model your peak hourly volume against OData throughput benchmarks in your specific landscape. The performance varies by system configuration, network, and data model.

Where the Licensing Bill Actually Lands

This is the section that most architecture conversations skip over, and it is consistently where the surprise invoices come from. Licensing exposure in SAP data lake integration is not always obvious, and it sits in several places simultaneously.

HANA License Tier

A HANA runtime license only covers SAP-licensed software touching the database. If a third-party tool reads directly from the HANA database layer — bypassing the application layer entirely — you need a full-use HANA license. That license is priced on a gigabyte-of-memory metric and frequently represents a six-figure gap between what was budgeted and what the audit demands. Before choosing direct HANA DB reads as your extraction method, confirm your HANA license tier in writing.

SLT Licensing

SAP Landscape Transformation Replication Server (SLT) is licensed separately unless the target system’s license already bundles SLT usage. If you are using SLT to feed an SAP CDC connector that writes to a non-SAP target, the full SLT license typically applies. This is not always communicated clearly by tool vendors whose integration layer relies on SLT under the hood.

Datasphere and BDC Capacity Units

Both Datasphere and Business Data Cloud are licensed on a capacity unit model. The more data you move and the more frequently you move it, the higher your capacity consumption. For hourly jobs across multiple large entities, this can add up quickly. Model your expected consumption against your contracted capacity before you begin building.

Digital and Indirect Access

Read-only analytics replication generally does not trigger document-based digital access fees under most SAP contracts. But “generally” is not a number you can put in a budget forecast. Verify this against your specific contract language, particularly if you are on a RISE with SAP or GROW with SAP agreement, since managed cloud contract terms differ from classic on-premises agreements in ways that are not always intuitive.

Vendor Tool Certification

SAP’s partner program rules now explicitly name certain extraction technologies as prohibited. When evaluating third-party connectors, ask vendors directly whether they have already shipped a non-ODP-RFC extraction path — not whether one is “on the roadmap.” A roadmap commitment is not a pipeline that runs today. This matters especially for teams that already have existing SAP data lake integration contracts with ETL vendors whose connectors were built on ODP-RFC.

Special Considerations for SAP S/4HANA Cloud Customers

If your organization is on SAP S/4HANA Cloud — either the public cloud edition or a RISE-managed private cloud — the ODP-RFC enforcement applies equally, but the remediation path may look slightly different. SAP S/4HANA Cloud public edition customers have less flexibility to install middleware like SLT directly, which makes Datasphere replication flows and BDC / Delta Sharing the practical options rather than just the preferred ones.

Additionally, SAP S/4HANA Cloud contracts often bundle certain integration capabilities that on-premises customers pay for separately. It is worth reviewing what is already included in your subscription before purchasing additional Datasphere or BDC capacity. Some RISE customers have found that their contract already includes a meaningful Datasphere entitlement that was not being used.

The Practical Sequence: What to Do This Week

Regardless of where you are in your SAP S/4HANA Implementation journey — live production, mid-project, or early planning — the sequence below applies.

1. Run the SAP self-assessment (Note 3439624). Find out whether anything in your current landscape uses ODP-RFC before the next support package arrives and takes down a pipeline unexpectedly. This is a free check that takes under a day to complete.
2. Confirm your licensing position in writing. Before you choose an architecture, get clarity on your HANA tier, SLT entitlement, and any Datasphere or BDC capacity that is already bundled in your contract.
3. Pick an architecture based on your actual situation. Datasphere replication flows for teams that need to move fast and can absorb the capacity-unit cost. BDC / Delta Sharing for teams building a net-new architecture with a long time horizon. Native CDS / OData rebuild for teams that want maximum vendor independence. ODP-OData as a short-term bridge if your volume allows it.
4. Ask your ETL or connector vendors for a written statement confirming they have shipped a compliant non-ODP-RFC extraction path and that it is available on your current contract version.
5. Verify before migrating to SAP S/4HANA Cloud. If a cloud migration is on your roadmap within the next 12 months, let the target architecture guide your extraction design now. Building an ODP-OData bridge today that you will need to replace again in six months is not a good use of engineering capacity.

 

Questions This Article Answers

The specific questions users ask search engines directly. This blog is structured to answer the following high-intent queries that appear frequently in SAP data integration searches:

•   “What is ODP-RFC and why is it blocked?” — Answered in Section 1 and 2.
•   “How do I extract SAP S/4HANA data to Snowflake or Databricks?” — Answered in Section 3 and 4.
•   “What are the SAP S/4HANA Implementation costs for data lake integration?” — Answered in Section 7.
•   “Does ODP-RFC work with SAP S/4HANA Cloud?” — Answered in Section 8.
•   “What is the alternative to ODP-RFC for SAP data extraction?” — Answered in Sections 4, 5, and 6.

 

The Bottom Line

Hourly extraction from SAP S/4HANA to a third-party data lake is not going away. The interface most of the market relied on to do it just became unavailable, and the replacement options each come with their own cost and complexity profile. The difference between teams that handle this smoothly and those that handle it expensively is almost always the same thing: knowing before you build.

If you are in the middle of a SAP S/4HANA Implementation, treat the ODP-RFC change as a forcing function to get your data architecture right rather than just patched. If you are evaluating a move to SAP S/4HANA Cloud, let the extraction strategy conversation happen before the contract is signed, not after. The licensing and integration questions are easier to answer when you still have negotiating leverage.

The tools exist, the paths are clear, and the compliance position is achievable. What it takes is running the right checks, asking the right vendors the right questions, and locking in your licensing position in writing before your architecture is committed to production.