Cognos to Power BI migration services
Cognos Analytics 11.2.x left full support on 30 April 2026, and the upgrade path retires the legacy studios — so a chunk of your estate faces a rebuild whichever way you go. We read your Framework Manager package instead of converting it, re-express it as a Power BI semantic model, sort Report Studio output into paginated rebuilds and modeled reports, replace bursting and schedules, and reconcile every number against live Cognos before sign-off. One written price, typical delivery in 2–4 weeks, 30 days of hypercare included.
Representative dashboard — sample data
What you get
Reports are the visible half. The modeling layer, the bursts, and the security filters underneath them are what actually keep the content store alive after everyone agrees to move.
Query subjects, relationships, determinants, embedded calculations and governor settings are read as a specification, then rebuilt as a star-schema semantic model with measures written once instead of re-declared per report.
Banded, print-fidelity output becomes a paginated report; genuinely interactive output becomes a modeled Power BI report. The sorting happens before any building, because the two need very different amounts of work.
Ad-hoc queries and cube analyses that live in the legacy studios do not travel to modern Cognos either. Here they stop being saved artifacts and become self-service against a governed model that answers the same questions.
The burst key, the recipient query, and the saved output versions are re-expressed as Power BI subscriptions plus Power Automate flows — with visible run history, rather than a schedule that fails quietly overnight.
Filters applied in the package by role, and the namespace groups behind them, are remapped onto workspace roles, app audiences and row-level security — then tested with real accounts before any Cognos role is retired.
Every rebuilt report is run beside live Cognos output across agreed periods and filter combinations, and signed off by the person who owns the number — before the renewal conversation, not after it.
How it works
A free consultation plus the content store's own audit and usage data tells us what is opened, what is bursted, what was authored in a legacy studio, and what nobody has run in two years. You get the upgrade-versus-rebuild comparison, a written scope, one fixed price, and a delivery date.
The package becomes a semantic model before a single visual is drawn. Reports are then rebuilt on it in batches — paginated where the layout matters, modeled where the exploration matters — with security and prompts re-expressed as part of each batch.
Each batch runs in parallel with Cognos until the numbers agree and the owner signs off. Bursts and schedules move last, users get a walkthrough of what changed, and you receive a written list of what remains pointing at Cognos, plus 30 days of hypercare.
For years the honest advice to a small Cognos shop was "leave it alone, it works". IBM withdrew support for Cognos Analytics 11.2.x on 30 April 2026 — the dates and the current terms are published on IBM's Cognos Analytics 11.2.x support page (opens in new tab), and they are worth reading rather than taking second-hand. Broadly, continued coverage moves onto extended and then sustained tiers, where fixes narrow to critical issues and eventually stop. Standing still is now a decision with a cost attached, which is why this page exists at all.
The part that gets missed is what the vendor's own upgrade path asks of you. Content authored in the legacy studios — Query Studio, Analysis Studio, Cognos Workspace — does not carry forward into the modern Cognos authoring experience. If a meaningful share of your estate was built there, upgrading is not a patch-and-continue exercise: it is a rebuild in Cognos. That reframes the decision entirely. You are not comparing "free upgrade" against "expensive migration", you are comparing two rebuilds, one of which ends on a platform your Microsoft 365 tenant already administers.
We do not assume the answer is Power BI. The inventory comes first and the table below is the frame we use to read it, filled in with your own numbers — how many reports were authored where, how much logic sits in the package, how many bursts run.
| What you are actually deciding | Upgrading within Cognos | Migrating to Power BI |
|---|---|---|
| Legacy studio content | Rebuilt in the modern Cognos authoring experience | Rebuilt once, as self-service on a shared semantic model |
| Framework Manager package | Carried forward, still maintained in a desktop modeling tool by whoever knows it | Re-expressed as a semantic model your report authors can open and read |
| Print-fidelity banded reports | Stay as they are — the least disruptive part of an upgrade | Rebuilt as paginated reports, which is real work and scoped as such |
| Bursting and scheduled delivery | Unchanged, including the parts nobody can currently explain | Rebuilt as subscriptions and flows, with run history you can audit |
| Who can maintain it next year | Needs Cognos-specific authoring and modeling skills on staff or on retainer | Skills overlap with the Excel and Microsoft 365 tooling your team already uses |
| Platform footprint | A Cognos environment to patch and support alongside Microsoft 365 | Content lives in the tenant you already administer |
| Licensing shape | Cognos entitlements renew on their own cycle, on IBM's terms | A Power BI licence per author and per viewer — see our small-business licensing guide |
If that table points at an upgrade for your estate, we will say so. A migration sold against the wrong baseline is the kind of engagement that ends badly for both sides.
Cognos put a deliberate abstraction between reports and data. A package published from Framework Manager carries query subjects, relationships with cardinality, determinants that keep aggregates honest across grains, embedded calculations and filters, governor settings, and often data security filters that decide who sees which rows. Authors then build against that presentation namespace without touching a table name. It is a genuinely good idea, and it is also why "we only have forty reports" understates the job: the forty reports are thin because the package is thick.
That layer has a close counterpart in Power BI — a shared semantic model — but the two are not translatable object for object, so we treat the package as a specification rather than a source file. Relationships and determinants become a modeled star schema following Microsoft's star schema guidance (opens in new tab); embedded calculations become DAX measures (opens in new tab) defined once; stored-procedure and SQL query subjects become Power Query (opens in new tab) steps or views. Determinants deserve particular attention: they exist to stop a measure double-counting when a query crosses grains, and a model rebuilt without thinking about them will look right until someone slices by the wrong dimension.
Where the package sits on Transformer PowerCubes or Dynamic Cubes rather than relational sources, we go back to the warehouse those cubes were built from instead of trying to reproduce the cube. The dimensional design usually survives the trip; the proprietary build and refresh cycle does not need to.
Most estates decompose into the same handful of pieces. This is the mapping we work from, and the inventory in your written scope is a filled-in version of it.
| In Cognos | Where it lands in Power BI | What the work involves |
|---|---|---|
| Framework Manager package | Shared semantic model | Namespaces, relationships, determinants, calculations and filters re-derived into a star schema with DAX measures agreed with the report owners |
| Data modules built in the web modeller | Tables and relationships in the same semantic model | Usually the easiest piece — joins and calculations are already explicit and map fairly directly |
| Transformer PowerCubes / Dynamic Cubes | Import or DirectQuery model over the underlying warehouse | Dimensional design kept, cube build and refresh replaced by scheduled dataset refresh |
| Report Studio banded, print-fidelity output | Paginated report in Power BI Report Builder | Rebuilt page by page — nothing about the .xml specification travels — then rendered side by side against the Cognos PDF |
| Report Studio interactive output | Power BI report on the shared semantic model | Rebuilt so filtering, drill-through and totals come from the model rather than from report-level queries |
| Query Studio and Analysis Studio content | Self-service against the governed model | Each saved query is checked for whether it answers a live question; the ones that do become a report or a template, the rest are retired |
| Prompt pages and cascading prompts | Slicers, sync slicers and report parameters | Prompt logic re-expressed as filters on the model; paginated rebuilds keep true parameters where the export needs them |
| Bursting on a burst key with a recipient query | Power Automate flow | Flow reads the recipient list, exports a filtered copy per row, delivers to email or SharePoint, and logs every run |
| Schedules and saved output versions | Scheduled refresh plus report subscriptions | Delivery times matched to the old schedule; retained output versions archived where a retention rule requires them |
| Namespace roles and data security filters | Workspace roles, app audiences, row-level security | Each rule remapped and then tested with a real account per role before the Cognos equivalent is retired |
A Cognos burst takes one report, splits it on a burst key, resolves recipients from a burst table or a directory query, and delivers a personalized copy to each of them — often as saved output that people then retrieve rather than receive. Power BI has scheduled subscriptions, and they cover the simple cases well, but nothing in the service reproduces that split-and-distribute behaviour directly.
So we rebuild the pattern rather than look for a feature: a flow reads the recipient list from your data, calls the documented Power BI export actions (opens in new tab) once per recipient with that recipient's filter applied, and delivers the file by email or into SharePoint. The result has something the burst never had: a run history showing exactly who received what, and a failure that raises itself instead of being discovered a week later. If distribution and approvals are a wider theme in your organization than reporting is, our Power Automate consulting service covers that ground properly.
Security follows the same principle. Cognos applies data security filters inside the package against roles resolved from a namespace, which is close in spirit to row-level security in Power BI (opens in new tab) but not identical in mechanics — and the rules have to be re-expressed against Microsoft Entra groups rather than the Cognos namespace. Every role is tested with a real account, because "the filter is on the model" is not evidence that the right person sees the right rows.
The reason migrations of this kind lose trust is almost never the visuals. It is a total that moved by a fraction of a percent and nobody could explain why, six weeks after the old system was switched off. So reconciliation runs alongside the rebuild rather than after it: each report is run against live Cognos output for periods and filter combinations you choose, differences are traced back to a rule in the package, and the person who owns the number signs it off in writing.
Sometimes the difference turns out to be a bug in the Cognos report that has been quietly wrong for years. That conversation is uncomfortable and it is the single most valuable thing these projects produce.
It fits small and mid-size US organizations running a modest Cognos estate — a few dozen to a few hundred reports — with a Microsoft 365 tenant already paid for, a support renewal in view, and often nobody left in-house who is comfortable opening Framework Manager. It is scoped as one fixed-fee project with a stated end date, not a rolling program with a discovery phase attached. The named accelerators in this market are built for estates of several thousand reports; at your size, reading the package properly beats bulk conversion.
If the incumbent is a different platform, a sibling page will fit you better. Our Tableau to Power BI migration service covers workbooks that carry their own calculation logic, where there is no shared modeling layer to read in the first place. Our QlikView to Power BI migration service deals with the associative engine and a load script buried inside each .qvw. Our SSRS to Power BI migration service is the Microsoft-to-Microsoft case, where RDL definitions travel largely intact as paginated reports and the work sits in subscriptions and folder security. And our Crystal Reports to Power BI migration service handles .rpt files, formula fields and subreports opened from a button inside an ERP. And our Domo to Power BI migration service covers the all-in-one SaaS case, where the vendor also owns the ETL, the storage and the embedding channel, so Beast Modes and Magic ETL flows move at the same time as the cards. And our SAP BusinessObjects to Power BI migration service is a near neighbour of this page: a universe plays much the same role as a Framework Manager package, and publications much the same role as report bursting, so the work has the same shape even though the tooling does not. And our MicroStrategy to Power BI migration service covers the closest relative of all — another platform whose modeling layer is declared centrally and reused by every report — except that there the layer is a project metadata repository of attributes, facts and level metrics, and the bursting runs through Distribution Services rather than the content store. Cognos is its own case because of the package: it sits with BusinessObjects and MicroStrategy in the small group where a governed modeling layer already exists, has to be understood, and cannot simply be lifted — and the package is the most opinionated of the three.
Once you have landed on Power BI, the work usually continues. Our fixed-fee Power BI dashboard development service covers reports built new on the model rather than migrated onto it, the guide to what a Power BI dashboard actually costs explains how scope drives a fixed fee, and if you are still shortlisting firms, our guide on how to choose a Power BI consultant lists the questions worth asking us and everyone else. Where the package was doing work that belonged in a data pipeline, our Azure Data Factory pipeline development service builds the scheduled loads that replace it.
The table shows scope and typical timeline rather than prices, because an honest number requires seeing the package and the burst list first — the same principle described on how our fixed-fee process works.
| Phase | Scope | Typical timeline | Fee |
|---|---|---|---|
| Phase 1 — inventory and model | Content store and usage review, the upgrade-versus-rebuild comparison, workspace and gateway setup, and the Framework Manager package re-expressed as a semantic model with its core measures | About the first week | Fixed fee — scoped after your free consultation |
| Phase 2 — reports and security | Interactive reports rebuilt on the model, print-fidelity output rebuilt as paginated reports, prompts re-expressed, and data security filters remapped to workspace roles and row-level security | Weeks 2–3 | Fixed fee — scoped after your free consultation |
| Phase 3 — distribution and reconciliation | Schedules recreated as subscriptions, bursts rebuilt as Power Automate flows and run in parallel, report-by-report reconciliation against live Cognos, and a written list of what still points at the old platform | Week 4 and close-out | Fixed fee — scoped after your free consultation |
Everything produced is yours from the first day: the semantic model, every measure, the report files, the flows, and the workspace configuration all live in your own Microsoft tenant, never in ours.
Representative perspective
We were quoted an upgrade and assumed that was the cheap option. Nobody had told us the reports our analysts actually use were built in a studio that does not survive the upgrade either.Finance systems manager, mid-market distributor
Related services
Fixed-fee development for the reports you want built new, once the estate has landed on Power BI.
Scheduled distribution, approvals and integrations — including the flows that replace report bursting.
Pipeline development for the scheduled loads that feed a semantic model from your source systems.
Pro vs Premium Per User vs capacity, explained for small business budgets.
What to ask, what to check, and the answers that should make you walk away.
How scope, data sources and rebuild depth drive a fixed fee.
FAQ
It is read, not converted. We work through the package namespace by namespace, lifting relationships, determinants, embedded calculations and data security filters out of the model, then rebuild them as a star-schema semantic model with DAX measures. The package stays available in Cognos while we reconcile, so nothing is lost if we read a rule wrong.
That is a fair question and sometimes the answer is yes. The point worth knowing is that anything authored in the legacy studios needs rebuilding either way, so the honest comparison is two rebuilds, not a rebuild against a free upgrade. We put the inventory in front of you before you commit to either path.
No. Banded output built to print or export at a fixed size, such as invoices, statements and regulatory packs, is rebuilt as paginated reports in Power BI Report Builder. Reports people genuinely explore become modeled Power BI reports on the shared semantic model. We sort the catalog into those two groups first.
Power BI has scheduled subscriptions, but nothing that splits one report by a burst key and mails a slice per recipient. We rebuild that pattern in Power Automate: a flow reads the recipient list from your data, exports a filtered copy per row, and delivers it by email or to SharePoint with run history you can audit.
By running both and comparing. Each rebuilt report is reconciled against live Cognos output for an agreed set of periods and filter combinations, and the person who owns the number signs it off. Differences are investigated rather than explained away, because a rounding gap is sometimes a rule we read wrong.
Typical delivery is two to four weeks from kickoff, with dates stated in your written scope. The fee is fixed and reflects how many reports move, how much logic sits in the Framework Manager package, and how many bursts and schedules have to be rebuilt. Nothing starts until you approve the scope.
Book a free consultation
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.