ERP6 Upgrade

[Former Member]

Hi,

I have a 3 systems landscape (DEV, QAS and PRD) and will be upgrading them from 4.7 to ERP6 soon.

I will do a test ERP6 upgrade on my DEV/QAS first and this is expected to take a few months before I upgrade the PRD server.

After upgrading my test servers (DEV and QAS) to ERP6 how can I manage my transport requests between DEV and QAS to PRD since PRD is still on 4.7?

Thanks for any advise.

[sunny_pahuja2 · Accepted solution]

Hi,

It is not recommended to transport between then systems having different version as object will also have different version.

Thanks

Sunny

[Former Member]

Hi Steven,

We also recently went for a upgrade for SAP 4.7 to ECC 6.0 and we too followed the same methodoloy as said by Tom.

Regards

Nitin

[Former Member]

Hi,

We are just nearing the end of an upgrade from 4.7 to erp 6 ehp 4. We have the same landscape as you, plus a separate sandbox server which I used to upgrade 2 or 3 times before attempting it on the production landscape).

The approach that I took was to build a brand new landscape on separate hardware (in our case we virtualized, so hardware wasn't such an issue).

So, our existing landscape was as follows:

D30 - Q30 - P20

This landscape stayed in production until right up to when I started to prepare for the production upgrade (which starts tomorrow!!!). This allowed us to manage any necessary change as it came up over the 3 months between the DEV upgrade and Production Upgrade. BUT, we had to duplicate any changes in the new landscape to keep all systems consistent.

I built a new Landscape as follows:

D40 - Q40

D40 was upgraded first, and was from a copy of P20. Within D40 two clients were created, one for config/and workbench, and one for unit testing. (you could create 3 or 4 clients as needed for testing/config/abap/etc.)

Q40 was upgraded second and full integration testing was performed.

Today, I dis-joined P20 from the existing transport domain (the old landscape), and joined the new landscape as tomorrow we start the production upgrade.

Now our production landscape is:

D40 - Q40 - P20

The old landscape will be decommissioned.

The only problem I have with this approach is that we lost all change history when we created a new D40 system. But, the benefits of a consistent and up to date Dev system outweighed this issue.

Good luck with your upgrade!

Tom

[Former Member]

Thanks Tom, that was very helpful.

Anyone else who would like to share their transport strategy during ERP6 upgrade?

[Former Member]

The above given approaches are the recommended approaches.

If you do not want to maintain a dual landscape, the possible way is to Hardfreeze all the changes, i.e., no change will move to production during Upgrade. I understand this is tough.

Follow the below approaches if you find them helpful -

Approach 1

1. Copy DEV to a new Hardware and call it DEV*

2. Upgrade DEV* and do all the SPDD/ SPAU and any other fixes on DEV*

3. Reconcile all the changes that happened in DEV to DEV*

4. Complete Unit testing on DEV*

Till this point you have the Support Path DEV >> QAS >> PRD in place.

1. Remove QA from the transport path (Now the transport path will be DEV >> PRD)

2. Upgrade QA directly

3. Complete testing

See that the QA Upgrade timeperiod is short, i.e., 4 weeks before PRD upgrade and see that no changes move to PRD during that time. Maintain a real real Hard Freeze.

1. Upgrade PRD

Approach 2

1. Remove the Existing DEV from the Transport path (Now the transport path will be QAS >> PRD)

2. Upgrade DEV

3. All changes that need to move to PRD will follow QAS to PRD

4. Reconcile all changes that moved to PRD from QAS to DEV manually

1. Remove QAS from transport path (No Support path, any changes will have to be done in PRD directly or maintain a Hardfreeze)

2. Upgrade QA directly

3. Upgrade Landscape will be DEV >> QAS

4. Complete testing on QA

1. Upgrade PRD

But the approach 2 is a bit risky, but if it is decided no changes will move to PRD, or changes can wait till go live then we can follow this.

Hope these will help you.

For any queries please get back.

[Former Member]

if your sysetems are on 32 bit you can transports the request from DEV/QA to PRD.

[markus_doehr2]

> if your sysetems are on 32 bit you can transports the request from DEV/QA to PRD.

Neither bitness nor OS nor database is relevant. Transports are by definition agnostic of all that.

Markus

[Former Member]

Hi,

customizing transports are not allowed between different versions, client independent objects can be transported, but it does make any sens because the same objects can have different structures in two versions.

Regards,

Mirek