Power Bi |

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 Cognos to Power BI

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

IBM Cognos Analytics platforms typically hold several years’ worth of business modeling: Frameworks, hierarchies, calculations, dimensions, measures, variables, and reports.

{openAudit} analyzes Cognos Frameworks, reports, and usage logs to reconstruct the dependencies between data sources, business objects, and reporting outputs.

Key point: in most Cognos estates, the value lies more in the Frameworks and business rules than in the reports themselves.

Analysis of the Cognos estate

The analysis covers Framework Manager, reports, queries, dimensions, hierarchies, calculations, filters, and variables.

The collected metadata makes it possible to reconstruct:

dependencies between objects;
relationships with data sources;
business objects and indicators exposed in reports.

Scope rationalization

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

This phase identifies unused reports, duplicates, and obsolete Frameworks.

Result: the scope that’s actually used is isolated before migration.

Conversion to Power BI

Cognos Frameworks are analyzed and then converted to the target Power BI model.

Dimensions, hierarchies, measures, calculations, variables, and relationships between objects are reconstructed in the target semantic model.

Cognos expressions are converted to SQL or DAX depending on their nature.

Dependencies between Frameworks, reports, and data sources are preserved in the generated model.

Key point: business objects and calculation rules are reconstructed directly from the Cognos Frameworks.

Validation

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

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

Typical use case: progressive validation of reports before cutover.

Usage-driven migration

Reports can be migrated in batches based on how often they’re used and their business criticality.

Observed usage forms the basis for project planning and development prioritization.

Result: a reduced volume to migrate, with effort focused on active usage.

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.