Do not use a 3.1 BFC to install or manage a 3.5 grid although there is no official documents against this, Applogic support have had several cases where this has given problems. There are important files which do not exist in the 3.1 version of the BFC which are required for the 3.5 version of AppLogic.
When first BFC upgrade failed for some reason, the install scripts will create a hidden file (.upgrading) in the target installation directory (/opt/bfc), if user run a second upgrade attempt, this file will prevent to the second run. Make sure remove or rename the hidden file /opt/bfc/.upgrading, before perform the second attempt otherwise it won’t proceed..
Make sure you have a full replica of the database before you attempt the BFC upgrade in case if it fails, the rollback procedure usually requires restoring from the replica database.
Make sure that the upgrade is done at a point in time when the BFC is not critical for operation in case it needs to be reinstalled or restored back.
Changing the IP address and/or host name of the BFC server breaks things. BFC uses LDAP and a few other services that break when you change the hostname or IP address - and not necessarily right away. So far, this appears to be the top reason in BFC upgrade failures.
Don't forget the database master passphrase. When BFC installs, it asks for a master passphrase; it then uses it to encrypt the database. you need the database master passphrase to recover BFC from a failed server or from the database replica - and if you don't know it, you can't recover. Please remember the passphrase. There is no way to recover the database and BFC without it.
The BFC replica database can be used to recover only with the same version of BFC. A few times people have tried to recover the BFC using a replica database taken with an older version - that does not work. If your BFC server dies, you must restore it to the same version of BFC you had - and then you can upgrade.
