Top Tips for Planning a BI 4.x Migration
SAP BI 4.x Migration Governance & Preparation
Many organizations fail to take into account for BI Governance. Sadly, many organizations’ BI deployments are IT-centric, with little to no input or control for the business unit. It is important to establish a governance council to properly direct and motivate the desired outcome of the program. There must be clearly defined business objectives that are translated into program directives, scope and quality. Furthermore, proper control processes are established to ensure the progresses per the plan with key decisions being made consistent with the objectives.
Planning and Preparation:
Upgrade, Update, or Migration?
Planning your move to BI 4.1 begins with assessing where you are today. What version, etc. The answer to this will determine your path early on. For example, running SAP BusinessObjects 3.1 or earlier, you will need to perform a full-on migration. This being said, you will need to stand up new server (or cluster), install the latest version, then migrate content. This is known as a Migration. The key factor here is a complete shift from 32-bit to 64-bit architecture.
Alternatively, if you are moving from BI 4.0 to 4.1, you can do a simple in-place upgrade. This means you can apply the update files directly to your current installation, instead of doing a new “side-by-side” install.
Similarly, if you are already on BI 4.1 and simply need to update, then you simply apply the Support Pack (or patch) files.
Sizing: What Resources Do I Need?
One of the most commonly overlooked aspects is sizing. Basically, do you have enough CPU, memory, and storage? SAP provides a sizing tool for determining BI 4.x CPU and memory requirements. However, this is typically a guesstimate. When doing migrations, I typically use this as a sanity-check for my own process.
What is this process? Basically, analyze your current environment’s utilization and forecast what’s needed for 4.1. In a nutshell, generate a SAPS rating, memory usage history, and storage usage history for your current environment. From here, you can assess what is needed for your upgrade. You will need to analyze your current usage, and forecast growth, new applications requirements, etc. This will vary, based on current utilization. For example, if your current utilization is consistently under 75% for any resource, I’ll forecast 25% over your current SAPS rating. Any higher, I forecast 35-50%, for the same amount of users. If increasing users, increase SAPS accordingly. A partner, such as ATCG Solutions can help you with this.
A note about SAPS: SAPS is a hardware-independent unit of measurement that describes the performance of a system configuration in the SAP environment
Next comes planning. This includes everything from number of servers, operating systems, storage, licensing, networks, etc. The list goes on.
The best approach is to start with your server topology (i.e. how many and what kind). As a baseline rule for mid to large-size deployments, I start with two BOBJ servers and two web application servers. Basically, a cluster of two CMS servers w/ all services, except the web tier. I prefer to isolate the web application tier into a cluster of two. With the proper configuration, this should support up to 750-1000 concurrent web users. However, this is a baseline configuration, or starting point. For smaller deployments, it’s still a best practice to deploy a failover cluster.
Migration Plan of Attack
Put together a plan: Before you get started, you will need to answer a few questions:
- What resources are needed? Keep in mind hardware resources, software, IT personnel, security, and your user base.
- What timeframe do we have to complete the migration? Shorter timeframes will require more personnel to work in tandem.
- What content is supported? Certain content, such as Desktop Intelligence has been retired. Certainly you can migrate your deski content, but it will not be supported with the newer features of BI 4.x. It is best to convert to Webi, pre-migration.
Do A Mockup: It is a good idea to get a picture of what the process will look like:
- What does the upgrade path look like? If you are on a legacy version of BusinessObjects, you may have to migrate to 3.1 before moving to 4.1.
- What content are we migrating? As indicated above, some content will not migrate, some will need extra validation, and some will just need to be validated for functionality.
- Full vs Staged Migration? For all but the smallest migrations, this will be Staged. The difference is that a full migration moves everything in one fell swoop. Staged breaks it into pieces.
- How is it staged? i.e. how are the stages’ content broken up? This is usually done by business units, and or subunits.
- What does the security model look like? This is of the utmost importance. Security is migrated first, and content falls into place after that. This is a good time to assess your security model and plan where you want to be in the future. Document authentication, user groups, folder structure & security, and any custom access levels.
Final Prep: A few things to wrap up before execution:
- What testing is done? We typically start with 10% of total migrated content to be tested. This can then be adjusted, due to budget and/or time constraints.
- How do you fix errors? Put together a process for addressing errors, because they will come up.
- How long will testing take? This correlates directly with the percentage of the overall content to be tested. Figure 2 hours on average for break/fix per report. Dashboards will be more complex.
Execute: We have liftoff!
Although this is only scratching the surface, these questions can get you on the right track. Proper planning and implementation is key to a successful migration- big or small.
Find out more?