Moving from IBM Cognos to a Databricks architecture

Guide, October 2026. Product facts come from Databricks and IBM documentation and IBM's community forums, linked at the end; check IBM's supported-environments page for your exact Cognos version. Read getting the most from the converter first: this guide builds on it.

Who this is for

Teams running IBM Cognos Analytics over a warehouse on Oracle, SQL Server or Teradata, who want the data on Databricks and are weighing what to do with the reports. Typical triggers: a Cognos renewal on the horizon, a warehouse that is expensive or slow, or business users asking for the natural-language questions they see elsewhere. If your warehouse is DB2 or Netezza, the plan is the same, with one difference noted below.

The two layers of a Cognos estate

A Cognos estate is two things stacked. The data layer is the warehouse: tables, views, stored procedures, load scripts, plus any native SQL written into Cognos query subjects. The presentation layer is Cognos itself: Framework Manager packages or data modules that define the business view, and the reports, dashboards and schedules built on them.

The agentic converter handles the top lane. It reads T-SQL, Snowflake, Redshift, Oracle, BigQuery and Teradata and writes Databricks SQL. Cognos itself is not in its list, nor in the source list of Lakebridge, Databricks' wider migration toolkit. The bottom lane is redesign work: there is no automated path from a Cognos report specification to a Databricks dashboard, and you would not want one, because this is the moment to stop rebuilding reports nobody reads.

On DB2 and Netezza: both appear in Lakebridge's list of supported SQL sources but not in the agentic converter's list of dialects. For those, the conversion goes through Lakebridge's rule-based transpilers rather than the agentic converter; check the Lakebridge documentation for which component covers your source before planning.

From a Cognos reporting structure to a Databricks architecture

Before any SQL moves, it helps to see where each part of today's Cognos estate ends up. Cognos bundles a lot into one product: connections, a metadata model, security, report authoring, scheduling, delivery and auditing. On Databricks those jobs are separate, governed pieces that all sit on Unity Catalog. The picture below is the target; the table after it maps each Cognos component onto it.

Three consequences of the new shape matter for planning. Security moves down to the data, so a rule written once applies in dashboards, Genie, Power BI and notebooks alike, instead of living inside one reporting tool. The semantic layer becomes shared, so Power BI and Databricks dashboards show the same measure computed the same way. And usage, lineage and audit become queries over system tables, which is what lets you prove nobody needs a report before you retire it.

Step 1: find out what is actually used

Cognos can log activity to an audit database. The COGIPF_RUNREPORT table records report runs, including dashboards and stories since 11.0.9, and the target type separates interactive runs from scheduled batch runs. IBM ships audit sample reports that read it. Pull a year of runs and sort reports into three groups: used weekly, used rarely, not used. Two warnings from people who have done this: a single dashboard open can write many rows, and prompt pages can double-count runs, so count distinct users and days, not rows.

The "not used" group does not migrate. The "used rarely" group gets a conversation with its owner. Only the first group is rebuilt first.

Step 2: extract the SQL

The converter works on .sql files, so the job is to get every piece of SQL that matters into files, grouped by source dialect.

• Warehouse objects. Export the DDL for tables and views and the source of stored procedures and load scripts from the warehouse itself. This is usually the largest share and converts most cleanly.
• Native SQL query subjects. Framework Manager and data modules let modellers write a query subject as native SQL in the database's own dialect. Export each one to its own file, named after the query subject, so the mapping back is obvious.
• SQL behind the reports that matter. For a data module query subject, "Show query information" (Cognos Analytics 11.1.5 and later) shows its SQL. For reports, the authoring tool can show the generated SQL. For a wider sweep, Cognos can audit the native queries it sends to the database; IBM advises switching that on only briefly because it fills the audit database quickly. These generated queries are not the code you will keep, but they are the exact statements that produce today's numbers, which makes them the best reconciliation targets there are.

Step 3: convert with a prepared agent

Follow the preparation in the converter guide: analyzer output, lineage, workspace instructions, a migration skill, a ten-script pilot. For a Cognos estate, add three things to the skill:

• A name map from Cognos query subject names to Unity Catalog tables or views, so the business names your users know survive the move.
• The calculations defined in the model (in Framework Manager these are often expressions on query items), written out as plain rules, so converted views compute them the same way.
• The filters and security rules the model applied (for example, region or business-unit filters), so they become row filters in Unity Catalog instead of disappearing.

Step 4: move the data first, keep Cognos running

The least risky order is two phases. In phase A, the warehouse moves to Databricks and Cognos keeps working, pointed at Databricks instead of the old database. On-premises Cognos Analytics can connect to Databricks through the Simba Spark JDBC driver; IBM's community answers place this as a supported connection type, with a minimum driver version and some version-specific issues, so confirm it against the supported-environments page for your release and test metadata loading early. Community threads also report that Cognos Analytics on Cloud did not offer the connection as of early 2026, so cloud customers should check before relying on this phase.

Phase A lets you reconcile with the users' own reports: the same report, run against the old warehouse and against Databricks, should show the same numbers. When it does, the data migration is done and proven, and nobody had to learn a new tool to prove it.

Step 5: rebuild the presentation layer, smallest first

In phase B, the business view moves off Cognos. The model's job, one definition per measure that every report shares, moves to a governed semantic layer: Unity Catalog metric views define each measure once for dashboards, Genie spaces and alerts and can be queried from Power BI and Tableau, or a Power BI semantic model if Power BI is your reporting standard. Then the weekly-used reports are rebuilt as AI/BI dashboards or Power BI reports, highest usage first, each one signed off by its owner against the phase A numbers. Ad-hoc questions that used to need a report request can go to a Genie space over the same metric definitions.

Cognos is switched off when the last report its users still open has a replacement they have signed off. Not before.

Proving the numbers at every step

Use the three checks from the converter guide (row counts per partition, totals and NULL counts, row hashes on the business key) for every table, and add one more for a Cognos estate: for each weekly-used report, the report's totals on the old system and on the new one, for the same prompt values, for the same day. Disagreements here are almost always one of three things: a calculation that lived in the Cognos model and was not carried into the skill, a filter the model applied silently, or one of the data differences (empty strings, integer division, NULL ordering, time zones) the converter guide lists.

What to expect

• The data layer moves faster than it used to, because the converter does the bulk translation and the skill carries your rules to every file.
• The presentation layer takes the time it takes, because it is a redesign. Retiring unused reports first is what keeps it short.
• The phased order means users see one change at a time: first the numbers stay the same on a new platform, then the reports move.

When to ask for help

We would start with the audit extract and a pilot: the ten most-used reports, their SQL extracted and converted, reconciled in phase A. That shows the real shape of the estate, and you get a written number for the rest once it is done.

Sources: Databricks release notes, October 2026; agentic code converter; Lakebridge overview and supported sources; Unity Catalog metric views; IBM Community on Databricks connections, data module SQL and audit counts. Cognos and IBM are trademarks of IBM; Octelion is not affiliated with IBM or Databricks.