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.