It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,884
×10,958
×5,944
×4,320
×3,951

question asked: Aug 16 '16, 12:45 p.m.
question was seen: 2,544 times
last updated: Aug 17 '16, 3:04 a.m.

Related questions

what is the migration approach to migrate CLM on AIX and Oracle to Windows platform using MS SQL Server?

0
Gary Dang (593●3●89●55) | asked Aug 16 '16, 12:45 p.m.
what is the migration approach to migrate CLM on AIX and Oracle to Windows platform using MS SQL Server?

Current environment: CLM 4.0.3/IHS/WebSphere and Oracle DB deployed AIX 7.1 LPARS
Target environment: CLM 6.0/IHS/WebSphere and MS SQL Server deployed on Windows platform.

Some initial high level questions..
1) Oracle DB to MS SQL Server db migration - not sure about feasibility of this.  Not sure if we can do this without 3rd party tool.  We might have to create delimited data dump and import into SQL worse case but not sure CLM likes this or not.
2) URI change - how does the URI change (certain URI will change) impact existing data?
3) Would IHS and WAS configuration settings on the source (AIX) be re-used in target (Windows)?

Another approach possibly is to export CLM data and import them into the target CLM but work item IDs and probably links will be impacted.

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Kevin Ramer (4.5k●9●186●201) | answered Aug 16 '16, 2:08 p.m.
1) Use repotools -export to write a platform / db independent file for import.   You'll need to do this for each application ( jts, ccm, etc ).   You will have to import using the same version of CLM that you export, then upgrade using the provided upgrade scripts.   This will require that each application be off-line and could take many hours just to export.

2)  You could get a rename key and rename your URLs after moving but before upgrading.  There are numerous writings on the rename within jazz.net.  Search on "server AND rename" ( no quotes in the search, those are there for you).   If your new hardware is going to be in the same "neighborhood" I would try to avoid rename by moving the current hostname to the new IP ( if possible ).  Granted there are reasons why one cannot ( e.g. divestment, acquisition, etc ).

3) The IHS/WAS will be similar but not likely exact as due to the possibility of renaming the server the SSL certificates in use will make client users unhappy ;-)


Comments
Gary Dang commented Aug 16 '16, 2:46 p.m. | edited Aug 16 '16, 7:05 p.m.

hi Kevin Ramer, thanks for the quick response!  Regarding..

1 - can you help confirm that the work item ID will not change? 


       - the total size of all the 3 CLM dbs in the source is around 50GB, is there a rough estimate on export/import?
       - both the export/import (https://jazz.net/help-dev/clm/topic/com.ibm.jazz.install.doc/topics/r_repotools_export.html, https://jazz.net/help-dev/clm/topic/com.ibm.jazz.install.doc/topics/r_repotools_import.html) refers to the teamserver.properties file.  I am not sure if this means I have to restore this file from the source onto the target.  Can you comment?
       - do we need to do stuff like rebuild indexes after the import? Is there link to a guide we can follow?
       - it looks there is repotools for each app (e.g. repotools-ccm, repotools-rm, repotools-jts, repotools-jts).  don't we also need to export data warehouse data as well? If so, is there a separate repotools utility for that as well?
     - I think the repotools import will restore all data as well as process specification, please confirm.

2 - the source CLM environment is in a completely different network/environment than the target CLM.  So, we will have to use server rename.



3 - I think it will be ok not to re-use the same content of the config from the source.  We will standup a CLM instance on Windows in the target environment just like what we are doing today and then manually adjust the WAS config in the target based on the source if necessary.   However, as noted above, it might be mandatory to re-use the same teamserver.properties.  Are there other CLM or WAS config files we should worry about?


Kevin Ramer commented Aug 16 '16, 3:00 p.m.

The export is an image of existing data suitable for import.  If memory serves you will need to create an empty database for each application prior to import and edit the teamserver.properties for the JDBC connection.  Work item ids will not change.  It is possible to move the index files across machines.  Those locations in the teamserver.properties would need to be copied from one machine to the other and the new teamserver.properties updated.   There might also be concerns regarding authentication configuration.  E.g. if current is LDAP, will the new have access to that same LDAP.

Gary Dang commented Aug 16 '16, 3:19 p.m.

good point on LDAP.  In our scenario, the source environment has its own authentication although I am not sure if it is LDAP or local defined users.  However, in the new target environment, CLM will be hooked up to our LDAP server which is completely different directory service. So, bottom line is the LDAP (even source and target env are using Microsoft AD for example) is completely different.  For example, do all existing users in the source env get new enterprise ID within the LDAP used by the target.  The LDAP group name mapping in the target will map to the new LDAP group where all these new users will be part of.  I am not sure how this affect access (if using Access Control) or permission of existing work items. What is the approach regarding this issue?

Also, can you comment on the data warehouse question regarding export/import as well?

Ralph Schoon commented Aug 17 '16, 3:01 a.m. | edited Aug 17 '16, 3:02 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

The documentation: https://jazz.net/help-dev/clm/topic/com.ibm.help.common.jazz.calm.doc/topics/c_node_jts_upgrading.html
You can find the specific instructions for your version in the documentation: https://www-01.ibm.com/support/knowledgecenter/SSYMRC/clm_family_welcome.html

You have to upgrade from 4.x to 5.x and then from 5.x to 6.x. You can migrate the environment at any step.

Suggestion: use a backup and restore a test environment on a disconnected network and test upgrade and migration. That provides you with detailed steps, an idea of how long it takes and all the details.

LDAP: the user ID's must match. If they don't, make them match, before connecting the new LDAP. see https://rsjazz.wordpress.com/2012/10/12/changing-the-jazz-user-id-using-the-rtc-plain-java-client-libraries/ for ways how to do that.

Ralph Schoon commented Aug 17 '16, 3:04 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

There is no way I am aware of to migrate the datawarehouse. The new data warehouse will get recreated, but you will loose data for items that are deleted (e.g. build results).

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.