Tag: Banking

Delivering a Smooth IBM Cognos Analytics Upgrade at Scale
Delivering a Smooth IBM Cognos Analytics Upgrade at Scale

Upgrading IBM Cognos Analytics is never just a technical exercise – especially when it powers the reporting backbone of a major bank. Recently, we successfully upgraded their IBM Cognos Analytics platform to version 11.2.4, a mission-critical project impacting thousands of users and core business processes.

Here’s how we delivered a smooth upgrade at scale.

The Scale of the Challenge

Before touching any servers, we mapped the full scope of the environment:

Users: Over 1,000 daily users across multiple business units
Content: 3,000+ reports
Environments: 8 separate environments from Development through to Production
Infrastructure: 20+ servers across multiple data centers
Integrations: Deep links with Control-M, Informatica and multiple databases systems
Custom Components: Multiple SDK-based applications requiring compatibility updates

This understanding shaped every part of our approach and risk planning.

How We Planned the Upgrade

We treated the upgrade like a full-scale project, not just a technical task:

Infrastructure Readiness
Built and hardened new servers for Cognos 11.2.4
Verified firewall rules, load balancer configuration and storage capacity
Content Audit & Cleanup
Identified and archived unused reports to reduce migration complexity
Updated documentation and ownership metadata
Multiple Dry Runs
Rehearsed the full upgrade end-to-end across lower environments
Measured timings and captured lessons learned in a runbook
Stakeholder Engagement
Communicated timelines and freeze periods across all business units
Coordinated test coverage with key user groups

Executing the Upgrade

The production cutover took place over a planned weekend window:

Performed a parallel install of Cognos Analytics 11.2.4 alongside the existing environment
Migrated and upgraded the content store
Updated and validated SDK applications for the new version
Verified Control-M and Informatica integrations
Conducted extensive regression testing with 40+ business testers

By Monday morning, all users were on the new version with no disruption.

Behind the Success

This upgrade reinforced some important principles for large-scale enterprise projects:

Automate Everything
We scripted the upgrade using PowerShell to eliminate manual errors and ensure repeatability.
Rehearse Relentlessly
By perfecting the process through multiple rehearsals, we turned a complex cutover into a routine operation.
Prioritize Compatibility Early
Updating SDK based applications and custom code ahead of time saved critical hours during go-live.
Communicate Constantly
Transparent updates kept stakeholders informed and reduced post-upgrade support noise.

The Outcome

We delivered a seamless upgrade of IBM Cognos Analytics to 11.2.4 – across 8 environments, 20+ servers, 1,000+ users and 3,000+ reports – without any business disruption.

Planning Your Own IBM Cognos Analytics Upgrade?

Upgrading IBM Cognos Analytics at scale can feel daunting – but with the right approach, it doesn’t have to be.

If you’re planning an upgrade and want to avoid disruption, accelerate delivery and reduce risk, let’s talk.
21 February 2024
Seamless IBM Cognos Analytics Data Center Migration
Seamless IBM Cognos Analytics Data Center Migration

Moving an enterprise IBM Cognos Analytics estate between data centers is a very different challenge from installing Cognos into a new environment.

When the requirement is to migrate the existing Cognos servers and workloads to new data centers, the objective is to preserve the existing platform while changing the underlying infrastructure around it and to do so with as little disruption as possible.

We recently architected and executed the migration of a complete IBM Cognos Analytics estate across to two new data centers. The servers themselves were migrated rather than rebuilding and reinstalling the Cognos platform.

At the same time, automated disaster recovery was implemented using Zerto, providing continuous protection and a resilient recovery capability.

The project reinforced an important lesson:

A successful data center migration is not about moving servers from A to B. It is about moving a live, interconnected business service while keeping the experience for users unchanged.

The Challenge

An established Cognos environment contains much more than the Cognos software itself.

Over time, the servers become part of a wider enterprise ecosystem. They have established network connections, database connections, authentication dependencies, shared storage, scheduled processes and integrations with other systems.

The challenge was therefore to migrate the existing servers while maintaining the behaviour and functionality of the Cognos estate.

The key objectives were:

Migrate the existing Cognos servers to two new data centers
Preserve the existing Cognos environments and configurations
Minimise disruption to users
Maintain connectivity to dependent systems
Validate the complete reporting service after migration
Provide automated disaster recovery
Ensure the migration could be performed in a controlled and repeatable way

Understand what you’re actually moving

One of the first lessons from a migration like this is that the server is only one part of the service. A Cognos server can be moved successfully and still not provide a working Cognos environment if one of its dependencies hasn’t followed it.

The migration therefore required a detailed understanding of the existing infrastructure and its relationships with other systems.

This included:

Cognos application servers
Content Manager
Application Tier components
Gateway components
Databases
Shared file systems
Authentication services
Network connectivity
Firewall rules
DNS
Scheduling and integration services
External systems consuming Cognos outputs

The important question wasn’t simply “Can we move this server?” It was “When this server starts in the new data center, will everything it depends on still work?”

That distinction is fundamental to infrastructure migration.

Migrating the existing servers

Because the existing Cognos installations were being migrated rather than rebuilt, preserving the server state was critical.

The objective was to move the workloads while maintaining the existing application configuration. That meant avoiding unnecessary changes as every additional change introduces another variable into a migration.

If the server, operating system, Cognos configuration, application settings and integrations are all changed at the same time, identifying the cause of a problem becomes significantly harder. Therefore keeping the existing Cognos environment intact reduced that risk and the migration became primarily an infrastructure and connectivity exercise rather than an application rebuild.

Two new data centers

The target environment consisted of two new data centers, which introduced additional considerations around network connectivity, routing, firewall configuration and the relationship between the two locations.

The migration wasn’t simply about relocating servers geographically. The new architecture needed to provide the connectivity required for the Cognos estate to continue operating as it had previously. This included ensuring that the systems Cognos depended on remained reachable and that users and downstream systems could continue accessing the platform.

Zerto and continuous protection

A particularly important part of the new architecture was the use of Zerto for automated disaster recovery. Zerto provided continuous replication of the workloads, creating a protected recovery path between the environments.

This had two significant benefits:

It provided an improved disaster recovery capability for the migrated Cognos estate.
It reduced the risk associated with the migration itself.

A major infrastructure migration always carries some level of uncertainty. Having continuously protected workloads means that if something unexpected happens, there is a recovery mechanism already in place. That is very different from relying on a backup taken before the migration and hoping that everything works afterwards.

Disaster recovery shouldn’t be an afterthought to a migration. It should be part of the migration strategy itself.

Minimising downtime

The goal wasn’t simply to make the migration work, it was to have minimal disruption to users during the transition.

A large Cognos estate can support critical reporting throughout the business. Even a relatively short outage can have a significant impact if it coincides with important reporting or operational processes.

The migration therefore needed to be carefully planned around the point at which workloads were transitioned to the new data centers. The more preparation that could be completed beforehand, the shorter and more predictable the final migration window became. This is one of the most important principles of infrastructure migration:

Don’t use the production change window to discover whether your migration works.

The migration should have already been rehearsed, tested and understood.

Testing the service, not just the servers

A server being online doesn’t mean the migration is successful.

After moving the Cognos workloads, validation needed to happen at the application and business-service level.

That means checking things such as:

Cognos Analytics is accessible
Reports execute successfully
Dashboards work
Data sources remain accessible
Scheduled reports execute
Outputs are generated correctly
File-based dependencies work
Integrations continue to operate
Background processes function correctly

This distinction is particularly important with enterprise platforms. Whilst infrastructure teams may see a collection of healthy servers, business users see whether they can run their reports. The migration is only successful when both views agree.

The hidden complexity is outside Cognos

One of the biggest lessons from the migration was that many of the potential problems weren’t actually inside Cognos.

They were in the surrounding infrastructure.

A firewall rule.
A DNS entry.
A database connection.
A file share.
A network route.
An authentication dependency.
A downstream integration.

These are the things that can turn a seemingly straightforward server migration into a much larger problem. Understanding these dependencies before the migration therefore becomes one of the most important activities in the project.

Automation and repeatability

Automation also played an important role. Because the larger the estate, the more difficult it becomes to rely on manual processes.

Migration activities need to be predictable. Validation needs to be repeatable. And where possible, the same checks should be performed consistently across environments.

Automation isn’t just about saving time, it reduces the number of opportunities for human error and makes the migration process easier to rehearse. That becomes particularly valuable when you’re moving multiple environments and servers.

Have a rollback strategy

One of the most important questions during any migration is: What happens if something doesn’t work?

A rollback strategy should be considered before the first server is moved. It needs to be practical and understood by everyone involved.

This is another area where the Zerto implementation provided significant value. Continuous protection meant that the migrated workloads had an established recovery mechanism rather than relying solely on traditional backup and restore procedures. The result was a much stronger position from which to perform the migration.

The biggest lesson

Looking back, the most important lesson wasn’t about Cognos itself. It was about risk management. The migration worked because the existing Cognos estate was treated as a business-critical service rather than simply a collection of servers.

The servers were migrated rather than rebuilt.

Dependencies were understood.

The target data centers were prepared in advance.

The migration was tested.

Downtime was minimised.

And automated disaster recovery using Zerto provided continuous protection.

That combination changed the nature of the project. Instead of asking “How do we rebuild Cognos in the new data center?” The question became “How do we safely move the existing Cognos service while keeping it operational?”

That is a much better way to approach a complex infrastructure migration.

Moving infrastructure without moving the risk

Data center migrations are often viewed as infrastructure projects, but for platforms such as IBM Cognos Analytics, they are really business continuity projects.

The technology may be moving, but the business still expects its reports to run, its dashboards to be available and its scheduled processes to continue.

The best migrations therefore make the underlying change almost invisible to the people using the system. The servers may have moved. The data centers may have changed. The disaster recovery architecture may have been significantly improved. But from the user’s perspective, Cognos should simply continue to work.

That’s what makes a data center migration successful. Moving the infrastructure without moving the risk to the business.
21 May 2023
Upgrading IBM Cognos Analytics: A Large-Scale Bank Migration Success Story
Upgrading IBM Cognos Analytics: A Large-Scale Bank Migration Success Story

Upgrading IBM Cognos Analytics in a large financial organisation is about far more than installing a new version of the software. When the platform supports thousands of users, thousands of reports and business-critical integrations, the upgrade becomes a major technology migration – one that needs to be carefully planned, tested and executed with minimal disruption.

We successfully delivered a large-scale Cognos Analytics upgrade for a major banking organisation, migrating from IBM Cognos 10.2 to Cognos Analytics 11.1.7 across a multi-environment estate.

The project involved approximately 3,000 users, 2,400 reports and multiple bespoke applications, requiring a structured approach to infrastructure, application compatibility, testing and migration.

The Challenge

The bank’s existing Cognos 10.2 platform was a mature and heavily integrated reporting environment. It supported:

Approximately 3,000 users
Around 2,400 reports
Multiple Cognos environments
Bespoke Java applications using the Cognos SDK
Enterprise scheduling and integration processes
Business-critical reporting across the organisation

The challenge was to introduce the new platform while ensuring that existing reports, integrations, applications and user functionality continued to work as expected. With thousands of reports, traditional manual regression testing would have been extremely time-consuming and would have provided limited confidence across the entire estate.

Building The New Platform

Rather than upgrading the existing servers in place, we established new virtual machine infrastructure for Cognos 11.1.7. This provided a clean and controlled target environment for the migration.

The approach also reduced the risk associated with making significant changes directly to the existing production platform. The legacy Cognos environment could remain available while the new platform was built, configured and tested.

A Phased Migration Strategy

The upgrade was delivered progressively across the different environments, with the migration beginning with the sandbox and test environments, allowing the team to identify issues early and refine the migration process before moving towards the more critical environments.

The phased approach provided several advantages:

Early identification of compatibility issues
Validation of the new infrastructure
Opportunity to refine deployment processes
Early testing of reports and applications
Reduced risk when moving towards production
Greater confidence for business stakeholders

Each environment provided another opportunity to validate the platform before progressing to the next stage.

Automated Regression Testing

One of the most important components of the project was the use of Cognos Lifecycle Manager for automated regression testing. With approximately 2,400 reports, manually running and comparing reports before and after the upgrade would have been impractical.

Lifecycle Manager provided a way to systematically compare report results between the existing Cognos 10.2 environment and the new Cognos 11.1.7 platform. This allowed the team to identify potential differences and focus investigation on reports where the upgrade had introduced a change.

Automated regression testing significantly increased confidence in the migration and helped turn what could have been a largely manual testing exercise into a structured, repeatable process.

The Cognos SDK Challenge

The upgrade was not limited to Cognos reports. The bank also had bespoke Java applications that used the Cognos SDK. These applications represented an important dependency because changes between Cognos versions could affect SDK functionality and application behaviour.

As part of the upgrade, these bespoke Java applications were reviewed and upgraded to work with the new Cognos 11.1.7 platform.

A Cognos upgrade can appear successful from the perspective of the standard Cognos interface while still breaking applications that interact with the platform programmatically. By treating the SDK-based applications as part of the migration rather than an afterthought, we were able to validate the wider Cognos ecosystem.

Testing Beyond The Reports

The testing strategy therefore covered much more than report output. Validation included:

Report execution
Report output comparisons
Scheduled reports
User access and security
Data source connectivity
Cognos configuration
SDK-based Java applications
Integration points
Business-critical reporting processes

The combination of automated regression testing and targeted functional testing provided broad coverage while allowing specialist effort to be focused on areas where differences or compatibility issues were identified.

Production Migration

By the time the project reached the production environments, the migration process had already been proven through the earlier sandbox and test environments. The team had:

Built and validated the new VM infrastructure
Refined the Cognos migration process
Tested approximately 2,400 reports
Used CLM for automated regression testing
Upgraded bespoke Java applications using the Cognos SDK
Validated integrations and critical functionality
Progressively migrated and tested the environments

This meant the production migration was not an unknown event. It was the final stage of a process that had already been tested and refined.

The outcome

The bank successfully migrated from Cognos 10.2 to Cognos Analytics 11.1.7 across its Cognos estate and the project delivered:

Cognos 10.2 → Cognos Analytics 11.1.7
Approximately 3,000 users
Approximately 2,400 reports
New VM infrastructure for the upgraded platform
A phased migration across environments
Automated regression testing using Cognos Lifecycle Manager
Upgraded bespoke Java applications using the Cognos SDK
Comprehensive validation of reports, integrations and applications
A controlled transition into the production environment

What Made The Project Successful?

The key to the project was treating the Cognos upgrade as an end-to-end platform migration, rather than simply a software upgrade. Three principles were particularly important.

Start small, then scale

Beginning with sandbox and test environments provided a safe place to identify problems and refine the approach. By the time production was reached, the migration process was well understood.

Automate regression testing

At 2,400 reports, manual testing alone would have been inefficient and difficult to repeat. Using Cognos Lifecycle Manager provided a scalable approach to regression testing and gave the project greater confidence in the upgraded platform.

Don’t forget what’s outside Cognos

The Cognos platform rarely operates in isolation. Bespoke applications, SDK integrations, scheduling systems, data sources and downstream processes can all be affected by an upgrade. Including these components in the migration scope was essential to delivering a successful outcome.

The Bigger Lesson

Large-scale Cognos upgrades are ultimately about reducing uncertainty. You cannot eliminate every risk from a major platform migration, but you can progressively reduce it through good architecture, phased implementation, automation and comprehensive testing.

For this bank, the combination of new infrastructure, a phased migration strategy, automated regression testing and application remediation provided a controlled route from Cognos 10.2 to Cognos 11.1.7.

The result was not simply a newer version of Cognos. It was a modernised and validated analytics platform capable of supporting approximately 3,000 users and 2,400 reports, with the wider application ecosystem upgraded alongside it.

Planning An IBM Cognos Analytics Upgrade?

We help organisations assess, plan and deliver complex Cognos upgrades and migrations – from individual environments to large enterprise estates.

Talk to us about your Cognos environment and how we can help you plan your next upgrade.
1 June 2021