Question - What is the Windows equivalent for the linux command to run the CloudBees CD (CloudBees Flow) upgrade script?
The Windows equivalent command to the linux command would be:
\bin\commander-upgrade
Where is the path to your CloudBees CD (CloudBees Flow) installation, which by default is this:
C:\Program Files\Electric Cloud\ElectricCommander
Question - C an we upgrade directly to 5.3 from our current 4.2.2 on SQL server 2012?
Yes, but we highly recommend that you make a copy of your production database first, and run this on a test server. This will give you a better familiarity with the upgrade process, and also allow you to determine the time that it will take when you need to stop your CloudBees CD (CloudBees Flow) server (which you will need to do for the final installation). If you need a license for a test server, let us know and we can generate a short term license for you to run these tests.
Question - C an we run the background database upgrader while still serving current 4.2.2?
Yes, the background upgrader is designed to be run while your 4.2 server is running - it upgrades your database in the background, by making the necessary changes from your original database (4.2) into your target database instance (5.x). Both your original and target instances need to be within the same database installation (i.e. not in separate DB servers). You will most likely want to run the background upgrader more than once, as the first run will do most of the upgrade on the DB as it exists when you start the background upgrader. The second time that it runs, it will do the upgrade on all changes that have been made since the first run was started.
Question - How to pause the background database upgrader if needed?
You cannot pause the background upgrader once it has started. If you stop it while it is running, you will potentially corrupt the new database instance, and will need to remove it and start over again.
Question - What is the best value of COMMANDER_DB_BATCH_SIZE if we don’t want to sacrifice the current production performance?
You should run with the default setting as that is how we found it best runs in most situations, you should change it only if you are having problems during the upgrade
Question - After the software upgrade, will we need to switch to the 5.3 database and the original database will need to delete manually later?
Yes, the installer will not delete the the old DB for you, you will need to do that yourself once the install is complete.
Question - What is the rollback procedure if needed…assuming we have all of backups?
If you for any reason need to roll back, you would re-install 4.2 and point it at the old database instance instead of the new one.
Question - What are user common mistakes related to the upgrade?
There is a section in the Install Guide named: Troubleshooting the Database Upgrade
There is also a KB article:
KBEC-00285 - Background Upgrade script for 5.x - Known solutions for errors and warnings
Question - Is it possible to install 5.0.4 THEN migrate and upgrade the data into 5.0.4 from 4.2.x?
You technically could install 5.0.4 on a different environment, then move the data from your 4.2.x server to the new one. This could be done via an export from your 4.2 server and import into your 5.0.4 server, but this would most likely take more time than doing the background upgrade, AND you could lose data. There are issues that you would need to consider if you chose this method, and it is not the recommended method.
You could also do a DB dump and then upload that into the new 5.2 DB, but again, there are many issues with this and it has not been tested, so again it is not recommended. Also, this could take longer than doing the standard upgrade, as conversions would then have to happen when the data is being imported.
The recommended method is the tested method of running the background upgrader, and then doing the installation of 5.0 product, as is described in the Installation Guide.
Also, you would need to run the migrate script to convert the job and workflow name templates in 4.2 before doing the export, if you want to avoid using the UUID in your job names, etc.