Can you export your Cognos Analytics content and take it elsewhere?
A Cognos deployment archive is a restore point for Cognos. Moving content to Apache Superset or Metabase means using the archive and the content store as an inventory of what exists, then rebuilding each item in the target tool. This matters most when a renewal date, a licensing change or a data residency requirement forces the timeline. The archive restores into a Cognos environment, so it does not hand dashboards to a new platform. Start by asking your Cognos administrator which archive types your version produces and where the content store database is hosted, because those two facts decide how much of the inventory you can pull without opening the product.
Treat the export capabilities below as a checklist to confirm with IBM before anyone plans work, since we have not verified the exact mechanics for every Cognos version. For each item, confirm whether the archive includes report definitions, package metadata, schedules and recipients, namespaces and groups, and data source connection definitions. Also confirm whether generated outputs such as PDF or Excel files are included, whether stored credentials for data sources are exported or must be re-entered, and whether the content store can be queried directly for a read-only listing. Record the answers in writing against your exact version, because gaps in any one of these items change the rebuild effort.
Some of what you need will never appear in an export, so document it by hand. Capture the business owner, purpose and audience for each report and package, the meaning of each schedule and its recipients, and the filters, prompts and calculations that users depend on. Use the content store or the Cognos usage reporting your administrator can access to flag reports that nobody has opened in a long period, and agree with the business which of them to retire before rebuilding. Keep this inventory in version control or a controlled document store, because it becomes the acceptance list for the new platform and the evidence your compliance reviewers will ask for during the change.
Which Cognos content can be exported and in what form
This table lists the content types in a typical Cognos Analytics estate, the export method for each, the output form and what you must confirm. Where IBM documentation for your version does not settle a format or limit, the table says so. Use it as a checklist: the deployment archive covers most content, but credentials, custom assets and run history often need separate handling before you start an inventory.
| Content type | Export method | Output format and limits | What to confirm or document |
|---|---|---|---|
| Deployment archive | Cognos deployment export from the administration tools | Cognos-specific archive that imports back into Cognos only | Confirm contents, size limits and import rules with IBM for your version |
| Content store metadata for reports and packages | Deployment archive, or IBM-supported access to the content store | Internal Cognos structures, not a documented open format | Confirm with IBM whether direct reads are supported before querying anything |
| Reports and report specifications | Deployment archive, or export of individual reports from the portal | Report definitions are Cognos-specific; rendered outputs such as PDF are separate | Confirm which formats each export produces and keep a list of report owners |
| Framework Manager packages and models | Deployment archive, or Framework Manager project export | Model project files, readable in Framework Manager only | Confirm whether models export separately and record each model's data sources |
| Schedules and subscriptions | Visible in the content store and administration views | Schedule definitions that do not transfer to other tools | Record trigger, recipients, output format and owner for each schedule by hand |
| Data source connections | Connection definitions in the archive, with credentials usually handled separately | Secrets are typically not portable; confirm the behavior with IBM | Plan credential re-entry through your secrets process and list every connection |
| Security assignments | Group, role and capability reports from the namespace or administration console | Tied to your identity sources; confirm the export format with IBM | Document each group, role and folder permission manually as a fallback |
| Custom assets and extensions | Included in the archive where present; confirm coverage | Custom code, themes and extensions may need separate copies | Inventory and back up custom assets outside Cognos before decommissioning |
| Run history and audit logs | Usually outside the migration archive; confirm retention settings | Log formats depend on configuration; confirm with IBM | Export and store audit records separately for your compliance evidence |
Why the deployment archive only imports back into Cognos
The deployment archive is a Cognos-internal snapshot of the environment, not a set of exportable files. It holds the content itself (reports, packages, folders, dashboards, schedules and the permissions attached to them) along with the structures that connect those objects: a report points to the package it runs against, a package points to its data sources, and folder and security entries point to identities defined in a namespace. It also carries environment settings the content depends on, such as data source connection definitions, namespace configuration and the administration settings that control how content is stored and run. Read the archive as one linked set. Pulling a single report out of it leaves its references dangling.
The format is tied to Cognos because those references use Cognos's own object identifiers and metadata model, and the import process expects the same product version and a compatible content store structure. Apache Superset and Metabase have no reader for that format, and they would not know what a Framework Manager package or a Cognos namespace reference means if they did. Confirm the version compatibility and import rules for your release in IBM's Cognos Analytics administration documentation before you plan around them. Assume the archive will never move content into another tool, and plan the rebuild as a separate project that reads from the content store instead.
The archive is still the safest backup and restore point during the exit. Keep a copy with the Cognos version and the matching content store backup, and retain it until the replacement is accepted and the old platform is switched off. The content store is the source you build the inventory from. Query it, or use the administration tools to list reports, packages, schedules, owners and last run dates, and record what each object depends on. Decide who owns the archive, where it is stored and how long it is kept, because those decisions determine whether a rollback is possible at all.
What does not export cleanly and how to handle each gap
A Cognos deployment archive carries a lot, but several things either stay behind, arrive in a form another platform cannot use, or depend on systems outside the archive. Each card below names one such gap, the workaround that fits it, and what to confirm with IBM before you assume the gap is closed or still open.
Framework Manager model logic
Framework Manager packages hold the business logic behind many reports: joins, calculated items, filters, security rules and the query subjects that reports depend on. This logic lives in model files and the package layer rather than in the report output, so reading report definitions alone will not recover it. Document each package's query subjects, relationships and calculations by hand before you rebuild them as Superset datasets or Metabase models. Confirm with IBM which model artifacts your archive version includes and whether the package metadata can be read outside Cognos.
Burst and pixel-formatted output
Bursting, which sends one report to many recipients with personalized filters, and pixel-perfect report formats such as PDF forms, invoices and statements are produced by the Cognos rendering engine. Superset and Metabase do not reproduce that output format, so these reports need a separate decision: rebuild them as dashboards that export to CSV or PDF, move them to a dedicated document or reporting tool, or retire them. Inventory every burst recipient list and output template. Confirm with IBM how burst definitions and their schedules are represented in the archive.
User passwords and credentials
Stored credentials, including data source logons and signon details, are generally protected in the content store and are not portable in readable form. The archive should not be expected to carry user passwords or the secrets used to connect to databases. Plan to re-enter database credentials in the target, issue new service accounts, and use SSO where the target supports it. Confirm with IBM exactly which credential types the archive excludes and how the content store encrypts the rest, because your security team will ask.
Portable group and role membership
Cognos security rests on namespaces, groups, roles and capabilities that are tied to the source directory. Group names and membership may not map one to one onto Metabase permission groups or Superset roles, and nested or inherited memberships can change meaning. Export the directory membership from your identity source, not from Cognos, and map each Cognos group to a target role by hand. Confirm with IBM whether the archive includes namespace and membership data or only references to them.
Rendered output history
Past rendered outputs, such as PDFs, spreadsheets and schedule run logs, are generated results rather than report definitions. They are usually not needed for a rebuilt dashboard, but auditors and records managers may still ask for them. Decide per category whether to keep a read-only archive of outputs, keep the run logs in the content store for a defined period, or accept that history stops at cutover. Confirm with IBM whether run history is in the archive, how long the content store keeps it by default, and whether the archive can be restored into a read-only Cognos instance for retrieval.
The export sequence and how to verify each stage
This sequence turns a Cognos estate into a verified inventory and archive that a rebuild team can work from. Each stage ends with a check and a named sign-off, so nothing is lost when Cognos is retired.
Freeze the Cognos environment version
The Cognos administrator records the exact Cognos Analytics version, build, content store database type and version, and the fix packs applied, then freezes configuration changes for the export window. The owner of the BI platform signs off on the version record. The step is done when the version record is stored with the project documents and a second administrator has read it back and confirmed it matches the running server.
Take and store the deployment archive
The Cognos administrator creates a deployment archive from the Cognos Administration console, covering the content store and the selected folders, and copies it to storage the migration team controls. The archive is only restorable into Cognos, so it is a safety copy rather than a migration format. The step is done when the archive file is checksummed, its size and creation time are logged, and the platform owner signs off that a test restore to a non-production Cognos instance is scheduled or completed.
Extract the content store inventory
Using read-only queries against the content store or the Cognos SDK, the migration analyst extracts a list of every report, package, dashboard, schedule, data source connection and output location, with owner, folder path and last-run date. This inventory is the working source for every later decision. The step is done when row counts for each object type match what the Cognos Administration and team content views show for a sample of folders, and the BI lead signs off the inventory as the baseline.
Document schedules and subscriptions
The analyst exports each schedule with its trigger, recipients, output format and the report it runs, then marks which ones have had recent successful runs. Schedules that produce burst, pixel-formatted or print output are flagged for separate handling because Superset and Metabase do not produce those formats. The step is done when every schedule in the inventory has a disposition field filled in and the business owner of each recurring report has confirmed whether it is still needed.
Document data sources and permissions
The security or identity engineer records each data source connection without its credentials, along with the namespaces, groups and roles that hold access to folders, packages and reports. Permissions are exported where the Cognos tooling allows and otherwise written down by folder. The step is done when the permission matrix covers every top-level folder in the inventory, and the identity owner signs off that group names map to the directory service the new platform will use.
Reconcile the inventory against user-visible content
The migration lead samples folders across departments and checks that each report, package and dashboard in the inventory opens in Cognos and that its owner matches the record. Orphaned or failing items are logged as candidates for retirement rather than silently dropped. The step is done when the discrepancy list is empty or every item on it has a recorded decision, and the business owners of the sampled folders have signed off the reconciled list.
Keep Cognos available read-only
The platform owner switches Cognos access for report authors to read-only or restricts publishing, keeps viewer access for reference, and keeps the archive and inventory under change control. Schedules that would still run are paused only after the business owners have agreed. The step is done when a test account confirms that content can be viewed but not edited, the change is recorded, and the BI lead and the business sponsor sign off that Cognos stays available for reference until the rebuild is accepted.
What your teams must document by hand before rebuilding
The archive carries report definitions, but it does not record why a report exists or who depends on it. Report owners hold that context, and without it a rebuild either copies everything or drops something a team relies on. Ask each owner to confirm the points below for every report in scope, using the content store inventory as the starting list.
- Usage: which reports were opened in the recent period and which have not been opened for a period your retention policy accepts. Usage history is often kept outside the archive, so confirm where your deployment logs it.
- Audience: named people, groups and external recipients, including anyone who receives a report by email or as a file outside the platform.
- Frequency and timing: the business cycle behind each run, such as month-end close or a regulatory submission date, which the schedule alone does not explain.
- Output format: whether the report must be delivered as a fixed-layout file, such as PDF, or as an interactive view, because dashboard tools differ in how they produce fixed layouts.
- Decision to record: keep, merge, retire or rebuild as a dashboard, with the owner's sign-off and the date.
Check that every report in the inventory has an owner, a recipient list and a recorded decision before any rebuild work is scheduled.
Administrators hold the settings that make the deployment work for users: namespaces, groups, data source connections, and the schedule and delivery configuration. An archive of content does not reproduce these settings in a form a new platform can use, and some values, such as credentials, are usually stored encrypted and do not transfer. Document them from the running system and the deployment configuration.
- Namespaces and groups: each authentication source, the membership of each group, the roles granted to each group, and any nesting that determines access. Map these to the identity provider you plan to use, and confirm how the new platform maps groups to roles.
- Data source connections: each connection name, the database type and version, the network path, and the service account it uses. Record who can issue a replacement credential, because the old one will not carry over.
- Scheduling and delivery: each schedule, its trigger, its run owner, the mail server settings, and any file share or external destination. Record the failure notification list as well.
- Capacity and retention: the size of the content store, the backup routine, and the purge rules, which decide how much history you carry over.
- Decision to record: which identity source, service account and delivery channel the new platform will use for each group and connection, and who approves changes to them.
Check this list against the running configuration rather than the original install notes, because changes made after installation are the ones most often missed.
Packages and models hold the logic behind the numbers: joins, calculations, filters and the rules that decide which records count. That logic appears in the archive as definitions, but the reasoning behind each rule usually lives with the modeling team. A rebuild without it can produce dashboards that run correctly but show different totals. Where models are governed in version control, export them there and record any gaps.
- Calculations and filters: each derived measure with its formula and period or currency basis, plus any filter applied inside the model that users may not see.
- Joins and grain: the tables joined, the join type, and the level at which each fact is recorded, since a change in grain changes totals.
- Business rules: exclusions, status mappings, fiscal calendar definitions and rounding conventions, along with the document or decision that set each one.
- Security filters: row-level restrictions tied to groups or users, which must be restated as permissions in the new tool. Metabase lists row and column level permissions only on its paid plans, so confirm the tier you need before design starts.
- Decision to record: which source is authoritative for each measure, the reconciliation totals from the old system for agreed test periods, and who signs off the match.
Check that each model has a named owner and a reconciliation result before you accept any rebuilt dashboard.
What to plan before the Cognos contract renews or ends
The export archive is only one input to the decision. The cards below cover the dates, retention, read-only access, version questions and internal sign-off that shape how much of the inventory you need before a renewal or end-of-term notice arrives. Each one names what to ask IBM or your own teams before work starts.
Set the inventory completion date
Work back from your contract end or renewal notice deadline to fix the date the inventory of reports, packages, schedules and users must be complete. Treat that date as the point after which new content is frozen for export purposes. Ask your IBM account team for the notice periods written into your agreement, and confirm whether any term ends before your internal review finishes. An inventory that finishes after the notice deadline leaves you negotiating from a weaker position.
Decide archive and inventory retention
Decide how long the deployment archive, the exported inventory and the content store extracts are kept, where they are stored and who can read them. These files can contain user names, group memberships, schedule recipients and data source connection details, so they fall under your data retention and access rules. Confirm with your records and security teams whether the archive must be encrypted at rest and whether it can sit in the same storage as other backups.
Keep Cognos read-only during transition
Ask whether your Cognos environment can stay available in read-only mode after the contract ends, and for how long, before you commit to a shutdown date. Business users often need historical reports for comparisons during the first cycles of a rebuilt dashboard. Confirm with IBM what happens to user access, scheduled jobs and the content store when the license term lapses, and whether access is kept for a defined period or cut off immediately.
Confirm version and support dates
Confirm the exact Cognos Analytics version, fix pack and deployment type you run, and the support end date that applies to that line in your environment. Check whether an upgrade path or extended support is on the table, because that changes how urgent the export is. Ask IBM to put the support dates for your version in writing, and record the answer alongside your inventory so the reason for the timeline is documented.
Identify procurement and legal owners
Name who in procurement and legal needs the export evidence: the contract owner, the person who tracks license counts, and the team that signs off on data handling. They need to know what the export proves, such as the number of reports, packages and scheduled jobs, and what it does not prove, such as the fidelity of a rebuilt report. Agree in advance on the format of that evidence so the team does not rebuild the list under time pressure.
Questions buyers ask before exporting Cognos content
How much effort does a full Cognos content export take?
The effort depends mainly on how much content is in scope and how much of it carries logic that does not survive a move. Estate size, the number of Framework Manager packages, the amount of custom calculations and prompts in reports, and the number of scheduled jobs and their recipients all push effort up. An inventory from the content store is the first step, because it turns an unknown estate into a countable list of reports, packages and schedules. Ask any provider for a written scope that states how the inventory will be produced, which object types are included, and which are excluded from rebuilding. Note that Cognos deployment archives are not a conversion format for other tools, so the bulk of the effort is documentation and rebuilding rather than file transfer.
What sets the timeline for exporting Cognos content?
The timeline is set by inventory completeness, the number of packages whose business logic must be documented, the count of schedules and distribution lists that need an owner, and how quickly business users can validate results. No supplied source gives a duration for a Cognos export, so treat any single number as unverified until it is tied to your own estate. Ask for milestones tied to counts you can check: packages inventoried, reports classified as keep, retire or rebuild, and schedules mapped to a named owner. Ask also how stakeholder review sessions are scheduled, since these often become the longest step.
What does a Cognos export require from our own staff?
Your staff must supply knowledge that no archive contains. The most important inputs are the business meaning of each report, the owners who rely on each schedule, the reasoning behind custom calculations and filters, and the security model that restricts data by group or role. A Cognos Administrator is needed to run the content store queries and confirm which objects are active. Plan for named reviewers from finance, operations or other business areas who can confirm that a rebuilt output matches the original. Ask any provider to list these roles in the written scope, with the time each one is expected to commit.
Can a competent internal team export Cognos content without outside help?
Yes, a capable internal team can run the inventory and export, but the rebuilding and documentation work demands skills in both Cognos internals and the target tool. The deployment archive and content store are accessible to administrators, so the mechanics are not the hard part. The harder parts are judging which reports should be retired, translating Framework Manager logic into equivalent datasets, and proving that outputs match. Teams that already maintain Cognos administration and have someone who can build SQL-based models often manage this in house. Teams without that capacity, or with a tight deadline before a licensing renewal or support change, usually gain more from a fixed-scope engagement with written deliverables. Confirm your internal capacity against the inventory before deciding.
Can the Cognos deployment archive be imported into Apache Superset or Metabase?
No. A Cognos deployment archive is designed to import only into a Cognos Analytics environment, so it does not give you reports that open in Apache Superset or Metabase. Its value during a migration is as a backup and as a reference record of what the deployment contained. You still need to export the metadata you need, document it, and rebuild dashboards, datasets and questions in the target tool. Confirm this with IBM documentation for your specific Cognos version before you finalize the plan, and keep the archive as a read-only record until the migration is signed off.
What changes if we only need to export a subset of Cognos content?
A subset export reduces the inventory, rebuilding and review work, but it adds decisions about dependencies. Reports often share packages, and a package that looks unused may feed a schedule or a report you plan to keep. Start by mapping each in-scope report to its package, data source and schedules, then flag shared objects. Ask the provider to include a dependency check in the written scope and to list the out-of-scope items explicitly, so nothing is dropped by accident. Subset work is often the right first step when only a few business areas are moving, because it tests the process on a bounded estate.
What should a written scope for a Cognos export include?
A written scope should name the Cognos version and deployment type, the content store and archive locations, the object types in scope, and the target tool. It should state the inventory method, how each object is classified, the documentation format for business logic, and who signs off each stage. Include what happens to schedules and distribution lists, how credentials and data source connections are handled, and which items are excluded, such as burst or pixel-formatted outputs. DeployOpen plans and implements these engagements on a fixed-scope basis, with scope, deliverables and timelines agreed in writing before work starts, and does not publish a price list, so a quote follows from that written scope.
How DeployOpen scopes and delivers a Cognos export and exit
DeployOpen treats the Cognos export as a fixed-scope piece of work with written deliverables, not a one-off file copy. We inventory what the deployment archive and content store actually hold, document what the archive cannot carry, and hand over an inventory your team can plan a rebuild from.
How we scope
- Written scope names the Cognos environments, content store access and folders in the export.
- Scope states which reports, packages, schedules and users are inventoried and which are excluded.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Deployment archives are generated and checked against the content store inventory.
- Report, package and schedule metadata are exported into a spreadsheet or database inventory.
- Items that cannot leave Cognos, such as proprietary formats and burst settings, are recorded by hand.
How we hand over
- Deliverables include the inventory, a dependency map of reports to packages and data sources.
- A manual documentation register lists schedules, recipients, namespaces and groups to recreate.
- Your team receives the archive copies, checksums and a written walkthrough of every artifact.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover a rebuild review once your team starts recreating dashboards elsewhere.
- Ask for the support scope, response expectations and exit terms in the written quote.
