DataViz Migration - migrating from SAP BO to Power BI

SAP BusinessObjects estates typically hold several years’ worth of modeling: universes, Web Intelligence reports, business objects, calculations, filters, prompts, and semantic layers.

{openAudit} analyzes universes, reports, and usage logs to reconstruct the dependencies between data sources, business objects, and visualizations.

Key point: the migration covers universes, business objects, and business rules just as much as reports.

SAP BusinessObjects analysis prerequisites

The analysis requires access to the SAP BusinessObjects services, technical repositories, and the audit database.

The extractors run within the Client’s environment. The collected metadata can be anonymized before processing.

Good to know: only technical metadata is used.

Estate analysis

The analysis covers Web Intelligence reports, UNV and UNX universes, Data Providers, business objects, variables, filters, prompts, and graphical components.

Technical dependencies and observed usage are consolidated into a repository.

Rationalization

Audit logs are cross-referenced with the platform’s metadata.

Unused reports, duplicates, unconsumed objects, and obsolete universes are identified before migration.

Result: a reduced volume to migrate.

Conversion to Power BI

Data Providers are converted into Power BI datasets.

Queries, calculations, and variables are converted into SQL or DAX. Business objects are reconstructed as dimensions and measures.

Dependencies between universes, reports, and data sources are preserved in the target model.

Tables, charts, filters, sections, and layout elements are analyzed and then reconstructed in Power BI.

The conversion relies on {oa-lake}: queries, calculations, and variables are encapsulated as SQL pipelines, and the business objects of the universes feed the interoperable semantic layer of {oa-lake}. Power BI connects to this ready-made model (see below).

Key point: the migration covers both the business layer and the reporting layer.

Validation

Migrations can be carried out with dual SAP BusinessObjects / Power BI execution.

The indicators produced by both platforms are compared during acceptance testing phases.

Tables, filters, and slicers

Conversion of SAP BusinessObjects tables, filters, and sections into Power BI components.

Pie charts

Conversion of SAP BusinessObjects pie charts into Power BI visuals.

Charts

Conversion of SAP BusinessObjects charts into Power BI visuals.

Dashboards

Conversion of SAP BusinessObjects dashboards into Power BI.

{oa-lake}: the foundation of every dataviz migration

Moving from one reporting tool to another meets the immediate need, but it shifts the business logic into a new proprietary model: the next time the tool changes, everything has to be rebuilt again.

That is why every dataviz migration now relies on the {oa-lake} middleware, which plays two roles:

• It encapsulates the intelligence. The queries, calculations, variables, and business rules extracted by {openAudit} are transcribed into SQL and run in {oa-lake} as mini SQL pipelines (a mini ETL), instead of being rewritten inside the target tool.
• It preserves the semantic layer. The semantic layer built up over the years in the source platform (universes, Frameworks, models) is rebuilt in the interoperable semantic layer of {oa-lake}, which then feeds the target tool.

Power BI connects to {oa-lake} and consumes a ready-made model: business objects, KPIs, and security are no longer locked into a new proprietary model.

• Define once, use everywhere: customer, contract, product… one single definition, valid for every consuming tool.
• Centralized KPIs and security: indicators computed once and security applied uniformly, whatever the reporting tool.
• Rationalized data prep: shared SQL mini-pipelines replace the preparation scattered across each tool.
• Interchangeable BI tools: Power BI, Looker, DigDash, or any other tool connects to a ready-made model, without redefining the business logic.
• Managed as code: SQL pipelines and a semantic model in YAML/JSON, versioned in Git and deployed with Terraform.
• AI-ready: the same data and the same semantics feed BI, LLMs, and AI agents.

Key point: migrating to {oa-lake} means migrating one last time. Business logic becomes a company asset, independent from vendors.

Discover {oa-lake} → · SQL interoperability and semantic layer →