Skip to Content

SAP BW system copy from 7.01 to 7.5 (not on HANA)

Oct 18, 2017 at 11:44 PM


avatar image

Hello everyone!

One of our clients has decided to do a fresh installation of SAP BW 7.5 (Oracle). They currently use BW 7.01 and our BW team is considering ways to better approach the situation - they basically want to move what they already have in the 7.01 to the 7.5.

In any case, we'll have sort of a sidecar scenario at some point in the near future: an old system running BW 7.01 and a new one running BW 7.5. This is beyond our control and we're trying to figure out the best way to move from here.

So far, we're considering two alternative paths:

A. a system copy between different versions of the system, assuming there isn't an extreme compatibility issue we're not fully appreciating yet; OR

B. importing all the requests transported from the old development system into the new one and moving them up the chain to production, having to set up data transfers between production systems to keep the historical data before killing the old system.

Is our "plan A" technically possible in any way? Or should we take it off the table and go for our "plan B" instead - considering all the additional complexity involved?

Thank you all for your time. Any pointers would be immensely appreciated.

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Best Answer
Frank Schuler
Oct 19, 2017 at 05:28 AM

Hello Igor,

Your scenario sounds straight forward to me:

A: You do a system copy of the BW 7.01 system and then upgrade that copy to BW 7.5.

B: I would not recommend to transport between different SAP releases.

Best regards


Show 4 Share
10 |10000 characters needed characters left characters exceeded

Thanks for the input, Frank! Much appreciated!

Please, may ask you a follow up question?

We're only doing this fresh install because their current BW embedded in ECC. It was a massive mistake, as they don't even use the ECC part of the kit, just the BW. Their de facto ECC is separated from BW.

If we decided to first install 7.01 on the new machine and transport our requests from the "old embedded 7.01" to the "new standalone 7.01", does it count as "different SAP releases" for the purposes of your point B?

We would then upgrade the "new standalone 7.01" to 7.5. I think it would simplify the process and prevent massive problems. I'm yet to see one of those big bang plans working as intended.


Hello Igor,

What you describe is exactly what I would recommend in your situation. A new BW 7.01 installation to transport all the embedded BW 7.01 content into. Since both are on the same release this will work. Embedded or not does not matter in this respect. Finally you upgrade the new BW system to 7.5. Of course, this will require rework, because a lot has changed from BW 7.01 to BW 7.5.

Best regards



Fantastic! Thank you for your advice, Frank!


Before this thread is automatically closed, I'd like to do a follow up on what happened in our case. If anyone reading this ever faces such an issue, you can learn from our experience. Thanks again, Frank, for the valuable insight.

We followed Frank's advice and things went somewhat smoothly from there. We decided to import each and every request released to production in the order they were released. That's because our client only had DEV -> PRD before (no QA), and a lot of objects were transported repeatedly to PRD because that's the only possible target. If they had a QA environment as well, I imagine we'd have to import fewer and more organized requests, focusing on what was imported in PRD instead of what was released in DEV. In that aspect, you'll probably have an easier time than we did if you have the full set of DEV -> QA -> PRD.

The import process has some drawbacks but the control over what is being moved to the new system and in what order definitely pays off. It's a boring process and you have to pay attention to the objects transported, but it is not rocket science. We ended up with some stuff missing in our new environment (checked against the old PRD environment), but then again you can just fill the gaps with a new request, collecting the handful of missing objects individually.

If you ever find yourself in the same position, beware of:

1. ABAP Dictionary objects, their versions and dependencies between requests. We simply transported everything from SE80 first, but there's a catch if you don't pay attention. If you transport a program in a new request NOW, the latest version of it is gonna be transported. However, if you then transport a request with the same program that was released a year ago, that old version is gonna overwrite the new one. If you're importing old requests, you're importing old versions of objects, and particularly, objects that depend on old version of programs.

2. Source systems. Many objects contained in the old requests depended on source systems that don't exist anymore. For the systems that still exist you just have to set up the name conversion table for source systems (Google it), but there's nothing you can do about source systems that are gone. You'll have to check every "red" request to see if the error was caused by this problem and check to see if everything else was imported and activated correctly.

3. On STMS, import stuff synchronously and, if possible, one request at a time. Importing many requests asynchronously caused a lot of missing objects if one of the requests was imported with an error (code 8, etc). In our case, this was a particularly time-consuming problem because most of our requests would've been just copies being transported if they had a QA environment back when the request was created.

Right now we're finishing the equalization of old DEV and new, standalone DEV. The next step is a client copy to new QA and new PRD. Not a lot of progress for three weeks, but some things are just out of our control.