Extraction is a project, not a task
Getting SAP data out traditionally means middleware, RFC plumbing, specialist consultants, and a timeline measured in quarters.
Solutions / SAP Data Replication
Your SAP data, in your warehouse. Without RFC, middleware, or a consulting engagement.
Dataddo replicates SAP S/4HANA data into your warehouse, lake, or AI stack through SAP's own standard OData services - read-only, HTTPS, nothing installed on your hosts. True CDC included: inserts, updates, and hard deletes, captured through SAP's official delta framework - so your models and agents always run on current SAP data, not last night's snapshot.
Your SAP team keeps full control of what leaves the system.
The problem
Everyone wants SAP data. SAP makes you earn it.
The most valuable operational data in the company sits in the ERP - and it's the hardest system to get data out of.
SAP just closed the back door
SAP Note 3255746 prohibits third-party tools from using the ODP-RFC interface, and a security patch now actively blocks those calls. If your current extraction tool relies on it, its days are numbered.
The ERP can't take a beating
This is the system that runs the company. Full-table reads on production SAP is a risk nobody wants to own - but skipping deletes and updates quietly corrupts everything downstream.
Read-only, standard-interface extraction isn't a nice-to-have for SAP - it's the only way IT will actually approve it.
SAP Note 3255746
Already compliant. Nothing to migrate later.
SAP no longer permits third-party applications to extract through ODP-RFC, and is actively blocking such calls. The Dataddo connector is not affected - it consumes the ODP framework exclusively through SAP's official OData API on SAP Gateway, exactly the interface the note directs third parties to use. It never uses RFC, for anything.
Replacing an ODP-RFC based extraction tool because of this note? This is the compliant successor.
How it works
Inside SAP: your code, your control. Outside: read-only HTTPS.
The connector reads through SAP's standard OData stack - it never connects to the HANA database directly. On the SAP side, a set of Dataddo ABAP scripts defines an extraction catalog and the CDS views to expose; your SAP team deploys, reviews, and activates them, so what leaves the system is decided inside your walls, by the people who own it. On the Dataddo side, every request is a read-only HTTPS call to your SAP Gateway.
Two extraction methods. Start light, scale to CDC.
| Method | What it captures | Best for |
|---|---|---|
| CDS Views | New and updated rows, by timestamp | Master data, snapshots, low-footprint onboarding |
| ODP (true CDC) | Inserts, updates, and hard deletes, via SAP's delta queue | High-volume or delete-sensitive tables |
Start with CDS Views - the smaller footprint, the safer first step, running the same day the views are activated. Move your big, busy tables to ODP when sync cost matters: after the initial load, SAP never re-reads the base table, so a large table syncs at the cost of its changes, not its size. ODP is also the only method that captures hard deletes, so rows deleted in SAP actually disappear downstream too.
Capabilities
Built for how SAP shops actually work.
A complete, current replica - not a pile of extracts.
Changed rows merge into your destination by key, deletes are honored, and duplicates don't accumulate. What's in your warehouse mirrors what's in SAP.
History when you need it.
CDC captures changes going forward; one-time backfills load the history, so replicas start complete. A full re-sync is always available when you want a clean slate.
Your SAP lives behind a firewall? Good.
Dataddo's data plane deploys on-prem or in your own cloud, next to the SAP system, managed from a single cloud control plane. SAP data that must not leave your perimeter, doesn't.
Any destination, including AI.
Warehouses (BigQuery, Snowflake, Databricks, and more), lakes, dashboards, and AI models and agents directly. SAP order and inventory data grounding your AI is the point, not a follow-up project.
Fresh on your schedule.
Syncs run on the schedule you set. Consume deltas daily or hourly - SAP's delta queue holds changes until you collect them, so nothing is missed between runs.
Enterprise-grade by default.
SSO and enterprise IAM, account- and action-level audit logs, webhook alerts into your monitoring - the same governance as every other Dataddo pipeline. SOC 2, ISO 27001, GDPR.
Time to value
One transport request. Not a middleware project.
Your SAP team deploys the ABAP scripts through the normal transport and review process - standard objects, standard OData stack, fully inspectable. From there, connecting a CDS view is a task in Dataddo's UI, not a specialist engagement. The first tables can be flowing to your warehouse the same week the scripts land, and every table after that is configuration, not consulting.
Beyond SAP
The rest of the legacy estate comes along.
SAP is usually the biggest legacy system in the building - rarely the only one. The same platform, the same on-prem deployment, and the same governance replicate from Oracle, SQL Server, Informix, and other foundational databases most enterprises still run.
See how Dataddo modernizes the rest of the legacy estate, including a 600M-row Informix migration for a European insurer. See Legacy Modernization →
Scope your SAP replication in one session.
Bring your S/4HANA landscape, your table list, and your compliance constraints. Leave with an extraction architecture - CDS views, ODP, or both - and a POC plan.