Installation, Upgrade, and Deployment Planning
Planning the deployment model
Cognos Analytics 12 planning is container-first: the server runs as container images on Red Hat OpenShift or Cloud Pak for Data, and configuration is supplied through the custom resource and Kubernetes secrets rather than only through the legacy configuration file. The exam tests whether you can choose a supported topology, size it, and sequence an upgrade without losing content or security.
Core rules
- Confirm the platform support matrix, database version, identity provider, and third-party JDBC drivers before installation.
- Size for peak concurrent users, not named users; account for report service, batch, and query workloads separately.
- Plan external content store, notification, and audit databases; do not co-locate the content store on an application node.
- Back up the content store and configuration before any upgrade; the content store schema is upgraded, not replaced.
- Treat export/import deployment as content promotion between compatible environments, not as an upgrade mechanism.
Worked example
A team moving from 11.2.x to 12 inventories custom extensions, Java authentication providers, and modified system files. They restore a content store copy into a test database, run the upgrade against the copy, then validate signons, schedules, capabilities, and data source connections. Only then do they repeat the sequence in production with a maintenance window and a rollback backup.
Traps
Assuming a deployment export upgrades binaries; forgetting that custom Java providers must be rebuilt for the new version; ignoring driver compatibility; and testing only with an administrator account, which hides permission and capability regressions.