SAP data into Databricks or Snowflake: the options in 2026

There are four ways to get SAP ECC, S/4HANA or BW data into Databricks or Snowflake in 2026. SAP Business Data Cloud can share SAP data products with Databricks or Snowflake without copying them. You can extract through ODP over OData, released APIs or CDS views. SLT can replicate tables. Or a third-party tool can do the extraction on top of one of these interfaces. The choice depends less on the target platform than on licensing. Since June 2026 SAP blocks third-party use of ODP over RFC, so check which interface every pipeline uses before choosing a tool.

This article covers each route, how they compare, and the SAP-specific problems that decide whether the result can be trusted.

What changed for SAP data integration in 2025 and 2026?

Three things changed.

First, SAP built its own outbound route to both platforms. SAP Business Data Cloud (BDC) exposes SAP data as data products, and both lakehouse vendors now take them without copying. Databricks announced general availability of SAP BDC Connect on 6 October 2025. Snowflake lists the SAP BDC zero-copy connector as generally available from 4 May 2026.

Second, SAP enforced its API policy. SAP Note 3255746 says the RFC modules of the ODP data replication API are not permitted for customer or third-party applications. SAP’s API policy overview for user groups (May 2026) calls ODP-RFC “the only unpermitted interface so far”. It describes a security patch shipped on 9 June 2026 that blocks these calls, and a temporary suspension of the patch available until 31 December 2026.

Third, the sharing protocol was renamed. Databricks and the Linux Foundation announced OpenSharing as the successor to Delta Sharing in June 2026, and the Databricks SAP documentation now uses the new name. Older material that says Delta Sharing describes the same integration.

How does SAP Business Data Cloud share data with Databricks and Snowflake?

BDC packages SAP data as data products. SAP-managed data products come with SAP’s semantics. Customer-managed data products are ones you build yourself, for example in Datasphere. You do not query SAP tables from the lakehouse. You activate a data product in BDC and share it.

Databricks: SAP Databricks or BDC Connect

There are two variants. SAP Databricks is a Databricks edition sold inside BDC. BDC Connect links BDC to a Databricks workspace you already run. For the connector, the Databricks documentation says the data “remains in place and is not moved or replicated”, and the workspace must be enabled for Unity Catalog. Each shared data product appears as a catalog in Unity Catalog. Table and column comments, primary and foreign keys, and sap.PersonalData.* governance tags are synced as read-only metadata. Foreign keys that point to a table in a different share are not supported. Sharing works in both directions, so you can publish Databricks results back to BDC as data products.

Snowflake: SAP Snowflake or BDC Connect for Snowflake

Snowflake has the same two variants. SAP Snowflake is Snowflake sold inside BDC as an SAP solution extension, aimed at new Snowflake customers. SAP BDC Connect for Snowflake gives existing Snowflake accounts access to SAP data products. Both are zero-copy and bidirectional, and they work across clouds and regions. Snowflake documents both as generally available in all AWS, Azure and GCP commercial regions. They are not available on Virtual Private Snowflake, in government regions or in China.

What to check before you commit to BDC

• Coverage. Check which SAP-managed data products exist for your source system and release, and whether they contain the fields your reports use. Anything missing becomes a customer-managed data product that you build.
• Licensing. BDC is a separate SAP subscription. Price the BDC capacity you need alongside the Databricks or Snowflake consumption.
• Source release. SAP’s onboarding material is written around S/4HANA Cloud Private Edition. If you run ECC or an older BW release, ask SAP what is supported for your release before you plan anything.
• Downstream copies. Zero-copy describes the share. Once a pipeline in Databricks or Snowflake writes SAP data into its own tables, you hold a copy, and your agreement with SAP decides what you may do with it.

What are the extraction routes outside Business Data Cloud?

ODP over OData, CDS views and released APIs

ODP (Operational Data Provisioning) is SAP’s framework for full and delta extraction from extractors, ABAP CDS views and BW objects. Delta comes from the operational delta queue, so you do not need timestamp watermarks. SAP’s distinction is about the transport. At the June 2026 API policy webinar, as reported by ASUG, SAP said ODP over OData “remains valid and unrestricted”. ODP over RFC is the blocked one. The same SAP deck says that OData services, CDS views and custom RFCs you build in your own namespace remain permitted, but custom code that calls SAP’s own APIs still has to comply with the policy.

Some cloud connectors already use ODP over OData. The AWS Glue SAP OData connector reads ODP-enabled entities with full and delta loads. For plain OData services, incremental loads need a last-changed field. Test initial-load throughput on your largest objects early, because the first full load is where OData pipelines are most often too slow.

SLT replication

SAP Landscape Transformation Replication Server (SLT) replicates SAP application tables, including tables that have no CDS view, and can act as a source for ODP so other tools read those tables with deltas. It adds a server to run, and you rebuild the business logic in the lakehouse. When a non-SAP tool reads from SLT through ODP, the RFC-versus-OData question above applies to that leg too. Check SLT’s licence terms for your use with SAP.

Datasphere replication flows

If you already license SAP Datasphere, replication flows can write SAP data to non-SAP targets such as cloud object storage, and Databricks or Snowflake load from there. Non-SAP targets need Premium Outbound Integration blocks assigned to the tenant, and these are sized by replicated volume. That is a cost item to price up front, not something to find on the first invoice.

Third-party connectors

Commercial integration tools for SAP fall into three groups: tools that extract at the application layer through ODP, OData or an ABAP add-on, tools that replicate at the database or log level, and cloud-native connectors from AWS, Azure and Google. Evaluate them by the interface they use, not by the logo. One example of why: Microsoft’s documentation for the Azure Data Factory SAP CDC connector states that the patch announced in Note 3255746 blocks the connector, because it calls the ODP RFC API. Ask every vendor in writing which SAP interface their product calls, and how it stays within SAP’s API policy after 31 December 2026.

Reading the database directly

Replicating from the HANA, Oracle or other database under ECC or S/4HANA skips the application layer and its business logic. It is also where licensing risk is highest. If your database licence was bought through SAP as a runtime licence, its terms may limit what non-SAP tools can do with it. Before anyone reads or replicates the database directly, get SAP’s written position for your contract.

How do the options compare?

Approach	Freshness	Semantic richness	Licensing risk	Cost and ops effort	Lock-in
BDC with SAP Databricks or SAP Snowflake	Near real time, data shared in place	High: data products with SAP semantics	Low, supported by SAP	BDC subscription plus platform consumption, low pipeline effort	High: tied to BDC and its data products
BDC Connect to an existing workspace or account	Near real time, data shared in place	High	Low, supported by SAP	BDC subscription, low pipeline effort	Medium to high
Datasphere replication flows to object storage	Scheduled or continuous	Medium to high, depending on the source object	Low with Premium Outbound blocks	Volume-based outbound cost, moderate effort	Medium
ODP over OData, CDS views, released APIs	Batch with delta	High for CDS views, medium for others	Low as of SAP’s mid-2026 statements	Your pipelines to build and run, slower initial loads	Low
SLT table replication	Near real time	Low: raw tables	Depends on SLT licence and onward interface	SLT server to run, logic rebuilt in the lakehouse	Low to medium
Third-party tool	Varies	Varies	Depends on the interface it uses	Tool licence plus moderate effort	Medium: tied to the vendor
Direct database replication	Near real time	Low: raw tables	Highest, check your runtime licence	Lowest extraction effort, highest modelling effort	Low

There is no single best row. A common pattern is to use BDC data products where SAP ships them and they cover the reports, and to use ODP over OData or SLT for the gaps. Run the comparison against two or three real reports, not against the vendor diagrams.

What makes SAP data hard once it lands?

Whichever route you choose, the lakehouse team inherits SAP’s data model. These problems recur on every project:

• Raw tables are not the business object. ECC pool and cluster tables cannot be read meaningfully at the database level, so they need the application layer or SLT. CDS views and data products already contain the joins, texts and conversions that raw tables leave to you.
• MANDT. Almost every table carries the client field. Filter on the production client early, or every join silently doubles across test clients that share the database.
• Currency and units. SAP stores amounts with a currency key, and some currencies are stored with shifted decimals (TCURX). Convert with SAP’s rules, or totals will not match SAP reports.
• Deletes and deltas. Delta queues and SLT carry deletes. Watermark-based pulls from plain OData services do not see them. Decide per object how deletes reach the lakehouse.
• Initial loads. The first load of large finance and logistics tables can take days and puts load on production. Agree windows with the SAP Basis team and split loads by fiscal year or company code.
• Reconciliation. Compare totals against the SAP reports finance already trusts, by company code and period, across at least one month-end close.
• Personal data. HR, payroll and customer master data contain personal data. On the Databricks route, SAP’s sap.PersonalData.* tags arrive in Unity Catalog. On every other route, tag and mask those columns yourself before analysts get access.

If the SAP feed is one of many sources, use the same landing conventions, watermark rules and quality gates for all of them. We describe these in designing a metadata-driven ingestion framework. If SAP integration is part of a larger platform move, the reconciliation layers in our Teradata to Snowflake or Databricks playbook apply here too.

How should you decide?

Start with what you already own. If you have, or plan to buy, BDC and the SAP-managed data products cover your reporting, sharing them into Databricks or Snowflake is the lowest-risk route and needs the least pipeline code. If you do not, ODP over OData and CDS views are the safest general route. Add SLT where you need raw tables in near real time. Before 31 December 2026, list every pipeline that still depends on ODP over RFC, including those inside third-party tools, and schedule its replacement. Confirm the licensing position for your own contract with SAP. This article describes SAP’s public statements, not your contract.

Where Duces fits

Our Data & AI practice designs and builds data warehouses and data lakes on-prem or in the cloud, including migration to cloud, data migration and data integration with standard designs, a thorough method and real accelerators. If you are planning how SAP data reaches Databricks or Snowflake, talk to the people who build it.