This article is an example on how a migration from SAP BusinessObjects XI 3.x to SAP BusinessObjects BI 4.x has been handled.
It sets up within SAP IT, as such, a SAP Internal project, from where a complete migration procedure has been executed from August 2012 to March 2013. This article will describe the different steps done and explain the different choices made, as well as highlight some hardships encountered during the migration.

Preparation before upgrade

1.   Inventory

First thing to look after when we wanted to migrate our XI3 content to BI4, was to do a clean inventory of what we wanted to migrate. Either in term of content amount –to serve in sizing matter-, or even in term of tools used in the XI3 landscape.
We also wanted to do some kind of cleaning before the migration: all content owners have been asked to clean unwanted or unused files to decrease the amount of data to be moved over the BI4 platform, restraining useless content to persist. To help them, we had audit reports (if requested) which summarize the global utilization of their solution. Other than that, the Solution Owners had to synchronize with their end-users to make sure that the content are relevant.

We have also informed the content owners, that the personal files, e.g Personal folders or Inbox, won't be migrated, only reports under the general Public Folders will.

We have also distributed and made available internally a document summarizung all the migration information and a small guide in regards of migration path so that each Solution Owners can refer to and also understand a bit better the context and steps of this project.

In term of tools, we had the complete set of BusinessObjects suite, as followed:

• Web Intelligence
• Crystal Report 2008
• Explorer
• Xcelsius
• LiveOffice
• BI Mobile

In term of connectivity, which is also important to list because of BI4 tool compatibility change, we had the following types:

• ODBC (IBM DB2, MS SQL, …);
• Flat DSN (Attunity);
• SAP BW.

As for the content, we have moved over 22 solutions pided in 9 LOBs, for an approximatedamount of 800 objects (documents, universes, connections).
As a side note and information, we had on our XI3 productive system over 3500 distinct users connecting a month for 80000 registered.

2.   Tool Migration Path analysis

As specified in the “How to Upgrade to BI4.0” article, some changes have been made in BI4.0. As such, if you plan later (after moving all your content as a 1-1 migration as suggested) to switch to those new features in replacement of the old ones, you will need have an eye on which tool you’re going to use in the future and what conversion path makes sense for your end-users.
For instance, if you used Crystal Report 2008 on top of a SAP BW backend (hence MDX Connection), you will either have the choice to stick with Crystal Report 2011 (keeping MDX) or to leverage the new Crystal Report Enterprise that use the new BICS Connectivity. Another example would be the simple question of converting to UNX format universe or keeping UNV format along? Or use both? But the latter would be a pain to maintain.

In our project, we have decided to prefer the new technology when it was feasible (e.g. UNX over UNV) and highly recommended the usage of new tools.
We have decided to not support UNV as most as possible, or at least, not having a mix of both format within a same solution to be able to easily maintain/support any issue coming up in the future.
Below is a sum up of what has been instructed/recommended to our platform Power-user and developer.

3.   Upgrade Management Tool

As explained in the “How to Upgrade to BI4.0”, Upgrade Management Tool is the premium tool to migrate all your content from one platform to another. This is as such the main tool used during the “technical migration” (moving content phase) paired with Import Wizard Tool (BO XI3 platform) to make BIAR files.

Upgrade Management Tool can run several scenario and mode. And we, as hinted above, decided to go with BIAR files, instead of a direct “Live-to-Live” scenario for the following aspects:

• It’s safer (no risk to break one or the other system during transfer);
• BIAR files can be used as backup files just in case (life savior, I can guarantee that);
• No downtime required on any platform during the move (this is crucial if your end-users are still using the platforms during the migration period, especially if you have a big amount of data to move out and as such would require several downtimes in the Live-to-Live scenario);
• Higher control on what’s being moved;
• Faster troubleshooting in case files are corrupted as only what’s has been selected in the BIAR would be impacted.

We have also decided to split the migration by solutions. As such, we did an incremental migration instead of a complete upgrade:

• Each solution has its own pace and LOBs, thus, the time allocated or availability for migration can differ from one solution to another;
• More granularity over the migration;
• Distinct Backup for each singular solution at the migration time;
• No impact on solutions not yet ready to migrate.

BI 4 setup

This part will cover information regarding the system itself. This can be referred as the Step 2 of the « How to upgrade to BI4.0 » article.

1.   Landscape description

In SAP, we have a full landscape dedicated to BO XI3 operations. By full landscape, we mean that we cover the following setup:

Development > Test > Quality > Production

As understandable, we wanted to move this entire setup to the BO BI4 version. However, even if possible, we didn’t run a side-by-side installation. For two reasons:

1. It’s not recommended;
2. We already had a full landscape dedicated to BI4 operations (so we were already maintaining two landscapes for it not to be a drawback for the UMT scenario choice).

As such, all installations, security framework, sizing, performance tweaks has been done prior and adjusted for the migration.
Please be alert of your FRS disc space consumption. This is the most critical metric to monitor during the technical migration phase (content move).

2.   Landscape preparation

Knowing that we have this separate installation of BI4 running, we had the choice between either migrate all content from XI3 as a parallel migration or, in a more linear way.

The purpose of a “parallel” migration would be to have a complete mirror of what is in your XI3 platform to the BI4 platform, like a save state. However, this would also mean 2 things:

1. To have the same number N of systems in the two landscapes;
2. To execute N-time the content migration for the N number of system composing the landscape, this can create tremendous workload.

In regards of the amount of content we had to migrate and to be in line with our desire of cleanup and control over the migration, we have opted for the Linear Migration. This allowing us the following:

• Choose the Source system (either development if it has the most up to date version of a solution or productive version; or even a mix of both: first productive version then followed by an incremental migration of some documents from development system);
• Less BIAR to be generated;
• Only one Destination system (BI4 Development system);
• Manual adjustments (the recommended tool update changes as identified in chapter 1.b - see also chapter 3.b) to be applied on only one system instead of the 4 (especially when we do not allow any direct modification on Production), so no task redundancy.
• Complete Change Management process can be reapplied on top of this migration: control anew what’s going/allowed to productive system.

It would also benefits upon Ad-hoc reports that have been created on the XI3 platform productive system -as they were integrated in the migration as long as they were located in the Public Folders-:

• Platform teams can control back the quality and performance of those reports that were created directly by the business;
• Integrate those ad-hoc reports to the "standard" folder of the solution: in our BI4 landscapes, we have introduced two folders within each solution. A first folder called "Standard" where are stored the reports developed from Dev system and considered as the "standard" of the solution hence where platform team ensure Support (read access only, no edit rights). And a second folder called "Business" where Power users are able to create, edit, delete ad-hoc reports on Productive system for their own needs.

Migration phase

This chapter will explain how we have split and handled our migration process. For a better understanding to our power and end users, we have made split the migration into 3 steps having each its own purpose and its own actors.

Here is a schema of those steps:

1.   Technical Migration

The technical migration phase is the step where the contents are being actually moved from the XI3 system (development or production) to the BI4 Development system.
However, it does not only contain this major step but also intervenes at first the Solution area creation: creating the new solution’s folder aligned with the new security framework, creating the DSN/ODBC connections, the BO connections, user group mapping, user assignments, etc.
Each migrated solution has been treated as a new oncoming solution: this was the most effective way to ensure the alignment with the new security, folder architecture and also the new naming convention of our BI4 landscape. The only difference with a “real” new solution is that the content will be moved over from XI3 in our case.
When the solution area has been successfully created, we used Upgrade Management Tool to bring over the needed content using the strategy explained in the previous chapter. Was left the connection change to Development backend (if the content came from the XI3 Productive system, then we need to change the target backend source from productive to development as the content are moved to BI4 Development system).
Prior to the content move, we have made sure to have from the Solution owner the source system, the migration date approval (that we have discussed internally beforehand to align with the migration timeframe) and of course, approval of migration so that every party are aligned.

The main actor of the Technical Migration phase was the Platform management team: BOE Administrator and Support Team.

2.   Manual Adjustments

The manual adjustment phase comes right after the Technical Migration and on top of the Development system. As already stated in a previous chapter, this step is the one reserved for the solution to adjust to the new BI4 recommendations (e.g. convert to UNX universe). It's strongly recommended to proceed with this step only after completing your 1-1 migration, basically, just pushing everything back to Production as it was on XI3 as soon as possible, and then modify reports to use new features from Development system. Like this, you will ensure a small and smooth migration period.

In our case, thanks to the experience already aquired from BI 4 validation programs and ramp-up as well as access to SAP experts, we took the controlled risk to do both in the same project. But again, this is not the recommended practice.

This step was a great opportunity to test the new features and tools offered by BI4. As one of the first customer to move over and use the new tools, we were more likely to see product defects during this phase. Most of them have found either workarounds or have been fixed in new patches in collaboration with our Product Group.

As mentioned earlier, we tried as much to force solution owner to convert to the new tools and stick to the recommendation, however it couldn’t always be possible mainly for the following reason:

• This step involves primarily the Solution owner and the Development team. As such, for the Platform team, this step if the most hard to quantify either in workload and time needed as it greatly depends from one solution to another.
• Too many reports to convert for small bandwidth at this time;
• Conversion not always intuitive (ex: CR2011 to CRE against SAP BW);
• No big ROI.

This step involves primarily the Solution owner and the Development team. As such, for the Platform team, this step if the most hard to quantify either in workload and time needed as it greatly depends from one solution to another.

3.   Change Management Process

When the Manual adjustments phase is over, the solution owner nominates the solution to go towers production. This is part of the usual Change Management Process. As such, the solution will reach Test and Quality system, where it will be validated and approved prior reaching Production.
When a migrating solution reached production, we have cut all access of this solution on the old XI3 landscape to make sure of the adoption of the new BI4 system by the end-users and thus closing its migration.

Involved actors: System owner, Platform management team and Support team.

Additional highlights

1.   Technical perspective

2.   Management constraints

One of the pain points is to be able to leverage enough traction in every involved team for the migration. Time can also be a decisive no-go for business to get involved in a migration: QEC period for instance.
As such, it’s critical to define milestone for every solution and agreement on the migration timeline. We had tremendous reluctance from our end users to switch to the new BI4 system due to those tight time periods that exist between each QEC and also because we didn’t define firmly a target date of move that can’t be delayed.
It’s also important to remind the purpose of this migration, whether it is to leverage new tools, possibility and knowledge or simply to reduce internal cost so that everybody feels concerned regarding the migration. Communication is key.

Finally, another point to not omit is the learning: BI4 brings new front end technology, new platform services, etc. As such, it’s important for the platform team, the report developer team and the end user to get the adequate trainings to be able to profit fully of the BI4 functionalities.

Benefits & changes

The move to BI4 has bring a lot of new features as already specified in previous chapters.

It's now easier to develop on top of SAP BW, for example WebI, thanks to BICS connectivity (no more OLAP UNVs are needed), same thing in regards of Dashboards on BW. However, feature aside, in term of performance, our end-users have noticed better performance and stability. We had good feedback especially with Crystal Reports and WebI paired with UNX.

Administration side, thanks to this move, we have been able to implement the Online Backup feature, which permit us to no longer have planned downtimes on weekends for backup purpose, greatly appreciable for high availability and, of course, to enable the whole world's timezones.

The new Monitoring feature has made us more reliable thanks to the different watches we have set and the Audit enables us to provide better statistics for the Solutions' Usage.

Please also note that somes process need to be changed, especially for Change Management as Import Wizard Tool is no longer available on BI4 but "Promotion Management" or also called "Life Cycle Management (LCM)". As such, you need to rework your transport procedure around this new tool and also , of course, get familiar with it.

Conclusion

Our internal migration took 9 months to finalize. However moving the content (technical migration) was not the longest part and has been done in a two-month timeframe. What took us time were majorly the Change Management phase (step 3) and the acceptance for some solutions to move over to the BI4 landscape due to, as said in the Management constraints chapter, QEC periods and also product bug resolution.
As such, it’s really important to prepare beforehand your migration, not only regarding the technical setup but management wise too.  Once your plan is concrete and ready, migrating shouldn’t be that complicated as long as you stay vigilant regarding issues that might occur.