Skip to Content
Author's profile photo Former Member

Multiple SAP BW Landscape Consolidation

Multiple SAP BW Landscape Consolidation! – Perhaps, I heard it for the first time and sounded really rare and ‘not so common’ scenario. The first question that came to my mind was, why one would want to do it – bring multiple BW systems on to a single database, say for example, SAP HANA. Well, the reasons are multifold –


  1. To simplify the landscape
  2. To enable easier maintenance
  3. Comparatively less investment on hardware and software
  4. Software installations/updates, patch updates etc., is just done once
  5. Take advantage of SAP HANA (if you are consolidating on SAP HANA)

There could be more reasons, better reasons. This can typically be like consolidation of regional systems, which is normally spread across geographically into a single landscape. Technically, it’s quite complex, since, the BW Objects like the InfoObjects, DSO, Infocube, Queries etc., when brought together from multiple systems can face overlapping in naming, which has subsequent effects on its own. For example, the infocube 0SD_C03 from one BW system can have issues when 0SD_C03 Infocube from a different BW system want to be moved to the consolidated BW system, especially when both the objects have different characteristics and keyfigurs. The same way with other BW objects as well.

In simple terms, the concept is clear that the technical names of the BW objects need to be exclusive, so that they can be seamlessly consolidated to a single system. But how? Imagining the volume of the BW objects and the intricacies involved in each object, the whole project would truly be massive and humongous.

From the approach point of view, there can be two ways


  1. Superset Approach
  2. Unique Object Renaming Approach

The concept of superset approach is quite simple – Create a single object and include attributes used in all other BW systems, so that we have a single object to cover up all attributes. For example, for the master data 0MATERIAL from BW1 system has attributes attr1, attr2, and attr3. The 0MATERIAL from BW2 system has attributes attr4, attr5, and attr6.  If we were to follow the superset approach for this object, the consolidated BW system will have 0MATERIAL with attributes attr1, attr2, attr3, attr4, attr5 and attr6. Though, this is clear from the object metadata point of view, from the data point of view, it brings up complexity. How? If 0MATERIAL from two different BW systems has same values representing different materials. This basically implies two things.

  1. We can follow the superset approach provided the data is harmonized across the regional BW systems. If this data governance has been followed right, this approach will work fine.
  2. However, if data harmonization has not been taken care, it might need development effort like compounding to 0LOGSYS to the objects to differentiate the data coming from different BW systems. Again, think of the massive effort involved in making this change.

With the Unique Renaming approach, the clarity is more interms of the approach, since, it’s a straightforward renaming of all objects so that the objects from different BW systems, when consolidated, still remains issueless, as they stay unique and exclusive.  But, think of the manual effort to rename the entire set of objects (InfoObjects,DSO, Infocube, MultiProvider, Transformations, Routines, Queries, Process Chains etc.,.) This is quite cumbersome, as manual effort is massive, definitely inefficient and is more prone to errors.

Either way, it’s definitely not a project that’s regular in nature, but requires extreme clarity regarding the complexity of the activities involved and adequate planning and expertise is required to ensure that the consolidated BW system works as before.

My Other Blogs:

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo HS Kok
      HS Kok

      This is indeed a thought-provoking blog post. I would say that the superset approach has its drawbacks in that sense that you may possibly end up with a lot of records that have zero-values. This would be a waste of database space ultimately.

      Moreover, if the source ECC systems are still separated, it may not make sense to consolidate the BW landscape onto 1. Unless the ECC landscapes are consolidated first, then it would be easier for BW to react accordingly for consolidation.

      Then again, if you only have 1 instance of SAP ECC running in the company, why would you have 2 separate sets of BW systems (that requires consolidation) running in the first place?

      Thought-provoking indeed...

      Author's profile photo Sankameshwar Ramakrishnan
      Sankameshwar Ramakrishnan

      Hi Kumar,

      That's a good post. Indeed I'm currently involved in a project of same type.

      Conflicts as described by you are real and we are in planning phase. We already have the same approaches mentioned by you, but not finalised.

      Later may be I can comment how we handled and best approach ! 🙂



      Author's profile photo Former Member
      Former Member

      Hi Sankameshwar,

      We are working on a similar kind of project, could you please post few points on how you handled and the best approach.

      Many Thanks,