Hi Mark,

I don't understand the source server minimal downtime requirement. Do you want to move all people to the new server and continue work there or do you want to create an isolated test environment?

The question, I think, comes down to if you keep the DB or create a new DB.

In general you could try to follow https://jazz.net/library/article/547 it is only for RTC, but applies to CLM too, if you add the other tools similar to RTC.

If you want to move to another server, I would try to set up the other server first and make sure it works and you have all the right values. This could include running a setup e.g. with derby as DB. If you overwrite the configuration files and index files and provide a different DB later there should be no harm done running a setup to make sure the deployment works.

To restore on the new server, assuming you clone the databases from a backup for an isolated test system I would on the source server:
- back up the configuration files for all applications and restore them on the new server, change the database connection info in the configuration.
- suspend indexing on the source server for all applications. The applications can stay productive.
- backup the index files.
- resume indexing
- stop the server and back up the databases
- restart the server


the old server is productive again.

On the new server
- make sure the config files are correct and will point to the cloned databases.
- Make sure the system is isolated and won't be able to conflict with the old one.
- restore the index files - please note, I have not tried if this works for different server architectures.
- Restore the new database clones from the backups
- bring up the server.

If data loss is acceptable e.g. for a test system, using online backups could further reduce downtime. You could select consistent online backup data for all databases from one point in time while the old server is running.

If you want to move to the new server (keeping the URI) and keep the original DB2 databases the approach would be similar

- back up the configuration files for all applications and restore them on the new server.
- suspend indexing on the source server for all applications. The applications can stay productive.
- backup the index files.
- restore them on the new server
- stop the source server

On the new server
- make sure the new server can act using the old URI
- bring up the server with the restored configuration files - it should run on the original data.
- restart indexing

Needless to say I would do a test run and make sure there are backups.

Hi Mark,

the steps are the same with repotools. I am not sure about the indexing. Although people use it for that purpose, I personally would not advise to do so, unless you have to change DB vendors. It depends on you database size. Please try out a repotools export to understand the time impact. The export and import has to change data formats and load the data back in. It is generally slower than just a backup of the database.

So if you are concerned about downtime, I would consider not using repotools.

Hi Mark,

I don't think that changing the architecture from Win to AIX is a vendor change. I would assume you can just restore a backup from DB2 windows on DB2 AIX.

You need to run the backup or the repotools for all servers. Each repotools command only exports one DB. The same applies to the indexes.

I am not an expert for the reporting. As far as I know there is no solution for changing the vendor for RRDI today. As far as I know there is no means to export and re-import the Datawarehouse today.

I assume you can either move the database to another server, keeping the vendor or install fresh. If you install fresh you loose historical data. I think for work items there is a mechanism to recreate historical data but I have not tested that either.

Mark,

if you want to stick with repotools for the database backup/restore, please read this blog Boris posted yesterday: https://jazz.net/blog/index.php/2012/02/07/ensuring-faster-migrations-between-database-instances-vendors-and-product-versions-2/