In my experience, it over-simplifies the process and tends to obscure issues when upgrading - UNLESS, all of your projects can easily pass the ''Verify'' and ''Repair'' steps with no issues at all.
Also, it does not migrate your DB's - you are expected to do that properly.

It *can* migrate repositories, but it takes lots of tinkering to get it to correctly share access between the OLD and NEW repository folders over the network and relies on Windows to transfer files - sometimes Windows chokes when copying large numbers/total size of files.

INSTEAD:
Do it the old fashioned way: MANUAL migration of DB's and repositories.
Followed by REMOVE'ing each project, editing DBID.XML to point to NEW DB and repository locations, then running VERIFY / REPAIR / UPGRADE.

Now, this can be sped up by restoring the repository folders from backup instead of waiting for (and trusting a Windows file copy), but repository migration takes the longest of all of the steps.

Also, you can do the Maintain steps (verify, repair, upgrade) ''in bulk'' by selecting a domain and indicating multiple projects to act on.

NOW, when you do things in bulk, it is up to the upgrader (you) to carefully review all of the logs to be sure it is ready for the next step - this is why Robot is a problem, it obscures issues with the process.

Another thing to keep in mind is that starting with QC11.52, there is another ''project'' called ''LAB_Project'' that needs to be upgraded as well.
This happens automatically when installing the newer QC (if the project has already been migrated), or it can create a new/blank one -- most customers don't use it and can live with a blank one, but if they use it in older version (11.52 or later), they need to also migrate it (similar to a ''regular'' project) and allow installer to upgrade it.