Hello, everyone.

I have a customer who is interested in migrating from his current deploy to a situation where he would have one instance of the JTS running with CCM, QM and RM, all in version 3.0.1. His current deploy is described below:

He has RTC 3.0, RQM 2.0.1 and RRC 2.0.0.3, all installed as different services (each with it's own tomcat instance) in the same machine, with each service knowing the other two as "friend" services.

Each is installed with (what seems to me) non-conflicting context roots:
RTC as https://rtc.domain/ccm; RRC as https://rrc.domain:rrc-port/rdm; RQM as https://rqm.domain:rqm-port/jazz

Problem is, it is my first time migrating the whole suite and I'm wondering what kind of problems I might face. Specially when it comes to the "jazz" context root used by RQM.

I plan on installing a Jazz Team Server with CCM 3.0.1 and migrating it first, then adding both the RM and QM modules to it, but I'd love if you guys could provide some pointers, docs and things to keep an eye on while doing it, to avoid problems.

Thanks.

Hi Alexandre here my thoughts:

1. Please go through the upgrade workshop in the library. Best would be if you did the workshop yourself.

2. I would discourage to migrate to a one Tomcat/one host installation. One of the reasons is you would loose all flexibility for splitting up in the future. Best would be to have the context roots virtually split as the CLM help suggests: http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/index.jsp Please read the topology considerations.

3. There are no conflicts in the application names as part of the URI's since the customer apparently started with RTC3 but there is another potential part of the URI that could prevent going to one tomcat. One Tomcat can - as far as I know in the standard way we install only listen to one port. If the ports are different it would be impossible to migrate to one Tomcat.
There is another caveat where I don't know if that is solvable. Is it possible that one tomcat provides a signed certificate for several host names? The host name ins fix in a certificate. You would have untrusted connections to the other host names. This might be solvable with techniques like virtual hosts but would require testing etc.