The ''Upgrade'' process is really a ''RESTORE'' of each project, followed by VERIFY/REPAIR, then UPGRADE on each.

The RESTORE part is basically just using the DBID.xml file to tell QC where the DB and repository are supposed to be for a given project. Site Admin expects the DBID.xml file to be LOCAL to the PC running Site Admin (you *could* make a copy of the file(s) for each of your ''admin'' users that you have divvied up the work to). All of these ''restore'' operations simultaneously will not be too much of a performance hit.

Now, if your projects are all ''restored'' (the Site Projects tree points correctly to the projects), your remaining VERIFY/REPAIR/UPGRADE tasks WILL be a performance hit on the QC and DB server and it would happen faster if it were more or less sequential.

You CAN direct maintenance tasks to happen for a DOMAIN (rt-click maintain domain/VERIFY), it will sequentially step down the list of projects (selectable) in a domain and do VERIFY, for instance.

There is also the NEW ALM Robot tool that can help automate your migration and upgrade tasks.

https://hpln.hp.com/page/hp-alm-robot-automatic-upgrade-tool

Again, this one is running SEQUENTIALLY.

We have upgraded 7 unique projects by using ALM 12 SA via 7 Site Administrator's it worked without any issues.However our application server RAM and CPU resources are highly configured.

Hi PT Barnum,

Thank you for your response.

We looked into ALM Robot, [I might be wrong], but it looks like the tool wants the upgrade to happen between two servers. For example: the tool seem to work by copying project repos and db from Server-A (ALM-11) to Server-B (ALM-12).

In our case:

1) We have Server-1 running only ALM-12

2) Server-2 is the QC database for ALM-12 (running Oracle 11g)

3) Currently, Server-2 contains ALM-11 qcsiteadmin_db and ALM-12 qcsiteadmin_db (called qcsiteadmin12)

4) Also, Server-2 contains all ALM-11 projects DBs/Schemas

5) NOTE: When ALM-12 was installed on Server-1, we choose ''Upgrade a copy of the existing Schema''.
Hence, ALM-12 SiteAdmin points to qcsiteadmin12 schema

6) Currently, when logged into ALM-12 Site Admin interface, we see all our 170+ projects.

7) But, the QC projects and their DB/Schema are still in ALM-11 format.

8) Hence, From ALM-12 Site Admin interface, we'll need to VERIFY, REPAIR, and UPGRADE each project and DB/schema to ALM-12 format

9) NOTE: Server-1 contains all the QC projects REPOS already

10) Both ALM-11 and ALM-12 are using Oracle 11g

11) So, you see in Summary, Server-1 contains only ALM-12 and all we need to do now is to VERIFY, REPAIR, and UPGRADE each project and DB/schema to ALM-12 format

12) #11 above is what we hope we can automate using ALM Robot all on ONE server running QC-12 with project repositories already copied on the server's local disk.

Thanks for your reply in advance!

Best regards,
Felix

What you are doing is often called an ''in-place upgrade''.

Since you already have DB's and Repositories in the correct place (according to the upgraded qcsiteadmin_db), all you really need to do after confirming the list of Site Projects is pointing correctly to them is do the VERIFY/REPAIR/UPGRADE tasks.

This can be done WITHOUT using ALM Robot (they are already there and do not need migration).

Rt-click on the DOMAIN and you can do a ''bulk'' maintenance run for either VERIFY, REPAIR or UPGRADE.
Still, it will step down the list of the projects that are checked in the list.

In my experience, doing a bulk operation ALWAYS gets halted by a rogue project or two (requiring manual intervention) and you end up doing them one at a time anyway.

Having multiple people launching these VERIFY/REPAIR/UPGRADE tasks from different PC's with Site Admin may not make anything happen any faster -- you still have a load on the QC server (work in the repository) and Oracle server (work on Schemas) -- the more you ask it to do, the slower it works overall.
You also need to pay special attention to the logs/reports given at each step as there is often manual intervention required (forgetting to check all VC objects back in for a project, or extra/missing columns or tables, for instance).

Either way, ALL of your desired ''active'' QC projects must have these tasks run on them before working in ALM/QC12.

Hi PT Barnum,

Thank you again for your response!

Yes, you're right...I'm quickly realizing that ALM Robot is not specifically designed for ''In-place'' upgrade. I was hoping that ALM Robot will help automate the MANUAL process of VERIFY/REPAIR/UPGRADE. As you noted, I think the best thing now is to upgrade each project one at a time.

The only other issue now is that it's impossible to upgrade 170+ projects in a weekend. So, I'm not sure how to run ALM-11 and ALM-12 on the same server. This is because as soon as I upgrade our PRODUCTION environment to ALM-12, any team's project that's not upgraded during live run weekend will be offline until their projects are upgraded to ALM-12. The downtime/offline possibility is unavoidable, but will not be allowed by management for business reasons. Do you have any suggestions? Or, have you successed in running ALM-11 and ALM-12 on the same server before?

Another alternative I'm thinking about[on the live run weekend] is to upgrade the current PRODUCTION server from ALM-11 to ALM-12. Then install ALM-11 (with a copy of the current production qcsistadmin_db) on a second server (this will be done before the live run weekend).

So, users/teams with any QC projects that were not upgraded to ALM-12 on the live run weekend, will be directed to point their browsers to the ALM-11 server. But, when a project gets upgraded, that project will be deactivated on the ALM-11 server and the team will be directed to point to the ALM-12 server.

Other than the above, I'm not sure of any other way to accomodate ALM-11 and ALM-12 users at the same time. Do you? It's impossbile to upgrade 170+ projects in one weekend. I think it will take about 2-weeks to upgrade all projects.

Thanks for your reply in advance!

Best regards,
Felix