BI upgrade: in place versus new deployment

[franciscoalmeida]

Back in 2013, while Organizations were still making the transition from previous version to BI 4.0, many Engineers must have gotten "creative" with upgrade practices, given the article written by Matthew Shaw about such practices (here). In the article, he admonishes against upgrade methods that simply ignored potential changes to the CMS database, and in the end concluded that the best practice is an in-place upgrade.

Although we do agree that an in-place upgrade is a very good approach, and is definitely superior to the "creative" methods he described in his article, we also think that there are advantages with the alternative supported method, namely, the new deployment approach, where a new BI system is built from scratch, and the content migrated from the current system via supported interfaces (Promotion Management in the case of 4.x to 4.x+)

One disadvantage of an in-place upgrade is that it forces the Organization into a development freeze from the moment you upgrade your first environment, which is probably Development. At that point in time, one can no longer promote their development content to production due to version differences. Even if you upgraded another environment first (say, Test), one of the points in the development life cycle would be affected by version difference. To minimize this impact, one could upgrade Test first, and would be forced to run tests in another environment (likely development), and this would in any case always impact in that life cycle, just in a different way (in this case, no new development can start until testing is complete).

This fact alone show that an in-place approach is more suitable for smaller deployments, which can quickly adapt to disturbances in their development life cycle processes and tolerate this type of development freeze.

Larger deployments, with multiple servers and dedicated BI Developers, a Test Team, etc., could find that impact unnacceptable.

In-place upgrades also bring with them a considerably higher risk factor: if things go wrong with the upgrade (anyone, anyone?) there is no fall back system. If ugprade issues happen in the development environment, here again smaller Organizations can adapt and run their development in the Test system or some other form of temporary improvisation. However, what if a particular problematic issue is only detected in the production system?

Below are some examples of issues detected during upgrades:

• CMC and BI Launchpad are down and inaccessible after applying a recommended patch


• WebI development on BW is so slow (5 minutes to show connection content) that one cannot develop anymore


• Scheduled jobs fail to run


• Lumira client cannot write to the repository

All these errors came from BI 4.2 upgrades, and there are no workarounds for some of them. What then? Would the Organization be happy to take on the risk of having the system down for several days until they are fixed, all the while you enlarge the development freeze? What if these issues happen in production?

Surely, I hear you think, I can simply uninstall (Windows) the deployment, and be back to the status quo ante, right? The answer is: sometimes. There are certain issues during the upgrade that may not be fixed by rolling back the installation (uninstall). Uninstalling did not resolve the problem. Even when possible, downgrading recent versions of BI require a change to licence keys that complicate the process somewhat.

Now you must be thinking "backups would work". Backups would certainly work, as long as they are done properly. Many Organizations backup their BI servers and ignore their CMS databases, relying on RDBMS backup schedules. This forces the return point objective (RPO) to the oldest of the two (server files or database) and if the difference between those is considerable, there will be some inconsistencies in the CMS which will have to be addressed by the Repository Diagnostic Tool. At this point, all the simplicity expected from an in-place upgrade is replaced with increased complexity.

A new deployment could have the exact same errors mentioned above, but the difference is that they would have no impact in the existing Business processes because the current version is still working. Change and development freeze will only start when the migration process starts, and even then, a second migration wave can capture objects created during the development freeze if required.

As the risk of disturbing Users is eliminated, rather than fire-fighting, the Project Team can focus on building the new environments and resolving the issues to deliver a high quality deployment for the time when the switch to the new version will occur. Disturbances to Developers, Testers, Business Users and Analysts will be minimal to none.

This approach has the advantage of allowing for security design changes that do not impact current users

Surely an in-place upgrade is convenient and easier, because you don’t have to worry about database drivers, and the installation takes less time. However there are several downsides, and also a higher risk to factor in, which is all but eliminated in the “new deployment” approach.

In conclusion, it is clear that the decision is not of the "one size fits all" type, and BI Managers and Administrators should take into account these factors because they are not very obvious and are easily missed when planning for an upgrade. In short, consider a new build if you are looking for the following advantages:

1. a. Shorter development freeze


2. b. A fall back system readily available in case the upgrade goes wrong


3. c. Remediation of production do not cause or extend outage


4. d. Security can be re-designed and tested with no impact


5. e. Lower overall risk