Change Data Capture

SAP knows what changed.
We read what it wrote.

Every other CDC tool sits outside SAP and tries to infer what happened from database transaction logs. DataXover reads the source SAP wrote — change documents that record exactly what changed, who changed it, when, and in what business context.

That's not a technical distinction. That's the difference between knowing and guessing.

The Problem

Database logs tell you a row changed. They don't tell you why.

Fivetran, HVR, and every database-level CDC tool work the same way. They sit outside your SAP system and read database transaction logs — redo logs, transaction logs, depending on your database backend.

When a sales order is modified in SAP, the database log records that rows changed in VBAK, VBAP, and possibly a dozen other tables. It records the before and after values. It does not record what business event caused it. It does not record which SAP user initiated it. It does not record the business context that SAP tracks natively.

SAP is database-agnostic.
The same SAP system might run on HANA, Oracle, SQL Server, or DB2. Database-level CDC tools have to handle each differently — different log formats, different access methods, different behaviors. The tool that works on your Oracle-backed ECC system may behave differently when you migrate to HANA. DataXover doesn't care what database SAP runs on. It operates above the database layer entirely.
SAP's business logic lives in ABAP, not in database logs.
A change document in CDHDR/CDPOS tells you that a sales order was changed, which fields changed, who made the change, when, and the business context. A database log tells you rows changed. These are not the same thing. One is a business event. The other is a storage event.
BSEG isn't what it looks like at the database layer.
In SAP ECC, BSEG is a cluster table — SAP packs multiple logical records into single database rows and unpacks them at the application layer. A database-level CDC tool reading BSEG sees packed cluster data, not the business records SAP presents to the application. In S/4HANA, SAP converted BSEG to a transparent table (ACDOCA) — the cluster problem goes away, but the table is even larger because it holds the complete universal journal. Either way, database-level CDC tools are reading at the wrong layer. DataXover reads at the application layer through standard ABAP, where the unpacking is already done on ECC and the transparent table is accessed natively on S/4HANA.
Full rebuilds break the economics.
Database-level CDC tools typically charge based on rows processed. A full rebuild — schema change, data correction, disaster recovery — processes every row in every table. On BSEG in ECC or ACDOCA in S/4HANA, with billions of rows, that's a bill spike that makes finance teams uncomfortable and Basis teams nervous. DataXover doesn't meter rebuilds. They're included.

How It Works

SAP has been writing change documents since the beginning. We read them.

When a user modifies a business object in SAP — a sales order, a vendor master, a material record, a financial posting — SAP writes two records:

CDHDR — Change Document Header
Object class, object ID, transaction code, user name, date, time. The who, what, and when of the business event.
CDPOS — Change Document Item
Table name, field name, change indicator. Pinpoints exactly which records and fields changed since the last run.

SAP has maintained this audit trail across every release, every database backend, every deployment model. It is the authoritative record of what happened in the system — written by SAP at the moment the business transaction posted, before any downstream system sees the data.

DataXover reads SAP's change documents (CDHDR/CDPOS) to identify which records changed since the last extraction run, retrieves the current state of those records, and delivers them to your destination with insert/update/delete flags. Your destination stays current. Your SAP system is not burdened with continuous extraction of unchanged data.

This is change data capture the way SAP intended — read from SAP's own change record, not inferred from database transaction logs.

Coverage

What about tables without change documents?

Most SAP business objects generate change documents natively. Sales orders, purchase orders, vendor master, customer master, material master, financial documents — the objects that matter most for analytics generate CDHDR/CDPOS records automatically.

For tables that don't generate change documents natively, your Basis team can enable change document tracking via transaction SCDO. This is standard SAP functionality — no customization, no development, no DataXover involvement. Your Basis team configures it in SAP and DataXover reads the records that result.

If a table doesn't support change documents and SCDO enablement isn't appropriate for your use case — full extraction on a schedule is always available. DataXover handles both modes from the same profile configuration.

Operations

Background jobs only. Your users won't feel it.

Configurable frequency. No platform minimum.
Run every 5 minutes, every 15 minutes, hourly — whatever fits your use case and your system's available background work process capacity. The schedule is yours to set and adjust at any time.
Watermark-based. No gaps. No duplicates.
DataXover maintains a high-water mark for each CDC profile. If a job fails or the system goes down, the next run picks up from the last successful point. No changes are missed. No records are processed twice.
Automatic transition from seeding.
When a large table seeding job completes, CDC starts automatically. DataXover captures a timestamp at the start of seeding — when the last file is delivered, CDC picks up from that timestamp. No manual switchover. No gap in the change record.
Full audit trail.
Every CDC run — records processed, changes detected, delivery status, elapsed time — logged automatically. The audit trail your compliance team needs, generated without additional configuration.

The Competitive Reality

Fivetran and HVR read database logs. DataXover reads change documents.

This isn't a feature comparison. It's an architectural difference that matters in SAP environments specifically.

Fivetran acquired HVR to do one thing: finally own SAP data movement. But the underlying approach — database-level log reading — is the same, and so are the SAP-specific problems it creates.

DataXover was built from the ground up for SAP. CDHDR and CDPOS aren't an integration — they're the foundation. The architecture that makes DataXover CDC work is the same architecture that makes everything else work. It's not bolted on. It's how the platform thinks.

Change data capture built for SAP.

Not adapted for it. Built for it.

Request Consideration Explore the technology