Migrate from IBM Cognos Analytics to Metabase

Migrate from IBM Cognos Analytics to Metabase: what the work involves

Metabase suits a Cognos estate made mostly of dashboards and simple list reports, and the migration is a rebuild of content, not a file move. Cognos packages, reports and schedules do not import into Metabase, so each dashboard has to be recreated as Metabase questions (saved queries), models and dashboards on top of the same databases. Plan the work as a content inventory followed by a rebuild, with the inventory showing which reports are still used, who owns them and which data sources they read. Retiring unused content first usually shrinks the rebuild more than any tooling choice.

The work is usually done by internal BI owners who know the business definitions, supported by platform engineers who stand up the servers, the application database and the data connections, and sometimes by an implementation partner for scoping, hardening and backups. Effort and risk are driven mainly by how many reports depend on Framework Manager-style business logic that must be restated in SQL or Metabase models, and by how many recipients rely on scheduled email delivery. Ask the partner to scope these items in writing before work starts, and confirm current Metabase edition limits in the Metabase pricing page for your own environment.

Metabase Open Source is free to self-host with unlimited users and dashboards, but single sign-on and row and column level permissions are included only in the Pro and Enterprise plans. That shapes the plan: if Cognos namespace and group access must be enforced per row or per column, or users must sign in through your identity provider, budget for a Pro or Enterprise plan from the start. If the estate needs only group-level access to whole dashboards, the Open Source edition may be enough, and the permission mapping in the next section becomes simpler.

Which Cognos capabilities map cleanly to Metabase

This table compares the Cognos capabilities that most estates rely on with their Metabase equivalents, marking each as clean, needs rework or gap. Read the Metabase open source column first, then check the Pro or Enterprise note where a row depends on paid features. The main takeaway is that dashboards, saved queries and basic scheduled emails usually map well, while Framework Manager logic, burst distribution and pixel-perfect output need separate planning.

Cognos capability	Metabase equivalent	Fit and notes
Dashboards and interactive visualizations	Dashboards built from questions and filters	Clean. Open source includes unlimited dashboards, though layout and drill behavior differ and need rebuilding.
List reports and simple tabular output	Table questions with saved SQL or the query builder	Clean for simple lists. Complex prompts and grouped report layouts need rework.
Framework Manager packages and metadata	Models and the semantic layer built in Metabase	Needs rework. Joins, calculated fields and business definitions must be re-expressed as Metabase models and metrics.
Namespaces and groups	Metabase groups and collection permissions	Needs rework. Open source covers groups, but advanced LDAP group sync and SCIM provisioning require Pro or Enterprise.
Row and column level security	Row and column permissions	Gap in open source. Row and column level permissions are a Pro or Enterprise feature, so confirm the plan before design.
Scheduled delivery by email	Dashboard and question subscriptions by email	Clean for recurring summaries. Confirm recipient, format and timing needs against your current schedules.
Burst reports and pixel-perfect output	No direct equivalent in Metabase	Gap. Metabase is not a strength for burst distribution or pixel-formatted documents, so confirm this with your report owners.
Single sign-on	Google sign-in and LDAP in open source; JWT, OIDC and SAML in Pro or Enterprise	Needs rework. Confirm the identity provider and whether the required plan is in budget.

What you can export from Cognos and what must be documented by hand

Cognos content generally does not export into Metabase, so the inventory of reports, packages, schedules and the data sources behind them is the real deliverable of this phase. Treat the Cognos deployment archive and the content store as inventory aids only. They show you what exists, who owns it and when it runs, but they do not give you a working Metabase artifact. The sibling page on exporting from Cognos explains what the archive contains and why it only imports back into Cognos, so read that before you plan the work: how to export your reports and content from IBM Cognos Analytics. Expect to record each report's purpose, its consumers, its refresh and subscription schedule, and its owner by hand in a spreadsheet or wiki that your Metabase team can work from.

The most time-consuming part is recreating the logic behind each report. Where a Cognos report depends on a Framework Manager package, you need to capture the joins, filters, calculated fields, business names and security rules that the package applies, then rebuild them as Metabase models and questions. Where a report uses hand-written SQL or a native query, copy the SQL into an inventory record and test it against the same database. For each data source, confirm that a database connection exists or can be created in Metabase, that a service account with read-only access is approved by the database owner, and that network paths and credentials are documented. Record the database engine and version, because Metabase's supported drivers and the query behavior you verify will depend on them.

Keep the inventory honest about what cannot be rebuilt as is. Burst reports, pixel-perfect layouts and report output that depends on Cognos-specific prompts or features will need a decision: simplify, redesign as a dashboard, or retire. Mark each item with one of those outcomes before any build starts. (Illustrative: a finance team's 40-page burst pack might become a dashboard with a scheduled export, and a rarely opened report might be archived.) Agree with business owners which items are retired, and get sign-off in writing so that unused content does not quietly become scope.

Data, identities and integrations to rebuild

Cognos content depends on connections, identities and delivery paths that a Metabase deployment does not inherit. Each item below must be recreated or re-decided before dashboards are cut over. Confirm each one against your own environment before scheduling the rebuild.

Source database connections

Cognos reads warehouses through data sources, connection strings and service accounts configured in its content store and Framework Manager packages. Metabase needs its own database connections, each with a driver, host, credentials and network path from the Metabase host. Recreate one connection per source, using a read-only service account, and test that each one reaches the same schemas the Cognos packages used. Confirm which source credentials are stored in Cognos today and who owns rotating them.

Metabase application database

Metabase stores questions, dashboards, users, permissions and subscriptions in an application database. It ships with an embedded H2 database that suits demos only, so production should run PostgreSQL, with MySQL 8.4.0 or MariaDB 10.6.0 and later also supported. Plan the database build, backups and the H2 to production move if any test content was created. Confirm your backup and restore process for this database before the first production load.

User and group identities

Cognos namespaces and groups define who sees which reports, and they have no direct equivalent in Metabase. Export the group membership and folder permissions from Cognos, then map each group to a Metabase group and collection permission set. Open Source and Starter support Google sign-in and LDAP only, so SSO, SAML, OIDC and SCIM group sync depend on the plan you choose. Confirm which identity provider is authoritative and whether group sync is required on day one.

Email subscription delivery

Cognos schedules and bursting send report output on a schedule to recipients. In Metabase, dashboard subscriptions and alerts send email on a schedule, so each recurring Cognos schedule needs a matching subscription with the same recipients, filters and timing. Confirm the outbound SMTP relay, sender domain and allowed recipient policy with your mail team before cutover. Test that delivery works for each recipient group, because subscriptions do not carry over from Cognos.

Embedded dashboards and downstream consumers

If Cognos reports are embedded in intranet portals or consumed by other systems, those links, iframes and API calls break when Cognos is retired. Metabase supports embedding, but embedded dashboards need their own signing setup and identity handoff in the host application. List every consumer that calls a Cognos URL, file share or export, and assign each one a replacement endpoint. Confirm with the owners of those systems which output formats they still depend on.

Migration sequence from inventory to Cognos decommission

This sequence takes a Cognos estate used mostly for dashboards and simple lists from an unexamined inventory to a retired Cognos deployment, with each step producing a record that the next step depends on. Scope decisions happen first so that effort goes only to content people still use.

Inventory and triage Cognos content
Start from the Cognos deployment archive and content store to list every report, dashboard, package, data source, schedule and recipient. Ask content owners and the business to confirm which items are used, who relies on them and which are duplicates or abandoned. Retire unused content in writing before any rebuild begins. The output is a signed-off inventory with a keep, merge, retire or defer decision for each item, approved by the business owners named in it.
Document logic and data sources
For each item kept, record the business rules, filters, calculations, prompts and source tables that Cognos applies, including anything hidden in Framework Manager packages. Map each source to a database Metabase can connect to, and note where a model or view must be created first. Confirm credentials and network paths with the database owners. The output is a specification per dashboard that a Metabase builder can follow without opening Cognos.
Map Cognos groups to Metabase permissions
Translate Cognos namespaces, groups and roles into a Metabase group model, listing which groups need view, edit or data access to each collection and database. Confirm with the identity team whether group membership will be synchronized from the directory or maintained manually. Check which permission features your Metabase edition includes, since row and column level permissions and advanced group sync are limited to paid plans in the pricing documentation. The output is a permissions matrix approved by the security and data owners.
Pilot a small set of dashboards
Rebuild a small, representative set of questions, models and dashboards in a non-production Metabase instance, choosing items that exercise filters, joins, scheduled email subscriptions and restricted access. Run the pilot with a few business users and compare results against Cognos for the same parameters. Confirm that email subscriptions reach the right recipients and that the permissions matrix behaves as written. The output is a validated pilot dashboard set and a list of defects and gaps to resolve before scaling.
Build the production instance and rebuild the estate
Deploy Metabase with a production application database, following the vendor guidance for PostgreSQL or MySQL rather than the embedded H2 database, and back up before each upgrade. Rebuild the remaining kept content in batches according to the specifications, then have owners review each batch against the Cognos output. Record the Metabase version in use so later upgrades can follow the version support and upgrade documentation. The output is a complete set of rebuilt content with owner acceptance recorded per item.
Run a parallel period with reconciled figures
Run Cognos and Metabase side by side for an agreed period, and reconcile key figures each cycle. Log every difference, its cause, and the agreed resolution, whether a defect in the rebuild, a data timing difference or a Cognos logic issue that the business chooses to correct. Keep scheduled deliveries running from both systems until owners confirm the match. The output is a reconciliation log that the business signs off as the basis for cutover.
Cut over with a runbook
Write a cutover runbook listing the order of actions: final content freeze, last reconciliation, switching email subscriptions, updating links and bookmarks, communicating to users and the rollback steps. Confirm access for users through the agreed identity method, which may depend on your SSO plan and on whether your edition supports the protocol you choose. Execute the runbook in a planned window and verify that each subscription and permission works. The output is a completed runbook with a sign-off record.
Archive Cognos content and decommission
After a stabilization period agreed with the business and compliance team, export and archive the Cognos content, package definitions, schedules and audit records that retention rules require, and store them where they can be read without Cognos. Then retire the Cognos server, content store and license assignments in a documented order, and confirm the vendor contract end date with procurement. The output is a Cognos archive with a retention record and a decommission certificate listing removed components.

How Cognos namespaces and groups map to Metabase permissions and SSO

The first decision is what your Cognos security model is doing today. In Cognos, access usually flows from namespaces (an LDAP directory, Active Directory or a Cognos-native namespace) into groups and roles, which then grant rights on folders, packages and capabilities. Metabase has a different shape. Users belong to groups, and groups are given access to collections and to individual data sources, with permissions set at each level. Export the Cognos group membership and folder permissions, then decide for each group whether it maps to a Metabase group that needs read access to a collection, to a data source, or to both. Groups that exist in Cognos only because of historical report ownership should be retired rather than carried across.

Row and column level permissions are where the plan can change. In Metabase, these controls are available only on the Pro and Enterprise plans, according to the pricing page, so Open Source and Starter cannot restrict which rows or columns a group sees. If Cognos enforces row filters through Framework Manager security or package-level rules, treat that as a licensing input before you design the data model. The alternative is to publish separate filtered models or collections per audience, which adds maintenance. Ask your Metabase partner or the vendor to confirm which permission features apply to your chosen tier, and record the answer with the design.

For SSO, confirm your identity provider and your licence tier before any build work starts. Open Source and Starter support Google sign-in and LDAP. JWT, OIDC, SAML and advanced LDAP group and attribute sync require Pro or Enterprise, and the documented SAML setups cover Auth0, Entra ID, Google, Keycloak and Okta. SCIM provisioning, which keeps Metabase users and groups aligned with the directory, also requires those higher tiers. If your Cognos namespace is Active Directory and you intend to keep group membership driven by the directory, plan for Pro or Enterprise from the start. The Metabase people and groups documentation sets out the mapping options, and your identity team should validate them against your directory structure.

What drives cost and duration in a Cognos to Metabase move

This table lists each cost component of moving a Cognos estate to Metabase, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Use it to shape your scope and the questions you put to a quote. Metabase Open Source has no license fee, so most cost sits in rebuilding, identity work and operations.

Cost component	Who is paid or who spends effort	One-time or recurring, and what drives it	What to request in a quote
Report rebuilding volume	Implementer and internal BI analysts	One-time. Driven by the number of Cognos reports, dashboards and list reports you choose to keep after inventory	Itemized count of content to rebuild, retire or leave in Cognos, with a rebuild estimate per item
Data model complexity	Implementer and data engineers	One-time. Driven by Framework Manager packages, joins, calculated fields and how many source databases feed Metabase models	Mapping of each Cognos package to Metabase models and the data sources they need
Groups and permission rules	Implementer and identity administrator	One-time to design, then recurring to maintain. Driven by the number of Cognos groups, roles and folder-level rules to map	Group-to-permission mapping document and the rules that need Pro or Enterprise features
SSO tier and identity integration	Identity team, implementer and Metabase license holder	One-time integration, with a recurring license if a paid tier is needed. Google sign-in and LDAP are in Open Source and Starter; JWT, OIDC, SAML and SCIM need Pro or Enterprise per Metabase's people and groups documentation	Confirmed identity provider, required protocol, and whether group sync or SCIM is in scope
Subscriptions and alert volume	Implementer and operations staff	Recurring in effort. Driven by scheduled email deliveries and alerts that replace Cognos schedules, plus mail relay capacity	Inventory of Cognos schedules with recipients, frequency and output format
Hosting and application database backups	Infrastructure team or hosting provider	Recurring. Metabase recommends PostgreSQL for production, and backups of the application database are needed before every upgrade	Hosting sizing, backup retention, restore test scope and the database platform to be used
Upgrade planning and support windows	Operations team and implementer	Recurring. Metabase LTS releases are supported for 14 months and non-LTS releases usually reach end of life after 2 months, so the upgrade cadence sets the effort	Upgrade runbook, chosen release track (LTS or non-LTS), and the support hours included in any retainer
Staff time and internal skills	Your staff, including project owner, data owners and testers	One-time for migration testing and user acceptance, recurring for ownership of dashboards and models. Driven by how many business owners must validate outputs	Named roles, time commitment per role, and a plan for handover after go-live

What usually goes wrong and how to prevent it

Most Cognos to Metabase migrations fail in predictable places: logic that lived only inside Framework Manager, numbers that drift during the parallel run, access that changes at cutover, and operational shortcuts taken to meet a date. Each risk below has a concrete check to put in the plan before the first dashboard is rebuilt.

Undocumented Framework Manager logic

Filters, calculated measures, security filters and join rules in Framework Manager packages often exist only in the model, not in any report. When these are not written down, the rebuilt Metabase questions silently drop them. Before rebuilding, export each package's model logic and list every calculation, filter and join against the reports that depend on it. Treat any figure without a documented definition as unfinished work.

Figures that do not reconcile

A parallel run often shows small differences between Cognos and Metabase totals, usually from rounding, time zones, null handling or a different date grain. Left unexplained, these differences erode trust in the new platform before users switch. Choose a fixed set of reference reports, agree tolerances with the business owners, and record each variance with its cause and sign-off before retiring the Cognos original.

Permission gaps after SSO cutover

Cognos namespaces and groups do not map one to one onto Metabase groups, and the SSO features that carry group sync are limited by plan. Users can log in successfully yet see empty or fewer collections than before. Build a permission matrix from the Cognos groups, confirm which SSO and group sync features your chosen Metabase plan includes, and test each role with a real user account before cutover.

Subscriptions that silently stop

Scheduled Cognos reports often run for years without an owner checking them. When the schedule is not recreated as a Metabase email subscription, recipients simply stop receiving files, and nobody notices until a month-end review. Inventory every Cognos schedule, record its recipients and purpose, recreate it in Metabase, and run a sample delivery to each recipient. Confirm mail server settings and assign an owner for ongoing failures.

H2 used in production

Metabase ships with an embedded H2 application database that suits demos but is not the production choice. Running production on H2 puts dashboards, users and subscription settings in a file that is harder to back up and scale. Move the application database to PostgreSQL or MySQL before go-live, using the documented load-from-h2 command with the same Metabase version that last wrote the H2 file.

Upgrades without a backup or clustering

Metabase runs application database migrations automatically when it starts a newer version, so a failed upgrade can leave the metadata store in a state that is hard to reverse. Clustered nodes can also block major upgrades through a migration lock. Back up the application database before every upgrade, reduce the cluster to a single node for major versions, and step through releases in order if the instance is older than release 40.

How the move differs by estate size and starting point

A small Cognos estate used mainly for a handful of dashboards and simple list reports can often be rebuilt by one or two people in a short sequence. The work is dominated by deciding what to keep, because rebuilding unused content is the most common source of wasted effort. Metabase's free Open Source edition supports unlimited users and dashboards, so the decision in a small estate is usually about the database and the hosting rather than seat counts.

Retire before rebuilding: Export the list of reports and schedules from the Cognos content store and cut anything nobody has opened in the period your business owners agree on.
Start on the H2 default only for a trial: Metabase ships with an embedded H2 application database for demos. Plan to move to PostgreSQL before users depend on saved questions and dashboards.
Keep the model small: Rebuild the few Framework Manager concepts you need as Metabase models and questions rather than recreating every package.
Test email subscriptions early: Confirm that scheduled dashboard emails reach recipients through your mail relay before you switch off the Cognos schedules.
Keep the cutover short: Run both systems in parallel for one reporting cycle, then turn Cognos off.

Before you start, confirm with Metabase which features your small team needs, since SSO and row or column level permissions sit in the paid plans.

Questions buyers ask before moving from Cognos to Metabase

How much effort and cost does a Cognos to Metabase move involve?

The effort depends mainly on how many reports, dashboards and schedules are actually in use, how complex the data models behind them are, and how much documentation exists. Costs fall into two groups. One-time costs include inventory, rebuilding content, configuring the application database, permissions mapping, SSO setup and testing. Recurring costs include the server and database hosting, backups, upgrades and support, plus staff time for content ownership. Metabase Open Source carries no license fee for self-hosting, so the comparison comes down to these labor and infrastructure components. Ask any partner for a quote that itemizes inventory, rebuild, identity integration, testing, handover and ongoing support as separate lines, so you can see which items your own staff could absorb.

How long does a Cognos to Metabase migration take?

The pace is set by the size of the content you keep, not by the tool. Retiring unused reports early shortens the work more than any other step. Other factors include how many data sources must be connected, whether Cognos Framework Manager models need to be redefined as Metabase models, how many stakeholders must approve rebuilt dashboards, and whether identity integration requires new decisions. Teams that run old and new dashboards in parallel for a period usually need more time than teams that cut over in stages. A written, fixed scope with agreed deliverables is the most reliable way to set a timeline, so request one before committing to dates.

Can our internal team migrate from Cognos to Metabase without outside help?

Many teams can handle a dashboard-focused estate internally, especially where a few analysts know the data well and the report count is modest. Internal work is harder when the estate depends on Framework Manager packages, burst distribution, many user groups or strict audit requirements. Consider three questions: whether you have someone who can run and upgrade Metabase and its application database, whether analysts have time to rebuild content alongside their normal work, and whether anyone owns security configuration. DeployOpen plans, implements, integrates, backs up, upgrades and documents self-hosted platforms in your own infrastructure, so a partner can cover some or all of these roles under a fixed scope or a retainer.

What does the migration need from our team?

Expect to supply several kinds of input. Business owners must confirm which reports are still used and who approves rebuilt dashboards. Data owners must confirm which sources feed each metric and how they are defined. Platform staff must provide hosting, a PostgreSQL or MySQL instance for the Metabase application database, network access to data sources and identity provider details. Security staff must agree on the group and permission model. Metabase's documentation recommends PostgreSQL for production and notes that the embedded H2 database is meant for demos, so plan the database early. Ask your implementation partner to list these inputs in the written scope so each owner knows their commitments before work begins.

Does Metabase Open Source cover our SSO requirements?

Metabase Open Source supports Google sign-in and LDAP, but not the wider SSO options. According to Metabase's pricing page, SSO is included only in the Pro and Enterprise plans. JWT, OIDC, SAML with documented setups for Auth0, Entra ID, Google, Keycloak and Okta, advanced LDAP group and attribute sync, and SCIM provisioning also require Pro or Enterprise. If your identity provider is Entra ID, Okta or another SAML or OIDC system, the Open Source edition will not meet that requirement on its own. Confirm your identity provider, group sync needs and provisioning requirements, then decide between a paid plan and a different authentication approach before finalizing the permissions design.

Do Cognos reports convert to Metabase automatically?

No. Cognos reports are not converted automatically into Metabase questions, models or dashboards. Cognos deployment archives import only into Cognos, so they serve as an inventory of content, packages and schedules rather than a transfer file. Each report must be understood, its data logic rebuilt in Metabase, and its layout recreated and checked against the original. Framework Manager business logic usually needs to be restated as Metabase models and saved questions. Plan for manual rebuilding and validation, and treat the Cognos inventory as the starting checklist for that work.

How should we handle burst or pixel-perfect Cognos reports in Metabase?

Metabase is built around interactive questions, dashboards and email subscriptions, so it is a poor fit for highly formatted, page-exact output or large burst distributions. Start by classifying each Cognos report as interactive, scheduled list, or pixel-perfect. Interactive and dashboard content usually moves well. Simple scheduled lists can often be rebuilt as subscriptions. Pixel-perfect and burst reports need a decision: rebuild them in a document-oriented tool, keep a small reporting component for those specific outputs, or retire them. Confirm the output formats and recipient volumes you need before deciding, because these choices change the scope and cost of the project.

How are Metabase upgrades handled after go-live?

Upgrades are an ongoing operating task. Metabase runs application database migrations automatically during upgrades. Its documentation recommends backing up the application database first, reducing a cluster to a single node for major upgrades because of a migration lock, and upgrading one release at a time when moving from versions older than 40. Support timing matters too. Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months. Metabase 64 is an LTS release published on 16 September 2026 with end of life on 1 December 2027. Decide who owns the upgrade calendar, testing and rollback before go-live, and include that work in your support arrangement.

How DeployOpen scopes and runs a Cognos to Metabase migration

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Cognos to Metabase move, we start from a written scope that covers which dashboards, list reports and subscriptions move, and we build and document the Metabase environment in your cloud account, data center or air-gapped network.

How we scope

Inventory of Cognos dashboards, list reports, schedules and recipients, with unused content flagged for retirement
Mapping of Cognos namespaces and groups to Metabase groups and collection permissions, agreed in writing
Decision on the Metabase edition needed for SSO, row and column permissions and support before work starts

How we build

Metabase deployed with PostgreSQL as the application database, with the H2 demo database not used for production
Data source connections, models and questions rebuilt from the source queries and checked against Cognos output
Dashboards and email subscriptions configured, then tested with representative users and recipients

How we hand over

Documentation of the deployment, backup routine, upgrade steps and permission model for your administrators
Side-by-side reconciliation records showing which Cognos outputs were matched, changed or retired
Runbook for the Metabase upgrade path, including application database backup before each version change

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Upgrade work scheduled against Metabase version support dates that your team confirms with the vendor
Cutover and Cognos retirement plan agreed in the written scope, so each step has a named owner

Migrate from IBM Cognos Analytics to Metabase