DataViz Migration - SAP BO, Power BI, Spotfire, or Cognos to an open, interoperable architecture
SAP BusinessObjects, IBM Cognos, Power BI, or Spotfire succeed one another within the same Information System, while business objects, calculations, indicators, and business rules generally remain identical from one platform to the next. {openAudit} extracts them to rebuild them in a format independent of the target technology.
Analysis of the decision-support estate
Parsers analyze SAP BusinessObjects universes, Cognos Frameworks, Power BI models, Spotfire Information Links, and the associated reports, dashboards, calculations, filters, and business objects. Dependencies between data sources, intermediate processes, and the objects exposed in dashboards are reconstructed, along with semantic layers and business rules.
Rationalization
Cross-referencing with usage logs identifies unused reports, duplicates, and obsolete components before migration.
Result: a reduced scope for the actual migration.
SQL transcription
Queries, calculations, filters, aggregations, joins, variables, and business rules are reconstructed in SQL, an open representation of the logic 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 →
