DataViz Migration - migrating from SAP BO to GCP Looker

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

{openAudit} analyzes these components to reconstruct the dependencies between data sources, universes, reports, and observed usage.

Key point: universes and business objects are generally the primary source of information for reconstructing the target model.

SAP BusinessObjects analysis prerequisites

The analysis relies on 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 or broken reports, duplicated reports, unconsumed objects, obsolete universes, etc. are identified before migration.

Result: a massive reduction in the volume to migrate.

Conversion to Looker

Data Providers, business objects, and queries are converted into Looker components.

Dimensions, measures, joins, and calculations are reconstructed in the LookML models.

Dashboards, filters, prompts, tables, charts, and navigation mechanisms are reconstructed from the SAP BusinessObjects reports.

The functional organization of the universes carries over into the target platform’s folders, Explores, and business catalogs.

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}. Looker connects to this ready-made model (see below).

Key point: functional objects and reporting components are reconstructed from the SAP BusinessObjects universes and reports.

Validation

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

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

SAP BusinessObjects prompts

SAP BusinessObjects prompts are converted into Looker’s native filters.

Value lists and input parameters are preserved.

Business objects and LookML models

Queries, business objects, dimensions, measures, and joins are converted into LookML components.

Functional structure

The organization of the universes is rebuilt as Explores, dimensions, and measures.

Pivots and matrix analyses

Cross-tabs and multidimensional analyses are converted into Looker’s pivot mechanisms.

Charts

Trend lines and comparative analyses are rebuilt from the indicators identified in the reports.

Bar charts

Bar charts are adapted to Looker’s visualization components.

Pie charts

Pie charts are converted into Looker’s native visualizations.

{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.

Looker 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 →