Cognos Analytics 12.0 end of support: upgrade or replace

Cognos 12.0 is in extended support: what that means for your estate

Cognos Analytics 12.0.x moved to extended support on September 30, 2026, so the decision in front of you is no longer whether to plan, but which path to take: upgrade to the 12.1.x line, stay on extended support for a defined period, or replace Cognos with a self-hosted tool. Confirm with IBM, in writing and against your contract, what extended support includes, how long it runs, and which fixes it covers. Do not assume the terms match what your team has heard elsewhere, and record the answer, because it sets the deadline for every other choice in this page.

The short answer is that your inventory decides the path. An estate built mostly on dashboards and simple list reports, with a modest number of packages and few dependencies on Framework Manager models, is a good fit for Apache Superset or Metabase. An estate that depends heavily on burst distribution, pixel-formatted output or complex scheduled bundles needs a more detailed plan, and may justify staying on Cognos longer. Count reports, packages, models, schedules and recipients, and note which items have run in the last few months, so you know what actually needs to move.

Whichever path you choose, run the upgrade or the replacement as a tested project rather than a calendar exercise. Take a backup of the content store and the configuration before any change, and test the 12.1.x upgrade in a staging environment with a copy of real content. If you replace Cognos instead, use the same inventory to decide which content to retire and which to rebuild. In both cases, set an internal decision date well before September 30, 2026, so that the choice is made by your team and not forced by the support calendar.

What the end-of-support date requires you to decide

Cognos Analytics 12.0.x moves to extended support on September 30, 2026, and that date sets the order of your decisions. Each card below is a choice or check that applies to every path: upgrading to 12.1.x, staying on extended support, or replacing Cognos.

Choose the 12.1.x upgrade path

The 12.1.x line follows a 3+1+3 support cycle, so the release you land on sets how long you can plan without a forced move. Confirm with IBM which 12.1.x release you would install, how long it stays supported, and whether your current content, custom extensions and authentication settings carry over without rework. Schedule at least one full staging test before any production cutover, since an upgrade that only starts the service proves little about your reports.

Weigh the cost of extended support

Extended support keeps the 12.0.x line running after September 30, 2026, but you should not assume it brings the same fixes as the active line. Ask IBM in writing what extended support includes, how security patches are delivered, and how long it will last. Record the answers next to your risk register, because an auditor or internal security team will ask what happens to a platform that receives no new feature or fix work.

Inventory reports, packages and models

Every path has to carry the same content, so the inventory is the first deliverable regardless of which product you choose. List reports, dashboards, data modules, Framework Manager packages and their owners, and mark anything with no run or view activity for a long period as a retirement candidate. This list also tells you how much rebuild work a replacement needs and whether a 12.1.x upgrade only moves content or also reshapes it.

Map schedules and output formats

Scheduled reports, bursting to recipients, and pixel-formatted PDF or Excel outputs are often the least visible part of a Cognos estate. Record each schedule, its trigger, recipients, output format and downstream consumer, such as a finance pack or regulator file. Apache Superset builds dashboards and alerts, so any burst or pixel-perfect output that matters to the business needs a named owner in either path, whether that is an upgraded Cognos schedule or a separate report generator.

Carry authentication and group mapping

Namespaces, groups, SSO and data source credentials are the security integrations that any migration must preserve. Document which LDAP or OAuth groups grant which Cognos capabilities and which database accounts the reports use. Apache Superset maps LDAP or OAuth groups to roles through AUTH_ROLES_MAPPING, so a group map written now is useful in either path. Review the access model with your identity team before cutover, not after users report missing reports.

Why the inventory must come before any upgrade or replacement decision

Every option on this page starts with the same list: every report, package, schedule, namespace, group and data source that Cognos Analytics 12.0 serves today, with a named owner for each. An upgrade to the 12.1.x line, a stay on extended support that ends September 30, 2026, and a move to Apache Superset or Metabase all depend on knowing what must keep working, who relies on it and what can be retired. Without that list, the effort for any path cannot be scoped, and the team cannot tell whether an unused report is truly unused or only quiet between runs. Ask for a dated extract, because the list reflects usage on the day it was taken.

The starting point is the Cognos deployment archive and the content store. The archive packages the deployment so it can be restored into Cognos, which makes it a reliable snapshot for inventory but not a source that Superset or Metabase can read. The content store is the queryable record of report and package objects, folder locations, schedule definitions and the namespaces and groups that secure them. Confirm with your Cognos administrator which objects your version's archive includes, whether run history and last-execution data are kept and for how long, and which database and service account the content store uses. Store the export date with every extract so later comparisons run against the same snapshot.

Several things do not come out of either source and must be documented by hand. Record the business logic inside reports and Framework Manager packages, including calculated fields, filters and prompts, because any rebuild depends on it. Capture each data source's connection details, owner and refresh expectations, and each schedule's recipients and output format, including burst distribution and pixel-formatted outputs that a replacement may not produce. Map every namespace and group to the teams and roles that use it, and assign a business owner to each report. Ask the business to sign off this list before choosing a path, so the choice rests on confirmed content.

Upgrade to 12.1, stay on extended support, or replace with Superset or Metabase

Upgrading to the 12.1.x line keeps Cognos Analytics as the platform, so your Framework Manager packages, reports, schedules and users carry over, but each upgrade still needs testing. The work sits with your Cognos administrators and the team that maintains the content store, with IBM support or an implementation partner supplying help on demand. Confirm the 3+1+3 support cycle terms and the 12.1.x release dates directly with IBM before you commit to a timeline.

What changes: the server version, the content store schema, and any custom extensions or authentication settings that the new line requires.
Who does the work: Cognos administrators run a staging upgrade, business testers sign off on reports and schedules, and database staff handle backups.
What recurs: per-user licensing and IBM support fees continue, and each later release on the cycle repeats the testing effort.
Main risk: Framework Manager models, custom extensions and scheduled burst or pixel-formatted reports can fail quietly after the upgrade, so regression tests must cover them.
Cost driver: the number of users and reports to test, and whether custom content has to be rewritten.

Before you start, ask IBM which 12.1.x release supports your planned server, database and operating system versions.

Apache Superset is licensed under Apache-2.0, is maintained by the Apache Software Foundation and has no paid edition, so the software itself carries no license fee. Version 6.1.0 was released on May 13, 2026. Replacing Cognos means rebuilding Framework Manager packages as Superset datasets and dashboards, then running Superset's web application, its metadata database and, where you need alerts or async queries, its caching and worker components.

What changes: Framework Manager packages become datasets and charts, schedules become alerts and reports, and authentication moves to Flask-AppBuilder with database, LDAP or OAuth login.
Who does the work: a platform team deploys and secures the stack, analysts rebuild content, and data engineers maintain the database connections.
What recurs: hosting, PostgreSQL or MySQL metadata database operations, and upgrades that back up the metadata database, run superset db upgrade and superset init, and test in staging first.
Main risk: pixel-formatted and burst reports that Superset does not produce need a separate path, and alerts depend on the caching and worker components being run correctly.
Cost driver: the number of reports to rebuild, the skills available in-house and the size of the infrastructure you run.

Check which report formats your business owners need and whether any of them require a document generation tool outside Superset.

How Superset and Metabase compare on the requirements that matter

This table compares Apache Superset and Metabase on the requirements a Cognos replacement must meet: licensing, metadata database, authentication, upgrades and paid tiers. Read each row as a question to answer in your own pilot, since the table shows what the published sources say and where Cognos output formats have no direct equivalent. The main takeaway is that both tools are self-hostable, but identity features and report formats decide the shortlist.

Requirement	Apache Superset	Metabase
License	Apache License 2.0, with no paid edition	AGPL for open source code, Metabase Commercial License for the enterprise directory and images
Metadata database	PostgreSQL or MySQL in production, SQLite default not recommended	H2 for demos, PostgreSQL recommended, MySQL 8.4.0 or MariaDB 10.6.0 and later supported
Authentication	Database, LDAP and OAuth2 through Flask-AppBuilder, with group-to-role mapping via AUTH_ROLES_MAPPING	Google sign-in and LDAP in open source; JWT, OIDC, SAML and SCIM require Pro or Enterprise
Row-level and advanced permissions	Available in the open source project; confirm the exact model in your pilot	Row and column level permissions and SSO only in Pro and Enterprise plans
Upgrade procedure	Back up metadata database, run superset db upgrade and superset init, test in staging, review UPDATING.md	Migrations run automatically; back up application database, reduce cluster to one node for major upgrades
Paid plan triggers	No paid edition; cost sits in hosting, staff and support	SSO, SAML, SCIM and air-gapped deployment push you toward paid plans; confirm current pricing with Metabase
Cognos burst and pixel-perfect output	Not produced natively; plan a separate output path for these reports	Not produced natively; plan a separate output path for these reports
Other gaps to confirm	Scheduling, export formats and embedding needs for each Cognos report type	Scheduling, export formats and embedding needs for each Cognos report type

How to run the replacement on your own infrastructure

This sequence takes you from choosing Superset or Metabase to a tested, backed-up instance inside your own environment, with the metadata, security and upgrade basics in place before any Cognos content is rebuilt.

Pick the target platform by content type
Decide between Apache Superset and Metabase using the inventory from the earlier steps. Superset suits SQL-heavy dashboards and teams comfortable with datasets and charts, while Metabase suits simpler questions, dashboards and email subscriptions for business users. Record the decision, the reasons and the owner in the project record. You know this step is done when the chosen platform and its scope are approved in writing by the sponsor and the data owners.
Deploy the platform in your environment
Your platform or infrastructure team installs the chosen tool in your cloud account, data center or air-gapped network. Superset is Apache-2.0 and has no paid edition, and Metabase's free Open Source edition is self-hosted. Use the official installation path your team has standardized on, and confirm the Kubernetes approach with current documentation, since the Helm chart is marked deprecated for new deployments. You know this step is done when a non-production instance answers over your internal address and connects to one test data source.
Use PostgreSQL or MySQL for metadata
Point the application metadata store at PostgreSQL or MySQL rather than the SQLite default used by quickstart and PyPI installs, which is not recommended for production. Superset supports PostgreSQL 10 to 17 and MySQL 5.7 and 8.x, and Metabase recommends PostgreSQL for production, with MySQL 8.4.0 or MariaDB 10.6.0 and later. Confirm the versions your database team supports before provisioning. You know this step is done when the platform starts cleanly against the external database and the backup job covers it.
Set SECRET_KEY and rotation policy
The security owner generates a unique SECRET_KEY and stores it in your secrets manager, since Superset refuses to start without a user-specified value. Document how PREVIOUS_SECRET_KEY will be used during rotation so existing sessions and encrypted values can be handled safely. Keep the key out of version control and out of container images. You know this step is done when the instance starts with the stored key and the rotation procedure is written down and reviewed by the security team.
Add caching and Celery for alerts and reports
If the Cognos estate uses scheduled reports or alerts, add the caching layer and Celery worker and beat processes that Superset needs for alerts and reports, async queries and dashboard thumbnails. Most installations use Redis and Celery for these components. Size and monitor the workers against the schedules you inventoried. You know this step is done when a test alert and a test scheduled report both run on schedule and deliver to a test recipient.
Configure authentication and group mapping
The identity team configures sign-in, either database accounts, LDAP, or OAuth2 through your identity provider, using the Flask-AppBuilder options Superset provides. Map directory groups to roles with AUTH_ROLES_MAPPING and check the mapping against the Cognos namespaces and groups you documented. For Metabase, confirm which SSO features your plan includes, since SAML, JWT, OIDC and SCIM require Pro or Enterprise. You know this step is done when test users from each group land in the correct roles and a user removed from the directory loses access.
Back up the metadata database before any upgrade
Before each upgrade, the platform owner takes a backup of the metadata database and confirms it can be restored in a separate environment. For Superset, run the documented upgrade steps including superset db upgrade and superset init, and review UPDATING.md for breaking changes between versions. For Metabase, back up the application database first and, for major upgrades, reduce a cluster to a single node because of the migration lock. You know this step is done when a restore test succeeds and the backup is recorded with its date and version.
Test every upgrade in staging first
Run each platform upgrade in a staging environment that mirrors production configuration, and rebuild a representative sample of dashboards and scheduled reports against it. Compare row counts, filters and figures with the Cognos originals for the same period. For Metabase, upgrade release by release if the installed version is older than 40. Promote to production only after the test results are signed off by the business owners. You know this step is done when the staging results match the agreed checklist and the production change is approved with a rollback plan.

Evidence to keep for the cutover and for auditors

A platform change leaves a trail that auditors and internal audit will ask to see, whether you stay on Cognos 12.x or move to Apache Superset or Metabase. The cards below cover the records that connect the inventory, access, upgrade, backup and decommissioning steps. DeployOpen prepares this evidence, but independent auditors decide what it proves.

Content and report inventory

Keep a dated inventory of every report, package, dashboard, schedule and data source in scope, with an owner and a business use for each item. Mark what is retired, what is rebuilt and what is kept unchanged, so the cutover can be traced item by item. Record the Cognos deployment archive and content store export that produced the list. Auditors will ask who approved each retirement decision.

Group to role access mapping

Document how each Cognos namespace, group and capability maps to roles in the new platform, including who approved the mapping and when. For Superset, record how LDAP or OAuth groups map to roles through AUTH_ROLES_MAPPING. For Metabase, record the group and permission design and which plan provides SSO and row-level permissions. Keep the reviewed list of access grants so that leavers and movers can be checked against it.

Upgrade and rollback records

For a move to the 12.1.x line, or an upgrade of any self-hosted component, record the source and target versions, the change plan, the staging test results and the approval. Write down the rollback steps and the state each rollback returns to, and test them before production. For Superset, the upgrade guidance covers the metadata database backup, superset db upgrade and superset init, and review of UPDATING.md. Keep the staging results with the change ticket.

Backup restore test results

A backup that has never been restored is weak evidence. Keep dated restore tests for the content store, the metadata database and any file or archive exports, with the time taken, the person who ran the test and the errors found. For Metabase, include the application database backup taken before upgrades. Confirm your retention periods with your policy owner and record them, since no retention default is set in this page's sources.

Secrets and configuration records

Record where configuration lives, who can read it and how keys are managed. For Superset, this includes the required SECRET_KEY and the rotation procedure that uses PREVIOUS_SECRET_KEY, along with the date of each rotation. Auditors commonly test whether secrets are stored outside source code and whether access to them is logged. Keep the configuration baseline under version control so changes can be reviewed.

Decommissioning certificate

When Cognos is retired, record the date the service stopped, the data and content removed, the disposition of archives and backups, and the access revoked. Confirm which copies must be kept for legal or records requirements, and where they are held. Get sign-off from the system owner and the security lead. This record closes the audit trail, so it should be the last item signed.

Questions buyers ask before choosing an upgrade or replacement

What drives the cost of staying on Cognos 12.0 or upgrading to 12.1?

The cost of staying on 12.0 is mostly deferred work, while upgrading and replacing each carry a one-time project plus recurring running costs. Staying on extended support keeps your current licensing and content store unchanged until that support period ends. Upgrading to 12.1.x means testing packages, data sources, custom content and security integrations on the new line, and that testing repeats with each release cycle. Replacing Cognos adds one-time work to inventory content and rebuild models and dashboards, plus recurring hosting and staff time. Superset has no paid edition, while Metabase publishes plan fees, including Pro at $575 per month on its pricing page. Ask IBM in writing for current per-user and renewal prices, because this page does not supply them.

How long does replacing Cognos take for a small or large estate?

The timeline grows with the number of live reports, packages, schedules and data sources, and the largest single factor is how much of that content is still used. Start by retiring unused content, because every report kept alive is a dashboard to rebuild and validate. Estates that depend on pixel-perfect or burst-distributed output take longer, since Superset does not produce every format Cognos does. Estates used mainly for dashboards and simple lists usually move faster than those built on many Framework Manager packages with complex security. No duration is supplied for this page, so ask any implementer to tie the timeline to a counted inventory and a written scope.

What does a Cognos replacement need from our own staff?

Your staff must own the business logic, the infrastructure and the access model, even when an implementer does the build. Business owners validate that rebuilt figures match Cognos output for the reports they rely on. Database administrators provision PostgreSQL or MySQL for the metadata store and its backups. Identity staff connect OAuth2 or LDAP and map groups to roles with AUTH_ROLES_MAPPING. Platform engineers run the caching layer and Celery workers that alerts and scheduled reports need, and they decide whether to use the Kubernetes Operator, since the Helm chart is marked deprecated for new deployments. Confirm that people who already run your databases, identity provider and container platform are available before the scope is signed.

Can our team replace Cognos Analytics without outside help?

It is possible for a team with SQL, Python and Linux operations skills to run a replacement alone, but the risk sits in the parts Cognos hides: package logic, security mappings and scheduled delivery. DeployOpen can plan, implement, customize, integrate, harden, back up, upgrade and document a self-hosted Superset or Metabase inside your own cloud account, data center or air-gapped network. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. Ask your team to list the specific skills it lacks, then compare that list with the written scope.

What should a written scope for a Cognos migration include?

A written scope turns estimates into commitments you can compare across bidders. Ask for these parts:

A counted inventory of reports, packages, schedules and users, with an owner for each item
A decision list for content to retire, rebuild or keep on Cognos
Data source connections, authentication mapping and role design
Test and sign-off criteria for each rebuilt report, with named approvers
Hosting design, backup and restore procedure, and an upgrade runbook
Documentation and knowledge transfer to your staff
Explicit exclusions, including any burst or pixel-formatted output you will keep elsewhere

An unclear exclusion list is the cheapest problem to fix before the scope is signed.

Which Superset components do alerts and scheduled reports need?

Alerts, scheduled reports, async queries and dashboard thumbnails need the caching layer and worker components, and most installations use Redis and Celery for them. Superset's architecture also includes a Flask and React application and a metadata database, which should be PostgreSQL or MySQL in production. The configuration docs list PostgreSQL 10 to 17 and MySQL 5.7 and 8.x as supported metadata versions. The SQLite default of quickstart and PyPI installs and the Docker Compose PostgreSQL container are not recommended for production. Superset requires a user-specified SECRET_KEY to start, which you should keep in your secrets manager and rotate with PREVIOUS_SECRET_KEY. Confirm these choices with your security team before the design review.

How should we upgrade Superset or Metabase safely in production?

Back up the metadata database first, then test each upgrade in staging before production. For Superset, follow the upgrade guide, run superset db upgrade and superset init after deploying the new version, and read UPDATING.md for breaking changes between each version you pass. Metabase runs its application database migrations automatically at startup, so back up that database first, reduce a cluster to a single node for major upgrades because of a migration lock, and upgrade one release at a time from versions older than 40. Plan around each product's support window: Metabase LTS releases are supported for 14 months, while non-LTS releases usually reach end of life after 2 months. Write the runbook into the scope so the procedure is tested before it is relied on.

What drives the cost of each path

Every path has a recurring cost and a one-time cost, and the split between them decides which option is cheaper over the next several years. For staying on Cognos Analytics, the recurring items are the per-user licenses for the editions in use, the content store database and its licensing, the application and gateway servers, and the support agreement. The one-time items are the upgrade project to the 12.1.x line, testing, and any remediation of reports that break on the new version. Ask IBM or your reseller to itemize the license quote by edition, user count and any add-on components, and to state the content store database requirements separately so the database line is not hidden inside the server line.

For the upgrade path, the largest variables are the number of reports and packages that need regression testing, the number of custom extensions or scheduled outputs that depend on the server, and the staff hours spent on the upgrade. For Apache Superset or Metabase, the license line drops to zero, but the recurring costs move to infrastructure (a metadata database, a cache and worker layer for alerts and scheduled reports, and backups), to support, and to internal staff time. The one-time costs are the rebuilding of Framework Manager models as datasets or Metabase models, the recreation of dashboards, and the work to replace burst or pixel-formatted outputs. Both open-source projects are free to use, so the quote you need is from the implementation partner and any hosting provider, not from the software vendor.

When you request quotes, ask each provider to separate fixed scope from ongoing support and to state what is included in the price. For a DeployOpen quote, the scope is agreed in writing before work starts and is based on your inventory, so complete the inventory first. Confirm with IBM the exact support end date for your version and whether extended support is priced separately, because that date sets how long you can defer each path. Confirm with your own finance team how depreciation of existing servers and the content store database is treated, since that changes the true first-year comparison.

How DeployOpen works on this

DeployOpen starts a Cognos Analytics 12.0 end of support decision with a written scope that records what must be upgraded to 12.1 or replaced with self-hosted Apache Superset or Metabase. Work is planned, built, tested and documented inside your own infrastructure, and handed over with the evidence your team needs.

How we scope

Inventory every Cognos report, package, schedule and user group before any option is chosen.
Record which content is used, which is retired and which needs a burst or pixel-formatted output.
Agree deliverables, timelines and exclusions in writing before work starts, since engagements are fixed-scope.

How we build

Stand up the chosen target in your cloud account, data center or air-gapped network, with PostgreSQL or MySQL as the metadata store.
Rebuild priority dashboards and datasets, and test each against the figures produced by the Cognos source.
Set up authentication against your directory, mapping groups to roles, and test access before users log in.

How we hand over

Document architecture, configuration, backup and upgrade steps, including a rollback path for each change.
Provide a content register that maps each retired, rebuilt or upgraded Cognos item to its new home.
Deliver evidence of controls and testing that your internal team or an independent auditor can review, noting that DeployOpen prepares evidence but does not issue audit reports.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Plan future releases, such as Superset or Metabase version upgrades, using each vendor's upgrade notes and a staging environment.
Ask for a quote from the written scope, since DeployOpen does not publish a price list.

Cognos Analytics 12.0 end of support: upgrade to 12.1 or replace