The package comes first
We walk the Framework Manager project through its database, business, and presentation layers, listing query subjects, query items, relationships, cardinality, determinants, and security filters before any visual is drawn.
Retiring IBM Cognos Analytics
A Cognos to Power BI migration that starts in Framework Manager, not in the report list
We read the metadata model before we touch a chart: query subjects and determinants become a star schema, stitch queries become conformed dimensions, many-to-many relationships become bridge tables, and every figure is reconciled against its Cognos original.
Representative dashboard — sample data
Why teams move
The reports are the easy half
An IBM Cognos estate is rarely retired because people dislike the reports. It is retired because the governed layer underneath them has become a specialism: one desktop copy of Framework Manager, a project file only one person opens, determinants and cardinality settings nobody wants to touch, and a change request queue measured in weeks. Meanwhile the business already pays for Microsoft 365 and wants the same governed numbers where it can filter them.
That is why a rebuild that copies the report list first tends to stall. The interesting work is in the package: what each query subject really represents, at what grain, and which relationships Cognos was quietly resolving for you at run time. Get that into a star schema and the reports follow quickly. Skip it and you inherit the same ambiguity in a new tool, with none of the run-time rescue Cognos was providing.
What the rebuild covers
- Framework Manager review
- Report spec inventory
- Star schema design
- Stitch queries → conformed dimensions
- Bridge tables
- Query calcs → DAX
- Security filters → RLS
- Paginated report parity
- Reconciliation & cutover
Try us risk-free for 4 hours
Start with a block of prepaid Flex hours and, if you're unhappy within the first 4 hours, we refund you in full — no questions asked. Reading the package and the report specifications makes a good first task: it tells you the real size of the job before you commit a budget to it.
How we approach it
Rebuilt from the metadata layer outward
Cognos does a lot of work at query time that Power BI expects you to have settled in the model. Naming those behaviours early is what keeps the rebuild predictable instead of surprising you at month-end.
Report specs are readable
Cognos stores each report as an XML specification, so data items, detail and summary filters, prompts, and calculations can be inventoried systematically rather than reconstructed by opening every report by hand.
Stitch queries become structure
Where Cognos joined two aggregated fact queries on shared dimension keys at run time, Power BI needs conformed dimension tables in the model. We design that shape deliberately and test it against the old totals.
Grain decided, not inherited
Determinants exist because a query subject mixes levels of granularity. In a tabular model that becomes a structural decision: split the table, set the right key, and add a bridge table where the relationship is genuinely many-to-many.
Security filters become RLS
Row-level rules that lived in the model as security filters are rewritten as row-level security roles with DAX filter expressions, then tested role by role so the same people see the same rows after cutover.
Print packs stay fixed-layout
Statutory packs, remittances, and burst statements are not dashboards. Those are rebuilt as paginated reports so page breaks, repeating headers, and every printed row land where the recipient expects them.
What actually moves out of Framework Manager?
Cognos separates a governed metadata layer from the reports that consume it. Framework Manager holds the project, publishes packages, and turns a user's request into SQL using the relationships, cardinality, and determinants you defined. Power BI splits the same responsibility differently: a semantic model holds tables, relationships, and DAX measures, and reports visualise it. So the migration is a model rebuild with a known map, not a file conversion.
The practical consequence is where ambiguity gets resolved. Cognos can carry a query subject that mixes grains and still return a sensible number, because it applies determinants and generates the aggregation for you. A tabular model has no equivalent rescue: the grain has to be right in the table, or the measure is wrong everywhere it is used. That is not a drawback so much as a relocation of the decision, and it is the reason we read the project before quoting the reports.
Newer estates make this easier. If your team has already moved modelling into browser-based data modules rather than the desktop project, the tables, joins, and calculations are closer in spirit to a Power BI model and the translation is shorter. Older estates that still lean on dimensionally modelled relational packages or PowerCubes need the extra step of deciding which hierarchies genuinely earn their place.
How do Cognos objects map to Power BI?
This is the working map the plan is built from. It is deliberately unglamorous: the value of a migration map is that nothing surprising appears in week three, and that every line has an owner who agreed to it.
| IBM Cognos | Power BI equivalent | What changes in practice |
|---|---|---|
| Framework Manager project and published package | Semantic model published to a workspace | Governed metadata leaves a desktop project file and becomes a shared, refreshable model |
| Database, business, and presentation layers | Power Query queries, model tables, and display folders | The layering convention survives; it moves into Power Query and the model view |
| Query subject | A dimension or fact table in a star schema | Query subjects that mix grains are split so each table has exactly one grain |
| Determinant | Correct table grain plus a key relationship | Granularity becomes structural instead of a property declared on the object |
| Multi-fact stitch query | Two fact tables filtered by the same conformed dimensions | What Cognos assembled at run time has to exist in the model before the report is built |
| Many-to-many relationship in the model | Bridge table between the two dimensions | The relationship becomes explicit and testable, so double-counting is visible early |
| Query item with a rollup aggregate | A named DAX measure | Aggregation stops being implicit; each definition is written once and reused |
| Detail filter and summary filter | Power Query filter, or a filter argument inside a measure | Before-versus-after aggregation becomes the difference between the query and the DAX |
| Report Studio list and crosstab | Table and matrix visuals on a shared model | Reports stop carrying their own queries and read from one governed definition |
| Fixed-layout report with page breaks and bursting | Paginated report in Power BI Report Builder, plus subscriptions | Layout and per-recipient delivery are preserved rather than approximated |
| Prompt page and cascading prompts | Slicers and filters, or report parameters in a paginated report | Users change the view themselves instead of re-running a prompted report |
| Security filter in Framework Manager | Row-level security role with a DAX filter expression | Row rules move onto the model and are testable with the View as role feature |
| Package and namespace object security | Workspace roles and app audiences | Who sees which content becomes a permissions question, not a modelling one |
| Scheduled job and emailed output | Scheduled refresh plus report subscriptions | Delivery moves onto the same platform as the reports themselves |
| Active Report distributed as a file | No direct equivalent | Offline interactivity is re-planned as a published report, a mobile layout, or an export |
Two lines in that table carry most of the risk, and both are modelling lines rather than reporting ones. Conformed dimensions and bridge tables are what stop a multi-fact rebuild from quietly disagreeing with the original, which is why we design against Microsoft's star schema guidance (opens in new tab) rather than importing the package shape as-is. The measure work that follows is the data modeling and DAX half of the job, and Microsoft's own Power BI migration guidance (opens in new tab) follows the same sequence: assess and prioritise the estate before rebuilding any of it.
What replaces the stitch query?
When a Cognos query touches two fact query subjects that share conformed dimensions, the engine aggregates each side separately and joins the results on the common dimension keys before returning them. It is an elegant run-time answer to the multi-fact problem, and it is invisible to the person writing the report — which is exactly why it surprises teams during a rebuild.
Power BI has no run-time equivalent to lean on. The same answer comes from structure: both fact tables relate to the same date, customer, product, and account tables, and each measure is written against its own fact and evaluated through those shared filters. Where a relationship is truly many-to-many — an account mapped to several reporting groups, a transaction tagged with several dimensions — a bridge table makes it explicit instead of hiding it inside a join.
The payoff is that a disagreement becomes diagnosable. If a rebuilt figure differs from Cognos, the cause is a relationship, a grain, or a filter you can point at, rather than a query the tool generated on your behalf.
What happens to pixel-perfect Report Studio output?
This is the objection that stalls most Cognos migrations, and it is a fair one. A standard Power BI report is built for interaction on a screen: a table you scroll prints only the rows that were visible. A statutory pack, a remittance, or a burst customer statement has to print every row, break pages in the right places, and repeat headers and footers exactly.
That work belongs in a paginated report (opens in new tab) authored in Power BI Report Builder, which gives exact page-layout control and prints all the data in a table across as many pages as it takes, with export and subscription options for delivery. Bursting to a distribution list is re-expressed rather than lifted, so it needs a decision about recipients and delivery early. Paginated reports also depend on the capacity your workspace runs on — confirm the licensing against Microsoft's current documentation before committing to a design.
In practice an estate splits cleanly: anything a person explores becomes an interactive report on the shared model, and anything a person prints, files, or sends to a customer stays fixed-layout. We make that call during classification and record the reason, so it is auditable later.
How is security rebuilt?
Cognos usually enforces two different things that get discussed as one. Security filters in the model restrict which rows a user sees; namespace, package, and folder permissions restrict which objects they can open at all. Those separate cleanly in Power BI, and keeping them separate is what makes the rebuild testable.
Row rules become row-level security (opens in new tab) roles on the semantic model, written as DAX filters and verified role by role before anyone else sees the report. Object visibility becomes workspace roles and app audiences. We document the mapping from your existing groups and roles so the security review at cutover is a comparison, not an investigation.
What does the migration cost?
Work runs on prepaid Flex hours that never expire: Starter 20 hours ($2,500), Growth 40 hours ($4,600), or Power 80 hours ($8,000), with hourly work from $100/hour. Reading the package and inventorying the report specifications for a typical mid-market estate fits inside a Starter block, and it is the task we recommend buying first, because it converts an unknown content store into a scoped list with hours against each line.
After that, cost tracks the shape of the model far more than the number of reports. A single-fact package feeding twenty list reports is a much smaller job than three fact query subjects, a set of determinants, and a security filter per business unit. You get an estimate in hours per deliverable, approve only what you want built, and unused hours stay banked. See Flex pricing.
How long does it take?
Individual reports typically ship within 3–5 business days of approval once the model is standing, and a phased migration is a sequence of those tasks rather than one project ending in a big-bang cutover. The model itself is the front-loaded piece: it is worth building and reconciling before the report queue starts, because every report after it gets cheaper.
Running Cognos alongside Power BI for one full reporting cycle is worth the overlap. Users compare both outputs on live data, and the old estate is switched off only once the replacements have been through a real month-end.
Who this is for
Finance, operations, and IT teams carrying an IBM Cognos estate they can no longer maintain comfortably: a Framework Manager project only one person understands, a licence renewal that has stopped looking like value, prompt-driven reports nobody can self-serve, or a knowledge gap left by whoever designed the packages. It is a poor fit for anyone wanting a like-for-like screen copy with no modelling decisions made — that buys a more expensive version of the problem you already have.
What you get
- A documented read of the Framework Manager project
- A report inventory with rebuild, merge, or retire calls
- A star-schema semantic model with named DAX measures
- Bridge tables where the relationships are many-to-many
- Row-level security mapped from your security filters
- Reconciliation against the Cognos originals
- Handover docs and a user walkthrough
3–5
business days per report
Phased
not big-bang
You
own everything
Buy the model-and-inventory task first and decide the rest once the real scope is visible. Comparing routes off different legacy platforms? The migration to Power BI hub covers them side by side.
How it works
From a published package to reporting people trust
- 1
Read the model and the estate
We document the Framework Manager project — query subjects, relationships, cardinality, determinants, calculations, security filters — and inventory the report specifications with owners and run frequency. You approve the list and the hours behind it before work starts.
- 2
Rebuild the model, then the reports
The package becomes a star schema with conformed dimensions, bridge tables where they are needed, and named DAX measures. Surviving reports are rebuilt on top of it highest-value first, with fixed-layout output built as paginated reports.
- 3
Reconcile, cut over, support
Each rebuilt report runs beside its Cognos original on the same prompts and period, differences are explained, then we publish, set refresh, row-level security and permissions, walk your users through it, and stay available on the hours you have left.
Representative perspective
The thing we underestimated was the package. Once someone wrote down what each query subject actually meant, half the arguments about which number was right answered themselves.Finance systems manager, mid-market manufacturer
Representative perspective
Our worry was the burst statements. Seeing those come out page-for-page in a paginated report is what let the rest of the migration stop being a debate.IT director, insurance services group
Find out what your package is really carrying
Tell us roughly how many packages and reports you have, and which ones month-end depends on. We'll scope the model read and report inventory in hours, so you can see the real project before committing to it.
FAQ
Questions teams ask before they commit
No. A Framework Manager project describes query subjects, determinants, and cardinality that Cognos resolves into SQL at run time, which has no direct import path into a tabular model. What is systematic is reading the project layer by layer and rebuilding it as a documented star schema with named DAX measures.
Conformed dimension tables. Cognos stitches two fact query subjects together at run time by aggregating each separately and joining on shared dimension keys. Power BI expects that shape to exist in the model instead, so both facts are related to the same date, customer, and product tables and measures filter through them.
Fixed-layout output moves to paginated reports authored in Power BI Report Builder, which control page breaks, repeating headers, and printing every row. Burst distribution is re-expressed as subscriptions or a per-recipient delivery process. Confirm capacity licensing for paginated reports against Microsoft's current documentation before committing to that design.
They become row-level security roles on the semantic model, written as DAX filters and tested with the View as role feature. Package and namespace object security, which controls what a group can see rather than which rows, becomes a workspace role and app audience question instead of a modelling one.
Every rebuilt report is run beside its Cognos original on the same prompts and period, and each difference is explained before sign-off. Some differences turn out to be corrections: a rebuild often exposes a determinant or a cardinality setting that had been quietly double-counting or dropping rows for years.
Related work
This page covers the IBM path specifically. If your estate spans several tools, the broader migration to Power BI service handles the Excel and SSRS routes on the same prepaid model, and the neighbouring rebuilds share most of this method: Crystal Reports to Power BI migration deals with subreports and record selection formulas, while Qlik to Power BI migration covers set analysis and Section Access. Teams on the SAP stack meet the same multi-fact problem under different names, so the SAP BusinessObjects to Power BI migration page maps Universe contexts and alias tables onto conformed dimensions much as this page maps stitch queries. Teams whose governed layer is a MicroStrategy project should read the MicroStrategy to Power BI migration page instead, where attributes, Level Metrics and security filters take the place of the package and its determinants. Teams retiring an Oracle estate should read the OBIEE to Power BI migration page instead — the RPD plays the part Framework Manager plays here, and it comes with an integrate-rather-than-migrate option this route does not have. Teams on the open-source side of the same buyer profile, running Pentaho and its Mondrian cubes, should read the Pentaho to Power BI migration page, where the schema XML and the Kettle jobs set the scope. Teams who meet Cognos only as the engine behind a vendor’s embedded reporting — the business intelligence layer inside UKG Pro is built on it — have no Framework Manager project to rebuild, so the UKG Pro Power BI dashboard page covers that route instead. The modelling itself is data modeling and DAX work, and teams standing up their first workspace usually pair it with Power BI consulting for the licensing and governance decisions a rollout brings. Every task is scoped before work begins from your prepaid block of senior-led hours, and hours are deducted only for work you approve.
Book a free demo
Get senior Power BI help, on demand
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
- Prepaid hours from $100/hour — and they never expire
- Senior-led delivery — 20+ years on the Microsoft platform
- Typical 3–5 business day turnaround
- Full refund if you’re unhappy in your first 4 hours
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.