The migrator inspects your SAP BW metadata instead of your screens: InfoObjects, ADSOs, InfoCubes, transformations, DTPs and process chains, plus the ABAP attached to routines. Claude explains what each object does and drafts the Databricks equivalent. Every conversion arrives as a proposal with its source, its original code and a confidence flag, for a human engineer to approve.
Years of InfoCubes, DSOs, transformations and ABAP routines encode business rules nobody wrote down and nobody remembers. When the decision to move to Databricks lands, the first phase of the project is not engineering, it is reverse engineering: opening transformation after transformation in the GUI, reading start routines, and asking former consultants what a field was meant to do. Most migrations stall there, or get rescoped into a lift-and-shift that carries the same mess into the lakehouse.
Start, end, field and expert routines carry the rules that matter. No automated converter reads them, so they get rediscovered by hand, or silently dropped and found again during reconciliation.
With several thousand objects and no reliable map, teams migrate everything, including the reporting layer built for a process that ended years ago. Scope becomes a default rather than a decision.
Three engineers convert the same transformation pattern three different ways. The work is slow, inconsistent, and the result is a lakehouse that is as hard to maintain as the system it replaced.
The migrator reads BW repository tables and transport exports to build a dependency graph of the whole landscape: what feeds what, which objects are orphaned, which chains still run, and where the logic sits. Claude then works over that graph. It does the reading, the drafting and the bookkeeping. It does not silently rewrite business rules, and where the logic is ambiguous it says so and asks rather than guessing.
InfoObjects, ADSOs and classic DSOs, InfoCubes, MultiProviders and CompositeProviders, transformations, DTPs and process chains, read from repository tables or transport exports rather than clicked through by hand.
A full dependency map across the landscape, with orphan and dead-object detection, so you can decide what is in scope before anyone commits to a migration plan.
Start, end, field and expert routines are parsed, explained in plain language, and translated into PySpark or Databricks SQL, with the original code kept alongside the output.
Delta table DDL under Unity Catalog, ingestion and transformation notebooks, and job definitions that reproduce the process chain sequence.
Every generated object carries its source object, the original logic and a confidence flag. An engineer approves, edits or rejects, instead of reading raw output cold.
An object inventory, the lineage map, and a per-object record of what was converted, what was dropped and why. The audit trail writes itself as the work happens.
SAP BW on HANA or BW/4HANA is read through repository metadata and transport exports. The target side is Unity Catalog, Delta Lake, PySpark and Databricks SQL, orchestrated with Workflows and deployed with Asset Bundles. Claude does the ABAP comprehension and code generation, driven from Python. Data movement out of SAP stays with whichever extraction path you already own, an ODP-based connector, a third-party extractor or the SAP and Databricks integration; the migrator generates against that landing zone rather than replacing it.
If you are scoping a BW decommissioning, get in touch for a walkthrough. The usual starting point is a short assessment run against a metadata export from your BW system, which tells you how many objects are actually in scope before anyone commits to a migration plan.