Modernization |

DataViz Migration - an upstream/downstream SQL interoperability layer - {oa-lake}

Fri, 03 Jul 2026 00:00:00 +0000

Decision-support platforms often rely on several databases, several data warehouses / data lakes, and several reporting tools.

{oa-lake} introduces an intermediate SQL layer between data sources and dataviz tools.

Business rules, business objects, dimensions, measures, and calculations are centralized in this layer and then exposed to consuming tools.

Key point: data sources and reporting tools become independent of one another.

Architecture

{oa-lake} connects simultaneously to multiple data systems: relational databases, data warehouses, lakehouses, files, or APIs.

Queries are federated by a distributed SQL engine that performs the necessary joins, calculations, and transformations.

The resulting SQL remains standard and executable across different engines, which limits technology lock-in.

Business objects are defined once and then exposed to consuming tools.

Data sources

The data stays in its original systems.

Oracle, SQL Server, PostgreSQL, DB2, BigQuery, Snowflake, Redshift, Azure SQL (and others), or files can be queried within a single request.

The SQL Push-Down mechanism avoids any systematic copying of data: queries run directly against the existing systems, respecting the architectures already in place.

Typical use case: build a dashboard from data spread across several platforms with no prior migration.

SQL business layer

Dimensions, measures, hierarchies, and calculation rules are centralized in {oa-lake}.

This layer becomes the single entry point for reporting tools.

Business rules are no longer duplicated across every dataviz platform.

Key point: a single definition of indicators for the entire decision-support system.

Parquet cache

Data can be materialized in Parquet format.

This caching layer reduces response times and limits load on source systems. It’s managed automatically based on observed usage, with no manual intervention.

Typical use case: speed up the most expensive analytical processing.

Data visualization

Reporting tools connect to the model exposed by {oa-lake}.

Power BI, Looker, Spotfire, Tableau, Qlik, SAP BusinessObjects, or any SQL-compatible tool can use the same business objects.

Switching dataviz tools no longer requires rebuilding dimensions, measures, and calculation rules.

Progressive migration

Several tools can coexist during a transition phase.

The same business model can be exposed simultaneously to several reporting platforms.

Result: progressive migration of usage with no change to the data systems.

Data Lineage

The data lineage reconstructed by {openAudit} remains available across the whole chain.

Dependencies are documented from the source systems all the way to the indicators exposed in the dashboards.

Key point: transformations, calculations, and usage remain traceable across the entire architecture.

DataViz Migration - migrating from SAP BO to GCP Looker

Thu, 02 Jul 2026 00:00:00 +0000

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.

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.

DataViz Migration - migrating from SAP BO to Power BI

Thu, 02 Jul 2026 00:00:00 +0000

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.

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.

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

Thu, 02 Jul 2026 00:00:00 +0000

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.

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

{oa-lake}

The SQL processes are integrated into {oa-lake}.

{oa-lake} centralizes business objects, indicators, dimensions, business rules, and SQL transformations. The engine federates several data systems and exposes a single model to reporting tools.

Data can be materialized in Parquet format. Queries are generated against the physical systems or executed from the cache when needed.

Key point: business logic is defined once and then exposed to several data visualization platforms.