Your SAP Data is Yours. Getting it out shouldn't be hard
There are more ways to get data out of SAP than there used to be — and fewer that still work the way they used to. ODP, ABAP extractors, CDS views, Datasphere, third-party replicators, direct DB reads. Each has tradeoffs. This page sorts them out so you can figure out what actually fits your situation.
30 years in SAP. We solve problems. Sometimes our tools are the answer
Reference Guide · Updated April 2026
A Field Guide to SAP Data Extraction
There are eight common ways to get data out of SAP. Each has trade-offs in performance, complexity, and cost — and after nine years of warnings, SAP Note 3255746 is no longer just policy. SAP is programmatically restricting the ODP interfaces that most third-party replication tools depend on. This page is a plain-language reference to where each method stands now.
We sell one of these methods. We’ll tell you which. But the point of this page is to help you make a defensible decision — not to make our case.
ODP / ODQ via RFC
Operational Data Provisioning, Remote Function Call
The framework most third-party replication tools were built on for the past decade. It works well, technically. SAP Note 3255746 prohibits its use by third-party applications — and SAP is now moving from policy to programmatic restriction. After roughly nine years of warnings, the interface is being closed. Tools in this category include the original SAP CDC connectors used by Azure Data Factory, Qlik Replicate, and several others. If your data flows depend on one of them, the question isn’t if they break — it’s when, and what’s already in motion to replace them.
SAP Datasphere Replication Flow
SAP-native, the path SAP recommends
SAP’s preferred answer to the ODP question. Datasphere can replicate from SAP sources to non-SAP targets including Snowflake, Databricks, and the major cloud lakes. The trade-offs are licensing cost, data egress charges, and a documented cap on concurrent replication threads that becomes a constraint in high-volume environments. Compliant by definition; expensive in practice.
Application Layer Extraction
Through SAP’s sanctioned application interfaces
Extraction through the SAP application layer using sanctioned interfaces — not the database, not ODP. This is the architectural approach SAP’s own integration vision points to and is fully outside the scope of Note 3255746’s prohibition. This is what Simplement Roundhouse™ does. CData also uses a variant of this approach via the SAP Gateway. We’re calling our own product out here because we said we would; the broader point is that this category exists and is compliant by design.
CDS Views via OData
SAP’s public REST surface for ABAP data
SAP exposes CDS Views through an officially-supported OData API. It’s public, stable, and explicitly recommended as the path third-party applications should be built on. The trade-off is volume: OData over HTTP is fine for smaller pulls and integration scenarios, but is not built for moving large fact tables on a schedule. AWS AppFlow uses this path. AWS itself is candid that it isn’t suited to large-scale ingestion.
Database Log Reading
CDC at the database, beneath the application
Reads change records directly from the SAP database transaction log (HANA, Oracle, DB2, SQL Server). Performant, real-time, and bypasses ODP entirely — which is why HVR, Qlik Replicate, and Fivetran HVR each support a log-reading mode. The compliance answer is more nuanced than the marketing usually admits: log reading sits outside Note 3255746, but raw-table replication misses business logic that lives in the application layer (clustered tables, currency conversion, organizational structure). It works, it scales, but the data on the other side is rarely what your business users expect.
SAP BW / BW Bridge
SAP’s legacy warehouse, sometimes still the answer
BW remains a perfectly compliant way to extract SAP data — it’s SAP’s own warehouse. The reason it’s losing share is operational, not legal: schedule-bound, ABAP-heavy, and a long way from the modern lakehouse pattern most data teams want to live in. Most of our customers who switched did so because they were tired of midnight loads and 80% of their reports were redundant; not because BW didn’t work.
Custom ABAP, IDocs, RFC Function Modules
The do-it-yourself path
Write your own ABAP. Push IDocs to a queue. Expose RFC-enabled function modules that downstream code can call with pyrfc. None of this is prohibited by Note 3255746 — it’s how SAP itself extends. The cost is the team and the timeline. We’ve seen Big 4 firms charge well into seven figures to build and maintain something a packaged tool would deliver in a fraction of the time. Right answer for some shops; wrong answer for most.
Generic ETL with SAP Drivers
SSIS, Informatica, Talend with SAP connectors
The traditional path: a general-purpose ETL platform with an SAP connector bolted on. Compliance depends entirely on which interface the connector chooses — some go through ODP and inherit Note 3255746’s problems; others use OData or RFC and don’t. If you’re running one of these, the right question for your vendor is specific: which SAP API are you calling, and is it covered by Note 3255746?
Where to start
If you're running a tool that uses ODP RFC, the priority is to know it and to plan a path off it. If you're evaluating new tools, ask the vendor in writing which SAP interface they call. If your reporting workloads are heavy and the answer needs to be in Snowflake, Fabric, or Databricks at sub-minute latency — we'd like to talk to you. If they don't, we hope this page was useful anyway.