BW to Datasphere extracts the metadata straight out of the BW dictionary, builds one dependency graph of the whole landscape, and drafts the Datasphere artifacts that come out of it. Every ABAP routine gets read, explained in plain language and re-expressed as SQL. Nothing is auto-promoted: a modeller accepts or rewrites each artifact before it goes anywhere.
A BW system that has been live for fifteen years is not a data model. Thousands of InfoObjects, aDSOs, InfoCubes, transformations and BEx queries, most of them built by people who left years ago, with the business logic buried in ABAP rather than in anything a modeller can read. Teams either lift the mess across unchanged or freeze, because nobody can say with confidence what a given transformation actually does.
Transformation logic sits in start, end, expert and field routines. Core Datasphere has no ABAP runtime, so every routine has to be re-expressed as a SQL view or a SQL Script table function, by hand, one at a time.
Query and DTP statistics rarely make it into the scoping exercise. Dormant InfoProviders get migrated at full cost alongside the ones the business actually opens every morning.
Which InfoObjects feed which aDSO, which transformation touches which field, which BEx query breaks if you drop something: today that answer comes from clicking through BW Modeling Tools object by object.
The agent treats the BW repository as its input corpus. It extracts metadata from the dictionary tables, resolves the full lineage, and produces the things a migration team actually argues over: a scoped object inventory, an impact and lineage map, and a first-pass classification of every object into migrate, redesign, retire, or replace with a replication flow. Claude then does the part that has always been manual.
Pulls BW metadata (RSTRAN and routine source, RSDODSO, RSDCUBE, RSDIOBJ, RSPC process chains, RSZ query components) and resolves lineage from source field all the way to the BEx query element.
Combines the object graph with query and DTP execution statistics, so retire, redesign and migrate candidates are proposed on evidence rather than on who shouts loudest in the workshop.
Claude reads each routine in the context of its transformation and the source and target field mappings, then produces a documented SQL view or SQL Script table function plus a plain-language description of the original intent.
Emits Datasphere-importable CSN/JSON for local tables, views and associations, so the target model arrives as deployable definitions instead of a slide deck of recommendations.
Flags the staging layers where the right answer is not to migrate the BW object at all, but to replicate the underlying source table or CDS view directly into Datasphere and drop the BW hop.
Every generated object carries its source ABAP, the translation reasoning and a confidence flag. A modeller accepts or rewrites it, and that decision feeds back as context for the objects still in the queue.
BW 7.5 on HANA and BW/4HANA as the source, read through the dictionary tables and object exports. Datasphere as the target, with CSN as the interchange format and the Datasphere CLI for deployment. Extracted metadata and generated artifacts live in a versioned repository, so every migration decision is diffable and reviewable.
You get the object inventory, the dependency graph and a sample of translated transformations back. Judge the quality of the output on your own landscape rather than on a demo dataset. Contact Intellus to scope a first pass.