DataViz Migration - SAP BO, Power BI, Spotfire, or Cognos to an open, interoperable architecture

Data visualization platforms evolve regularly.

SAP BusinessObjects, IBM Cognos, Power BI, or Spotfire may succeed one another within the same Information System. Business objects, calculations, indicators, and business rules generally remain identical from one platform to the next.

{openAudit} analyzes technical repositories, semantic layers, and reports to reconstruct the dependencies between data sources, intermediate processes, and the objects exposed in dashboards.

Key point: the functional components of reporting platforms are extracted and then rebuilt in a format independent of the target technology.

Analysis of the decision-support estate

The parser-based analysis mechanisms cover SAP BusinessObjects universes, Cognos Frameworks, Power BI models, Spotfire Information Links, as well as the associated reports, dashboards, calculations, filters, and business objects.

The collected metadata makes it possible to reconstruct technical dependencies, semantic layers, and business rules.

Rationalization

Technical repositories are cross-referenced with usage logs. Unused reports, duplicates, and obsolete components are identified before the migration phase.

Result: a reduced scope for the actual migration.

SQL transcription

Queries, calculations, filters, aggregations, joins, variables, and business rules are reconstructed in the form of SQL.

The resulting SQL forms an open representation of the functional logic originally carried by the data visualization platform.

This SQL runs in {oa-lake} as mini pipelines, and the business objects from the source semantic layers feed its interoperable semantic layer (see below).

Key point: SQL becomes the pivot format for representing business objects.

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

Whatever the target tool, it 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 →