In-Place vs. Side by Side
Which is the best method for an SAP BusinessObjects upgrade?
The Reality of BOBJ
SAP tends to refer to upgrades as moving from minor versions such as 4.x to 4.x, rather than a migration which is more for major releases such as 3.x to 4.x. There are two ways of a 4.x to 4.x upgrade: in-place (similar steps to install a patch) or side by side (similar steps to a migration).
One important note to mention here is that those still on SAP BusinessObjects XI 3.1 will need to migrate and pass by BI 4.2 first being able to upgrade to BI 4.3.
In a recent webinar, we surveyed SAP BusinessObjects users to see which upgrade strategy they would prefer, before knowing all the information, and these were the results:
According to you, what is the best strategy to upgrade to BI 4.3?
SAP BusinessObjects In-Place Upgrade Project
In my opinion, SAP suggests this method to encourage people to upgrade frequently rather than carry out a side by side project because on paper it’s less effort. An in-place upgrade involves the following steps:
- Download all the software to be patched (server, client tools, addons, etc).
- Install everything on top of your existing server(s) and workstation(s).
- Test and repair any risen problems.
I’ll start with my one “pro” of this method — you can use the same hardware and dependencies! You will not need any involvement from the IT team other than making a backup and being on standby in case you need to roll back in the event of any serious issues.
BUT. Yes, I will always have a but for this method. Downloading and installing everything on an existing server means your server is down for a very LONG time, meaning your SAP BusinessObjects services will not be available to end-users. This will be between several hours to even a few days which is not at all very business-friendly or bring any business value.
You will also not be able to carry out complete testing and it will even be difficult to test at all other than functional testing, as you will no longer have the old environment to do a side by side comparison. Some things may even be impossible to test. This is a major downside because the longer your server is down, the longer users will have to wait for it to back up and running. With this downtime there will also most likely be reconfigurations to perform, for example upgrading Tomcat (requiring you to set up your SSL and perhaps SSO once again), as well as repair work on universes and/or reports that need fixing. Some old services and add-ons such as Lumira may also need to be updated and others may not exist in future releases, for example, Explorer will not exist in SAP BI 4.3. Again, the longer it takes to test and repair, the longer your platform will be down. Once the upgrade is completed and you are “live”, it will also be hard to rollback as it’s already up and running for users. If you do rollback, you will lose content that has been created and modified since the backup.
We can also use the example of updating an iPhone as a simple analogy of an in-place upgrade:
Updating My iPhone (same phone):
- Plug in my iPhone to have enough battery
- Access Wifi
- Do a Backup (if there’s enough space on the iCloud!)
- Install the Update (iPhone unavailable during this time)
- Restart (cross your fingers!)
- Reconfigure some things (E.g.: Vodafone)
- Tests (some apps will not support the latest iOS)
- Rollback: Difficult / Impossible
- If the new iCloud backup has been done, it can’t be restored
SAP BusinessObjects Side by Side Upgrade Project
The other option when upgrading from version 4.x to 4.x is a side by side upgrade. This goes as follows:
- Get new server(s) and dependencies such as System and Audit databases.
- Download, install and configure the software.
- Promote content from A to B.
- Carry out testing for as long as you like and repair if necessary.
- Promote content that has changed since the first promotion (step 3).
- Go live.
The other existing server(s) are still active and running whilst the new server(s) are seamlessly being deployed, installed, tested and content being repaired if required. Some users will have no idea that an upgrade is happening.
There are many advantages to this method in my eyes. Firstly, you can take as long as you want to upgrade. Given that the old environment is still available for users, you do not need to worry about time and cutting corners. Secondly, as this environment is working alongside the old one, you can also test for as long as you like, thus reducing the risk of problems arising once it goes live.
A side-by-side SAP BusinessObjects upgrade is also a good opportunity to upgrade Operating Systems and other 3rd party dependencies (e.g. database drivers, web application server such as Tomcat). You could even use this opportunity to move from on-premise to cloud hosting — all in all an ideal time to take advantage of this project and downtime to review everything.
One drawback is that it will require help from your IT team to provide you with new server(s) and required dependencies, and you may need to carry out other architecture changes as well, for example, firewall and SSO (single sign-on).
Sticking to the iPhone example, a side-by-side upgrade works the same way as replacing your iPhone with a newer version as seen below in my analogy:
My new iPhone (and to replace my old iPhone 7) :
- Buy my new iPhone 11
- Turn on my new telephone
- Initial set-up (preferences, wifi, etc)
- Restore the iCloud backup
- Test applications and new functionalities
- Take out and insert my SIM card and do last few tests
- Test (some apps will not support the latest iOS)
- Rollback: Easy. Re-use my old iPhone with the same SIM card.
In-Place vs Side by Side: Conclusion
In my opinion, an in-place upgrade is rarely the way to move forward. Based on many years of experience I would almost always advise a side-by-side upgrade given the reduced risks and the fact that you can take your time making sure all tests and repairs are carried out. Most companies are risk-averse so in the majority of cases, they will choose the latter option.
However, at the end of the day, it all depends on how mission-critical a company’s SAP BusinessObjects deployment is. If you can easily go for a potentially long time without your Production server(s) and you have fully tested against a nearly identical environment then why not choose an in-place upgrade.
Now you’ve seen the differences between the two types of upgrades, which one would you go for? At the end of the webinar that I mentioned above, a lot of people changed their minds:
Did you change your mind? According to you, what is the best strategy to upgrade to BI 4.3?
Remember that if you are on version SAP BusinessObjects XI 3.1, you will need to migrate to BI 4.2 first, then to BI 4.3. So why wait, migrate today!
Need some help and advice for your upcoming SAP BusinessObjects upgrade?