Skip to Content

Upgrading to BW7.3 the unconventional way

Upgrade your BW system the unconventional way

In many cases we have seen that upgrading from BW3.x to 7.3 is not feasible because of limitations on authorizations etc.

Ideal Path:

It is a known fact that BW7.3 supports only analysis authorizations. This has led to an open question as to how you would upgrade a BW3.x system to BW7.3 without going through the steps of going through BW7.0.

This is because an intermediate step of BW7.0 is required so that you can migrate to analysis authorizations before migrating to 7.3 – but then the lingering question is that of whether we should test the application in its BW7.0 form before migrating to 7.3

This presents a lot of logistical challenges –

Resources : People are needed for a longer period for testing

Longer cutovers : We cannot hold back productive environments for longer periods.

Too much coordination – transports moving to BW7.0 , Development freezes etc all contribute to a royal headache

Another way of looking at it :

Install a fresh BW7.3 system

No need to elaborate this point

Transport all objects ( BW Objects sans authorizations ) from the 3.x system to the 7.3 system

Copy all the objects from the BW3.x system as transports into the 7.3 system – this is not recommended but then the structure of ODS /Cube etc is not changed – which means that these transports can be done.

Implement analysis authorizations
This would be either similar to the existing structure or reimplemented

Move the data over

Do an Export Import of the tables from the 3.x system into the 7.3 system – make sure you do both master and transaction data.

Now come the queries
Examine authorization variables and migrate / redevelop them

Transport the Queries

Now you have a single system to test and validate – once the development is validated – go ahead with the rest of the systems.

Once you have the queries with authorization variables – you can choose to create them manually / migrate the same.

Also since we are moving objects as transports – if you do any changes to these object , they might get collected as repair requests – this needs to be handled carefully.


Disclaimer : I have not done this in full – but we have tested the option of moving transports from 3.x to 7.3.

What we did was to move the objects from a 3.x system to a 7.3 system and then we did a functional migration of the objects. We reactivated all the objects and migrated the dataflow also. This would not qualify as an upgrade  in  technical sense.

I am just trying to reach out to understand if upgrades can be done this way instead of a mandatory two step process where we separate the application layer and the database layer .

You must be Logged on to comment or reply to a post.
  • Hello Arun,

    it’s possible to do cross-release transports however the devil is in the details. Please see note 556734, question 6 (and the notes mentioned in the answer).

    Especially between BW release 3.x and 7.x major changes occured and transports are very likely to run into problems. For example, you would have to execute the post release upgrade steps manually depending on the object type. Unless you are an absolute expert and can deal with issues like inconsistent meta data, I would stay away from this “upgrade method”.

    SAP Customer Solution Adoption (CSA)

    • Marc,
      I had not stated what we did clearly , we did a functional upgrade by moving the objects across. But then I am trying to understand if we can do an upgrade this way…
      We did face some resistance from the BASIS team about the transports but they worked out good in the end.

      I have accordingly corrected my blog content.

  • Dear Arun,

    a nice idea, but I don’t see the advantages. For the transports from 3.x to new 7.3 you also need a development freeze. How could you garantuee that no development from 3.x is missing otherwise?
    I’ve done a migration project where only part of the applications were migrated from 3.x to 7.x and this took weeks and was quite complex.

    Also implementing the new analysis authorizations can be a very complex task and should be tested intensively. From my point of view, here you’re right, this can be done on a BW 7.x or 7.3 system.

    As far as I know from BW 3.x to BW 7 there was some done some migration of objects, like webtemplates and workbooks. What about them?

    As we say, devil is a squirrel and jumps from tree to tree. The problems will occur in the details. Maybe the upgrade simply depends on the complexity of the old authorizations. I’m not sure.
    So from my point of view, I would not really recommend your shortcut. It may be possible for sandbox systems or isolate testing of special fetatures but not as a general recoomended way for upgrade of whole systems.


  • Hi, Arun,

    I’m not sure if I understood this statement: “This is because an intermediate step of BW7.0 is required…”.

    We’re planning upgrade from BW 3.5 to 7.3, and based on what I read until now this direct upgrade is possible, so I didn’t understand why is obligatory this intermediate step. Is just because authorization? In the way I see, authorization conversion could be done in development system, after the upgrade, and then transported to quality and production systems. Am I wrong? Or there are aditional issues?

    Thank you,