If your reporting, BI or data-lake pipelines pull data out of SAP, a change SAP made to the ODP-RFC interface may already be affecting them. Here is how to check, what it means, and the sanctioned ways to keep the data flowing.
SAP restricts third-party ODP-RFC extraction from SAP systems. A temporary opt-out runs to the end of 2026, with no extension announced. (SAP Note 3255746)
If your reporting, BI or data-lake pipelines pull data out of SAP, there is a change you need to check this quarter. SAP has restricted the use of the Operational Data Provisioning interface over the RFC protocol, usually shortened to ODP-RFC, for third-party and custom data extraction. The technical enforcement is already in force, and the temporary way around it closes at the end of 2026.
This matters to a Head of Data because it can affect a pipeline that has run quietly for years without anyone touching it. If an extractor you depend on uses ODP-RFC, it can stop returning data, and the first sign may be a dashboard that silently stops refreshing rather than an error anyone is watching for. The good news is that this is checkable. You can establish in days whether you are exposed, and there are SAP-sanctioned ways to keep the data moving.
What exactly did SAP change?
SAP has clarified that the ODP-RFC interface is not released for use by third-party tools or custom extractors to pull data out of SAP ABAP source systems, which includes SAP ECC, SAP BW and SAP S/4HANA. This is set out in SAP Note 3255746. It is a usage restriction on one interface, enforced technically. It is not the removal of the RFC protocol itself, and it does not stop SAP's own supported extraction paths from working.
The timeline is the part to act on. The technical enforcement began in June 2026. SAP provided a temporary opt-out that lets restricted ODP-RFC calls continue until the end of 2026, and SAP has not announced an extension beyond that. So a pipeline that still works today because the opt-out is in place can stop working at the turn of the year.
Why does this put your pipelines at risk?
Because ODP-RFC sits underneath more extraction tooling than most data teams realise. It has been a common way for third-party connectors to read SAP extractors, CDS views and delta queues. Several widely used connectors have offered an ODP-based extraction mode, so the dependency is often inherited from a tool's configuration rather than chosen deliberately. The restriction targets the method, not any one vendor, and most affected vendors have published migration guidance to SAP-sanctioned methods.
The risk, then, is not that SAP has broken your integration on purpose. It is that a pipeline may be relying on an interface that is no longer sanctioned, and neither the dashboard that consumes it nor the people who read that dashboard will necessarily know until the data stops. That is why the first job is to find out, precisely, what you depend on.
How do you check your SAP pipelines for an ODP-RFC dependency?
Treat this as an evidence exercise, not a guess. The aim is a confirmed list of every pipeline that reads from SAP and, for each one, the extraction method it actually uses. You will need SAP support access and system authorisations to do it, so run it with whoever holds those: an in-house SAP Basis team if you have one, or your SAP support partner if you do not.
At the end of that, you should be able to say, with evidence, which pipelines are clear, which depend on ODP-RFC, and which you are not yet sure about. The unsure list is the one to close out first, because uncertainty here is the same as exposure.
What are the compliant alternatives?
If you find a dependency, you have several SAP-sanctioned routes, and the right one depends on the data, the latency you need and the systems you are running:
None of these is a like-for-like swap you make in an afternoon. Each changes how the data lands, how it is modelled downstream and how it is governed, so the move is worth planning rather than rushing under deadline pressure.
Where should you start?
Start with the check, not the rebuild. You cannot plan a migration until you know exactly what depends on ODP-RFC, so the self-assessment and the inventory come first and they are worth doing now, while the opt-out still gives you room.
That last point is the one worth sitting with. The reason an interface change can threaten a dashboard at all is that the extraction, the modelling and the serving are wired together tightly enough that a change at the source breaks the whole chain. The right tools depend on your environment, not a vendor preference. We build this across the modern data stack and choose what fits the data you already hold and the systems you run. In practice, moving SAP data onto a governed platform on Snowflake or Databricks, modelled with dbt, with extraction through a SAP-sanctioned method, means the serving layer in a tool like Qlik is insulated from how the data left SAP in the first place.
ODP-RFC is a specific, checkable change with a fixed deadline. Find out whether you depend on it, close out anything you are unsure about, and use the move as the reason to put your SAP data somewhere a single interface change can no longer take a pipeline down.
Where does your SAP data go once it leaves SAP?
Whatever method you extract with, the data still needs a home a future interface change cannot take down. That connected foundation is what we build. See where your wider operation stands, or read the full report.
