What the note says
SAP Note 3255746 defines the RFC modules of the ODP Data Replication API as being exclusively for data transfer between SAP applications. Customers and third-party applications may not use ODP-RFC to access SAP ABAP systems, whether on premise or in a private cloud.
The note has existed since 2022. What changed in 2026 is enforcement. On 9 June 2026 SAP shipped patches that block unrestricted calls from non-SAP applications relying on the ODP-RFC interface, turning a contractual position into a technical one.
The timeline
| Date | What happened |
|---|---|
| 2022 | Note 3255746 published. ODP-RFC declared SAP-to-SAP only. |
| 9 June 2026 | Patches ship. Unrestricted third-party ODP-RFC calls blocked. |
| December 2026 | The time-limited revert option expires. |
Which tools are affected
Any pipeline extracting from SAP through ODP over RFC. In practice that includes Fivetran, Microsoft Azure Data Factory, Qlik Replicate and Informatica, among others. Vendors have published their own guidance. The constraint sits in the interface rather than in any particular product.
If your SAP extracts reach Snowflake through an RFC-based ODP pipeline, you are in scope, including where the data arrives through an intermediate warehouse or a data share.
What the temporary revert does
SAP made available a time-limited option to restore unrestricted ODP-RFC calls, which many organizations applied in June to keep reporting running. It buys time rather than solving the problem. It expires in December 2026, and pipelines depending on it stop working at that point.
Two things follow. If you applied the revert, you now have a fixed deadline rather than an open question. And the remediation work has to be planned now, because designing and building a replacement extraction path across a real landscape takes months.
What does not work as a fix
Switching third-party ETL tools does not help. The note addresses customer and third-party access to the interface, and a different tool making the same calls falls under the same restriction.
Waiting for the revert to be extended is also a poor plan. SAP may or may not extend it, and building on that assumption puts your reporting estate on someone else’s roadmap decision.
Compliant replacements
The right route differs by source system, latency requirement, and license position. The serious options:
| Option | What it is | Fits when |
|---|---|---|
| SAP BDC Connect for Snowflake | Governed zero-copy sharing of SAP data products into an existing Snowflake account | You want SAP semantics preserved, no duplication and a sanctioned path |
| SAP Snowflake | Snowflake delivered within SAP’s commercial and architectural envelope | You are consolidating commercially with SAP |
| CDS views / OData | Application-level extraction through the SAP-endorsed view layer | S/4HANA especially, where the CDS layer is rich |
| SLT | Trigger-based replication at table level | Low-latency requirements at table level |
| Database-level replication | Replication beneath the application layer | Check licensing and semantic implications before designing it in |
A fuller side-by-side, including cost and latency characteristics, is in SAP data extraction options compared.
What to do now
- Establish your exposure: which pipelines use ODP-RFC, what they feed, and whether the revert was applied. This usually takes less time than people expect, and everything else depends on it.
- Separate the urgent from the merely broken. Not every affected feed matters equally, so rank them by the decisions that depend on them.
- Choose a route per source rather than per landscape. A single connector decision across a mixed estate is how organizations end up paying for latency they do not need.
- Sequence the remediation against December. Design and build take considerably longer than the patch did.
If you also run SAP BW, this decision ties into the BW 2027 maintenance question, and it is worth taking both together rather than solving the feed twice. See BW migration paths compared.