Skip to Content

1. Why Migration in BPC

Migration is an on-going process in any product to make use of the benefits the latest version brings in. This helps in improving business with the advancement of technology in the market.

The BPC migration though involves effort and money it brings in lot of values with the new product. The Key benefits that brings in Migration of BPC 7.5 NW to BPC 10 NW to Business and to consultants are listed below,

1.1. Benefits of Migration

Migration of BPC from 7.5 to 10 brings in lots of value add to both Business and Consultants working in BPC. The key benefits it brings for them are listed below,

1.1.1. To Business

  • System becomes more secured with security from BI and BPC resulting in low threat on system or data failure.
  • Users have the benefits of HANA specific Performance Optimization in BPC 10 NW(SP06 and after) which will not available in BPC 7.53 NW even if it supports HANA DB.
  • Removal of .Net server from system architecture helps in reducing the cost and system maintenance effort.
  • Increased performance as the communication is made direct between the ABAP Layer and User Interface Layer.
  • Single interface to access all the EPM suite of products which includes, BPC, PCM, SSM, FC, etc and it is more robust.
  • With HANA it provides option to do planning at very granular level and report on huge volume of data without having any impact on performance.
  • Consolidation Central is a One Stop to find all Consolidation related activities in the system, which enables business to analyze the system and act accordingly.
  • Dynamic Reporting on data available from different systems in a single layout.
  • Enhanced hierarchy maintenance which enables the process of hierarchy update and reporting on it very quick and easy.
  • Easy interactive web reporting providing standalone usage.
  • The business needed functionalities and general admin tasks regrouped under more descriptive headers.
  • Error and warnings are more descriptive and displayed within the screen.
  • Administration and dimension management much easier while comparison with earlier versions.

1.1.2. To Consultants

  • Reporting on data available in BW and other EPM systems has become straight forward.
  • The Logic Script has been redesigned and provides predictive assistance for creation of scripts.
  • The maintenance of the dimension formulas are in a single screen and predictive.
  • The feature of Delta loading is accomplished in the BPC 10, no additional background developments needed for delta loading.
  • Error Messages in Log and during Script validation are more descriptive and relevant.
  • User/team can be assigned multiple task profiles, giving better option for configuring security.
  • Each profile created generates a role in SAP BI system.
  • Granular transports with selective object collection is possible
  • Option for retaining technical name is possible for any BPC Cubes which in-turn can enhance the option for loading data into it and to leverage other BW functionalities in BPC Cubes.
  • Environment parameters are maintained in SAP IMG this ensures that it is in complete control of only administrators of the system.
  • Design for reports and forms made easier with more usable options and selections while creation of reports.
  • Incremental concept of consolidation processes is available as a built-in option and can be leveraged easily.
  • Task Profiles are more descriptive and helps understand its function just by its name.

2. Technical Design

2.1. Prerequisites for Server Installation

Hardware Requirement:

As required for an ABAP application server to run on the Netweaver platform in the client landscape

Software Requirement:

Below are the set of software’s required in the server to have BPC 10 installed,

  • SAP Netweaver
    • Requires at least NW 7.30 SP 02 or above
    • Requires NW 7.30 SP 06 for BPC SP06 or above
    • Requires NW 7.31 for BPC SP07 and above
  • Application Server ABAP – PI_BASIS 7.3
  • Application Server ABAP – SAP ABA 7.3
  • Application Server ABAP – SAP BASIS 7.3
  • Application Server ABAP – SAP BW 7.3
  • SAP NetWeaver Add-in POASBC ABAP component – version POA_SBC_100_730
    • Kernel (64 Bit) and Unicode only
    • Any of the below set of Operating systems

                      Pic1.jpg

Pic2.jpg

Pic3.jpg

  • Any of the below set of Database

  Pic4.jpg

2.2. Prerequisites for Client Installation

Set of software that is required to access BPC 10 using EPM and Web client are listed below,

  • Operating System
    • Windows XP SP3(32-bit)
    • Windows Vista (32-bit & 64-bit)
    • Windows 7 (32-bit & 64-bit)
    • Windows server 2003,2008 and 2008 R2 terminal services, 32 or 64-bit editions
    • .NET Framework 3.5 SP1 or 4.0 as of EPM Add-In SP07
    • MS Office
    • 2003 SP 07 and later
    • 2007
    • 2010 – 32 bit only
    • Web Service Enhancement 3.0
    • MS XML Parser 6.0 SP1
    • Browsers
    • IE 7.0 – 32 bit only
    • IE 8.0 – 32 bit only
    • IE 9.0 for BPC 10 SP06 and later releases – 32 bit only
    • Firefox 8.0 for BPC 10 SP07 and later releases
    • Adobe Flash Player 10.3 for SP04 and later releases
    • Adobe Flash Player 11.0 for SP06 and later releases

Note:

2.3. SAP recommended Software Infrastructure

Server Software

SAP NW 7.3 SP02

Client Software

  • OS – Windows 7 32 bit
  • MS Office 2007
  • Browser IE 8.0

3. Migration Approach

3.1. Approach #1

This approach is a straight forward approach which involves minimal hardware requirement, where the migration is done on the existing BPC system directly.

The below figure explains the process involved in migrating the entire landscape using this approach.

  Approach1.jpg

3.1.1. Situation

This approach is good when the existing environment is shared with other SAP applicationslike BW etc. and when the refresh of the system is simple.

3.1.2. Steps

It includes the following steps,

  • Synchronize All systems
    • Clean up Sandbox, Development and Quality removing all objects which will not be moved to Production and not really required.
    • Refresh Sandbox, Development and Quality systems from Production
  • Upgrade the existing BW system to 7.3
  • Upgrade BPC component from 7.5 to 10.
  • Configure the required ABAP and Web services settings
  • Create BPC 10 users in the BW 7.3 system
  • Prepare the document with list of BPC 7.5 user ID’s mapping to corresponding BPC 10 user ID’s.
  • Execute the Migration Program for BPC object migration

Perform required testing and tunings to stabilize the system.

3.1.3. Advantage

The advantages of following this approach are,

  • Low hardware and maintenance cost
  • Other SAP applications need not be handled as a part of BPC migration as they remain in the same system.

3.1.4. Risk

Following are the risks involved when following this approach,

  1. 1. Considering the production system being used directly for upgrade, system will be down and will not be available for users till upgrade is complete.
  2. 2. If professionals involved in this approach of migration are not experienced it has high risk of losing the objects available in the system.

3.2. Approach #2

This approach is a safe approach which involves more hardware without any preparations before the start of migration process, as the existing system remains safe till the installation is done in the new system.

Below figure explains the process involved when migrating the system landscape using this approach.

  Approach2.jpg

3.2.1. Situation

This approach is advisable in any scenario where the BW system is specific for BPC only and there is no downtime accepted for the BPC system. 

3.2.2. Steps

It includes the following steps,

  • Install BW 7.3 in new system
  • BPC component for 10 in BW 7.3 system
  • Configure the required ABAP and Web services settings
  • Copy all BW objects from old system to new.
  • Backup BPC 7.5 Appset from existing BPC system
  • Restore the Appset in BPC 10 system
  • Create BPC 10 users in the BW 7.3 system
  • Prepare the document with list of BPC 7.5 user ID’s mapping to corresponding BPC 10 user ID’s.
  • Execute the Migration Program for BPC object migration
  • Perform required testing and tunings to stabilize the system
  • Remove the old system from company system landscape.

3.2.3. Advantage

Following are the advantages when this approach is followed during migration,

  • Considering this approach done in a different machine, the users can use the old system till the migration is complete
  • Downtime of the system is very low and it’s much secured option as the existing system remains untouched.

3.2.4. Risk

Following are the risks involved when following this approach,

  • Cost of hardware will be double
  • Migrating existing BW objects in a well-established BW landscape to the new system involves lot of effort in migration and testing to ensure the stability of the system.

3.3. Approach #3

This approach involves effective usage of the hardware available with a secured data migration. This is hybrid approach leveraging the best of both Approach #1 and Approach #2.

The overall process in migrating the entire system landscape in this approach is detailed in the below diagram,

Approach3.jpg

3.3.1. Situation

This approach is advisable in any scenario where BPC and BW lies on the same system and require a safe and cost effective method for migration.

3.3.2. Steps

The steps involved in performing migration with this approach involves are the following:

  • Refresh Sandbox system with Production system for BW and BPC
  • Upgrade Sandbox system to BW 7.3 and BPC 10 and rename it to be the new Development system
  • Migrate the BW and BPC objects
  • Install BW 7.3 and BPC 10 in a new system, define it as new Quality system
  • Transport BW and BPC objects from new Development system to this system
  • Migrate existing P system to BW 7.3 and BPC 10
  • Migrate the Objects in the upgraded P system
  • Upgrade the old Development system to BW 7.3 and BPC 10 and define it as Sandbox
  • Migrate the objects in Sandbox as required.

3.3.3. Advantage

Following are the advantages when this approach is followed during migration,

  • System landscape remains untouched until the Production system upgrade is started so any transport or development required can go parallel along with migration. (These developed Objects has to be handled independently for migration after this process)
  • Cost remains low as it doesn’t involve more hardware system.
  • Quality system involves data being transported from Development, resulting in very minimal migration effort in Quality.

3.3.4. Risk

Following are the risks involved when following this approach,

  • Production System will be down during its migration.
  • This approach of Migration involves both Installation and Upgrade in different system resulting in inconsistency of process and it might lead to some potential risk which is specific in some system only.

4. Score Card

Approach #1

Approach #2

Approach #3

Business Impact/Down Time

Low

Medium

Medium

Hardware Cost

High

Low

Medium

Maintenance Cost

Medium

Low

Medium

Migration Approach in D, Q and P

Consistent

Consistent

InConsistent

Potential Risk

Low

High

Medium

BW Migration Impact

High

Low

Medium

5. Features Comparison

Feature

BPC 7.x

BPC 10

Admin Client

Thick Client

Thin Web based Client

Security

Windows domain Users are used

SAP BI users are used

Script Logic

Users have to remember the properties, member names and Script Key words etc for writing the logic.

Option to browse dimension member details and Script Logic Keywords are available

Member Formulas

Formulas are maintained in each Dimension

Formulas are maintained in a common place, enabling easy tracking of member formulas in the system.

Business Rules

Validation Business Rule helps in validating the data for consolidation process.

Validation Rule is available as Controls which is tightly integrated with the consolidation framework of the system

Work Status

Only Entity dimension can be used as Owner dimension

Entity and Account dimension can be used as Owner dimension

Only relevant workstates are displayed to the users

Dimension Management

Excel should be available in the machine to update Dimensions

Flex Based tool with look and feel of Excel and doesn’t require Excel for updating a dimension.

Tool tip to show the status/errors

Any updated members are highlighted – helps easy maintenance

Process & Activities Monitor

Not Available

Gives the screen listing the set of process available for the user to perform

Consolidation Central

Not Available

One Stop for monitoring all consolidation related activities

Reporting

Report can be built only on BPC Data

Report can be built on BPC, BI and other remote BI systems connected to the source BI system

Macros

Macros are simple and standard

Object based methods are available which can be executed only with proper declaration

Data Manager

Data Load from BI is always full Load

Currency Conversion is always in full mode

Data load can be Full Load or Delta Load

Currency Conversion can be done in incremental or full mode

Journals

No Standard approach for defining logic specific for data entry from Journals

Standard logic file(JOURNAL.LGF) available to define logic for data from Journal entries

Books

Not Available

Reports can be published as Books

Ownership Manager

It was named as Dynamic Hierarchy Editor, not an easy interface for the users to use.

Standard layout helping out easy update of Ownership details

SQE

Use MDX functions to calculate Periodic, YTD and QTD

Use Bex Query to calculate Periodic, YTD and QTD with better performance

Write Back

Calculations can be done parallel and write Back is not

XDIM_PACKAGEBY keyword helps in calculation and writing back parallel to the system

Transport

It transports the entire Application and not very granular

It can transport granular objects like can specify which script logic file can be transported.

6. Objects Migrated

Following are the list of Objects which are migrated automatically few of which needs manual effort in updating it post migration,

  • All Transaction and Master Data are Migrated including the Comments in the source system.
  • All Admin settings are Migrated
  • Domain users and its relevant SAP users are mapped based on the Mapping in the Excel file used during migration
  • Journals, Business Rules, BPF’s, Validations, Data Manager Packages(Not the Logs) are Migrated completely
  • Security, Validations, Content Library, BPC Templates are migrated with some Limitations which needs to be tested and corrected manually
  • Xcelcius, Live Reports, Custom menus are not Migrated

7. Key Considerations

Though Migration of BPC objects from 7.5 to BPC 10 is facilitated by the standard program there are various other factors that impact the smooth migration from BPC 7.5 to BPC 10.

The Impacts or key considerations for migrating different BPC objects from 7.5 to 10 are listed below under various headers.

7.1. Master Data

  • Dimension Properties- migrated only if same property name is not repeated in different dimension.(If same name used in multiple dimensions, only one will be migrated & rest needs to be processed manually)
  • Sequence of the members
  • Formula to be moved manually
  • User info maintained in properties other than OWNER/REVIWER property
  • Members with space, dot and other special character are not supported during migration – replace the members with “_” before migration if migration is done including master data.

7.2. EVDRE Template Migration

EVDRE templates in BPC 7.5 are not migrated as a part of migration program executed in converting the objects from BPC 7.5 to BPC 10 format. There is a different EVDRE migration tool available which converts the template in BPC 10 compatible format.

This tool converts the EV functions in the template with its corresponding EPM functions. This also adjusts various other EVDRE ranges and parameters in line with BPC 10 reports.

This EVDRE migration tool works only when the BPC 7.5 reports adheres to the following list of basic conditions,

  • EVDRE should have 2 or 3 parameters which can only be a cell range or value without any formula.
  • All the Ranges and EVDRE should be in the same sheet for the Migration tool to work
  • Page Key Range should be available above the row and column key ranges
  • Column Key Range Should not be below Row key Range
  • When 2 EVDRE sharing a common row or column axis, only the overridden report will be migrated
  • Template with Expansion across sheets cannot be migrated

The report’s which falls under any of the above condition has to be migrated manually and tested.

Even when the BPC 7.5 report adheres to the above there are many other constraints which need to be considered to ensure the migrated report works in the same fashion as it was working before. For a complex EVDRE report which involves various formulas and conditions will require additional manual effort to fine tune and test manually after the report is migrated with the EVDRE migration tool.

Below are few set of considerations which has to be considered after migrating the report using the migration tool,

  • Reports with pipes, static reports (either of the expansions locked) will have issues in migration.
  • Reports with scaling using EVDRE, Scaling part will not be migrated, not sure about scaling using excel macros. Reports/IS with locked CV’s are also not migrated properly.
  • Formatting of Reports is not migrated when none of the rows are recognized, even when its recognized its doesn’t behave exactly as before due to non-support of few keywords that were supported before.
  • Override members in Report to be updated in the standard templates as per change in sequence of dimensions of the application in BPC 10 system
  • EV function and Macros referring to the members in Pagekey and Override member range to be maintained
  • MNU Commands will not work and it has to be replaced manually with its corresponding API’s
  • Certain EV functions which are not supported has to be redesigned to leverage what is available in BPC to perform their action. like EVHOT are not supported their actions should be redesigned with quick links.

Manual Changes required on few parameters which are supported in BPC 7.5 and are replaced with different other functions like, Suppress has to be replaced with Remove Empty option for the Report

7.3. Business rules & Script logic

  • Business rules & script logic- both will be migrated but needs few manual update and unit testing
    • Account Transformation – Update UJP_CALC_ACCH and UJP_CALC_ACCHT table field values
    • Elimination – Update UJP_ELIMHT field values
    • Currency Conversion – Update UJP_FXTRANSH and UJP_FXTRANSHT tables
    • Booking – Update UJP_ICBOOKH and UJP_ICBOOKHT tables
    • Method – Update UJP_MEHTODH and UJP_METHODHT tables
    • Rule – Update UJP_RULEHT table
    • Validation – Controls migrated, Control Set and Control Assignment to be defined manually(as per SAP note 1619983) and end to end testing to be done
  • BADI Code –
    • Needs to be migrated manually if migration done in a different system as this is not restored in UJBR
    • Needs to be modified because of Dimension IDs (No of Characters for Dimension Ids increased from 20 to 32). Also for Custom Logic Badi there are 2 additional methods in place which need to be activated.

7.4. Loading data

  • Transformation & Conversion files migrated but needs unit testing
  • All the standard BPC Process Chains in BI needs to activated before using the datamanager packages which are migrated.

7.5. Security

  • Creation of Users in BI
  • Create CSV file with mapping of AD users with BI users.
  • Extensive testing needs to be done for BI User roles assignment as it overrides BPC front end security descriptions.

7.6. Business Process Flow

  • Archived Instances will not be Migrated – Should be Closed before staring the migration
  • Template Layout with steps and Sub Steps will be changed
  • Few activities will not be migrated – Example – Journal – Repost, Unpost , Manage Dynamic Hierarchy,  Offline distribution wizard etc. (Check SAP note 1620503)
  • Detailed testing and updating the process for the steps which are not migrated is required

7.7. Journal

Journal entries are all migrated, except for few value update in the table UJJ_JRNL

7.8. Xcelcius Dashboard

They are not migrated and requires the following manual steps to be done for migrating it to BPC 10 system.

  • Open the old .xlf files in Dashboard designer
  • Remove the old EPM connection
  • Recreate the connection with new EPM connector and set the required parameters.

7.9. Other Objects

Other objects which are listed below are migrated completely and requires just unit testing to ensure they all are correct.

  • Work Status
  • Data and Comments
  • Web and Admin Parameters
  • Content Library – Documents and URLs

The Objects listed below are not migrated automatically. It requires manual updates for it to work,

  • Live Reports
  • Content Library – Web Pages
  • Custom Menus
  • Xcelcius Dashboard

8. Post Migration Checks

Once the Migration Program execution is complete the log of what happened during the execution of this program can be traced using the following approach,

  • Log in SLG1 for Objects with UJ
  • Using a ABAP program UJA_DATA_CHECKER in SE38
  • Logs are available in the Excel Client for templates migrated using EVDRE Migration tool

9. Migration Recommendation

Below are few recommendations which can improve the migration process and ensure a smooth transition,

  • Make sure all the systems(Dev, QA, Prod) in the landscape are in sync.
  • Make sure all the systems are clean with required objects only.
  • Take Backup of all the Appset and ensure it is available as a disaster recovery option.
  • Freeze all the system for any changes or development before start of migration

10. References

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Chris Bennett

    This is a great document that highlights issues with migration, but to date I have not found any material on working around the issues.

    I have issues with reporting and have found no way to overcome them in the native v10 report writing.

    One particular strength of EVDRE reporting seems to be completely overlooked – piping together different sections in a dimension expansion.  Joining separate reports in v10 results in a far far slower report experience which is frankly unacceptable in the latest incarnation of this great software.  This slowness is noted in the documentation for the product – is it being worked on or is another solution in progress or, dare I say it, is the recommendation to stay with EVDRE?  For new users this may be a bit of a challenge.

    (0) 

Leave a Reply