Concept card

SAP Data Services (BODS)

As of 2026-08-14T00:00:00Z

What is SAP Data Services (BODS)?

SAP Data Services, still universally called BODS after the BusinessObjects Data Services name it carried, is the classical enterprise ETL tool of the SAP estate: a thick Designer client, jobs made of dataflows, a Job Server that executes them on a schedule, and a repository that holds the metadata.

What it is

Its relevance is that it is still there. Data Services rarely appears in a strategy deck, and it rarely disappears from a landscape either. It is the tool that loads the warehouse overnight, cleanses the customer master, matches and deduplicates addresses, and feeds a dozen downstream systems nobody remembers subscribing. In a migration inventory it is routinely discovered late, because the people who built it have often moved on and the jobs simply keep running.

The data-quality logic is the asset, and the trap. Movement is the easy part of a BODS estate: a dataflow that reads a table and writes another has an obvious expression in a Datasphere replication flow. What does not move easily is everything BODS carries around the movement — address cleansing with reference directories, match-and-consolidate rules, custom functions written in the Data Services scripting language, and the accumulated exception handling that makes a nightly load survive bad input. That logic encodes years of business decisions, and it is usually undocumented outside the jobs themselves.

How to read a BODS estate. Inventory jobs, then dataflows, then — the number that matters — custom functions and data-quality transforms. A landscape of two hundred dataflows that are all straight movement is a small migration. A landscape of forty dataflows with heavy cleansing and match logic is a large one. The ratio, not the total, is the estimate.

For consultants, BODS sits in the same category as BusinessObjects and BEx: legacy in roadmap terms, live in operational ones, and valuable precisely because the people who can read it are becoming scarce while the estates keep running.

Why it matters

It is the undocumented layer a migration finds late. The cleansing and match logic inside BODS jobs encodes years of business decisions that exist nowhere else.

Key points

The classical SAP ETL tool: Designer client, jobs made of dataflows, Job Server, metadata repository.
Still called BODS after its BusinessObjects Data Services era; SAP Information Steward is the profiling and data-quality companion.
Straight movement re-expresses cleanly as a Datasphere replication flow.
🔴 Address cleansing, match-and-consolidate rules and custom scripting functions are the part with no clean successor — and the part that is undocumented.
Estimate by the ratio of data-quality dataflows to movement dataflows, never by the total count.

Common pitfalls

Discovering BODS late — Signal: A migration plan that never mentions the nightly loads Fix: Inventory the schedulers early. Jobs that simply keep running are the ones nobody lists.
Assuming cleansing rules are documented — Signal: "The rules are in the design document" Fix: They are in the jobs. Budget the archaeology before the rebuild.
Confusing Data Services with Data Intelligence — Signal: The two treated as one product with two names Fix: Different products and different eras: classical batch ETL versus containerised orchestration.

Decision framework

Decision	Option A	Choose A when	Option B	Choose B when
Where does the data-quality logic go	Rebuild in the target platform	The rules are still business-current and someone can restate them	Keep BODS for that step	The rules are load-bearing and undocumented — retire the movement first, the quality logic later
How to inventory	Count dataflows	Enough only for a landscape sketch	Count custom functions and DQ transforms	The default: this is the number that predicts the migration effort

Sources

Open in the app →