SAP Data Intelligence
As of 2026-08-14T00:00:00Z
What is SAP Data Intelligence?
SAP Data Intelligence — SAP Data Hub before a 2019 rename — is a containerised data orchestration product: a graphical pipeline Modeler, a metadata catalogue, and an execution runtime that runs operators on Kubernetes.
What it is
SAP Data Intelligence — SAP Data Hub before a 2019 rename — is a containerised data orchestration product: a graphical pipeline Modeler, a metadata catalogue, and an execution runtime that runs operators on Kubernetes. It was SAP's answer to the problem of moving and processing data across SAP and non-SAP systems without routing everything through a data warehouse first, and it came in two forms: Data Intelligence Cloud, run by SAP, and an on-premise edition customers ran themselves.
Why it matters now is mostly directional. The capabilities that made Data Intelligence distinctive — pipeline orchestration, connectivity breadth, metadata cataloguing — are the same capabilities SAP has been building into SAP Datasphere as replication flows, transformation flows, task chains and the catalogue. For an estate running Data Intelligence today, the strategic question is therefore not "how do we get more out of it" but "what does each pipeline become on the other side". That question has real content: a Data Intelligence graph with custom Python operators does not map one-to-one onto a Datasphere flow, and the operators that carried business logic are exactly the ones with no direct successor.
The pattern is familiar, and worth naming. This is the same shape as the BW-to-Datasphere and BusinessObjects-to-SAC transitions: a capable product whose functions are re-expressed inside a newer, more consolidated platform, with a residue of custom work that has to be rebuilt rather than converted. The residue is where the effort and the risk sit, and it is almost never visible in a licence-level comparison.
What a consultant should actually inventory. Count the graphs, then classify them: pure movement (source to target, no logic) usually re-expresses cleanly as a replication flow; transformation graphs re-express as transformation flows with effort proportional to the logic; custom operators — Python, shell, bespoke containers — are rebuilds. Add the connections, because connectivity coverage is where a migration plan most often discovers a gap late.
Treated this way, Data Intelligence is not a dead subject. It is a live one, on the migration side of the ledger — which is precisely where this market pays.
Why it matters
- 374 community articles discuss it and no Academy card covered it. For estates that run it, the value is entirely in the migration inventory — and the custom operators are the part with no successor.
Key points
- Formerly SAP Data Hub; renamed SAP Data Intelligence in 2019. Two forms: Cloud (SAP-run) and an on-premise edition.
- A containerised orchestration product: graphical pipeline Modeler, metadata catalogue, operators executed on Kubernetes.
- Its capabilities re-appear inside SAP Datasphere as replication flows, transformation flows, task chains and the catalogue.
- 🔴 Custom operators (Python, shell, bespoke containers) have no direct successor — they are rebuilds, not conversions.
- The migration inventory that predicts effort: graph count, classified into movement · transformation · custom, plus connection coverage.
Common pitfalls
- Sizing by graph count alone — Signal: "We have 240 graphs, so it is a 240-unit migration" Fix: Classify first. Movement, transformation and custom-code graphs differ by an order of magnitude in effort.
- Assuming feature parity in Datasphere — Signal: A mapping table with no empty cells Fix: Custom operators are the empty cells. Find them before committing to a plan.
- Confusing Data Intelligence with Data Services — Signal: The two used interchangeably in a landscape document Fix: Different products, different eras, different successors. Data Services is the classical ETL tool; Data Intelligence is the containerised orchestration one.
Decision framework
| Decision | Option A | Choose A when | Option B | Choose B when |
|---|---|---|---|---|
| What to do with an existing graph | Re-express as a Datasphere flow | Movement or declarative transformation — the logic is expressible in the target | Rebuild | The graph carries custom code; there is no conversion path, only a re-implementation |
| How to size the migration | By graph count | Only defensible once the graphs are classified — an unclassified count says nothing | By custom-operator inventory | The default: the custom residue predicts the effort far better than the total |