DataViz Migration - migrating from Cognos to Power BI

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.

The conversion relies on {oa-lake}: calculations and business rules from the Frameworks are encapsulated as SQL pipelines, and business objects feed the interoperable semantic layer of {oa-lake}. Power BI connects to this ready-made model (see below).

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.

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

Power BI 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 →