Best Practice: ECC6->EHP5 Upgrade (2 Hour Downtime)

[Former Member]

Hi all,

I have a client that needs an upgrade from ECC6 EHP2 to EHP5. They are using MaxDB 7.6 on windows 2003 R2 64bit. The hardware is powerful and they are currently not running at full capacity.

The problem is that they can only afford a maximum of 2 hours downtime, so what is the best approach to do the upgrade?

They need to focus on the SAP_APPL (currently 602), IS-H(currently 602) and SAP_BW(currently 700) components.

My understanding is that EHP5 will automatically upgrade the NetWeaver components to 705 - is that correct? If so then the SAP_BW component should move up to 705, right?

The real challenge is keeping the business downtime under 2 hours...

Thanks very much

[sunny_pahuja2 · Accepted solution]

Hi,

Your downtime depends upon how much optimization you can do in upgrade. Noone can suggest you on downtime part. You have to do mock test and find out how much downtime will be required.

Second, all netweaver components will be on 702 release in case of EHP5, only ERP components will be on 605 release and only those ERP componets which will you upgrade to 605, rest will be on 600.

Thanks

Sunny

[Former Member · Accepted solution]

Hi Sunny - thanks for your input. I meant to say 702, not 705...

I understand that it will be a "per customer" basis, but what I am looking for are different methods used in these sort of situations. It is highly unlikely that we would be able to do the upgrade, carry out all post-upgrade activities and do final testing within 2 hours, regardless of optimizations. So what I am looking for are ideas on reducing the business downtime - an example would be to run two production systems in parallel for a day or two while the upgrade takes place, and then once ready and tested, the cut-over or switch can take place with almost no downtime...

[JPReyes · Accepted solution]

So what I am looking for are ideas on reducing the business downtime - an example would be to run two production systems in parallel for a day or two while the upgrade takes place, and then once ready and tested, the cut-over or switch can take place with almost no downtime..

MMmmm.... that would most likely will lead you to data inconsistencies in between them....

I recommend the same as the rest... setup a sandbox and run the a couple of upgrade iterations, 1st iteration to correct all issues, 2nd to focus on pure performance... you can do all the testing you want on that box (including your funtional testing). At the end of the process you should have a pretty good idea of what to expect.

Regards

Juan

[Former Member · Accepted solution]

Thanks Juan,

I agree that the parallel systems may cause inconsistencies - it was just an example

I understand that in order to determine the least possible downtime for the upgrade it would simply take some rehearsal upgrades. The problem is that the client has indicated a maximum downtime of 2 hours - so regardless of how quickly we can upgrade the system, they cannot afford more than 2 hours downtime. If we are taking too long, we need to abort and give the old system back.

So again, what is the suggested approach? Surely in this case it would not be a good idea to upgrade their current production system hoping that nothing goes wrong? What is the fail-safe?

[sunny_pahuja2 · Accepted solution]

Hi,

I think 2 hours for downtime is highly unrealistic. You will run SGEN as part of downtime, so, SGEN alone will take more than 2 hours.

2 parallel production system approach is not possible. Because of how you will migrate delta data to your upgraded system.

Only thing I will suggest you to do the mock run and come at good downtime estimate and pass those figures to client. And client should decide based on that.

Thanks

Sunny

[JPReyes · Accepted solution]

Agree with Sunny, The best you can do it to give them a good estimate of a realistic timimg required for the job and let them decide and sort the downtime.

Regards

Juan

[Former Member · Accepted solution]

Hi David,

Well, Near Zero downtime seems to be an approach introduced for customers demanding 2 to 4 hrs of business downtime.

A brief about this:

With the Near Zero Downtime method, the upgrade is performed on a clone of the production system. During this upgrade, all changes to the production system are logged at the database level. After the completion of the upgrade on the clone, the real downtime begins. During this downtime, the data changes from the production system will be transferred to the clone. The data transfer is performed by the tool based on the Migration Workbench. The tool will also transform the data structure in case of changes in the data model between the old and the new release. After system validation, the clone takes over the role of the production system.

But ofcourse, its disadvantages are:

Additional project effort and a longer upgrade project (minimum of six months).

Additional hardware requirements.

Code freeze for four to six weeks prior to go-live.

Restricted transport for one to two weeks prior to go-live.

Link: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/b0bcdae4-a5f0-2d10-ae89-b5512d4aa...

I only know of this as an approach tried for one of the SAP Customers. Have never been a part of it. Perhaps someone else here knows/has tried.

Regards,

Srikishan

[sunny_pahuja2 · Accepted solution]

Hi,

I think approach suggested by Srikishan is fine but again Transport freeze will be longer and again this will be a kind of downtime to customer because of no transport to production.

And kind of effort and experience required in this approach will be high.

Thanks

Sunny

[Former Member]

Thanks everyone for your suggestions - I really appreciate it!

[Former Member]

Hi David,

As Sunny mentioned, the 'best' way to approximate a downtime is by running a mock upgrade using a copy of the target productive system.

However regarding downtime minimizing - the following document could also help:

http://searchsap.techtarget.com/How-to-minimize-upgrade-downtime-during-SAP-ERP-60-upgrade-projects

ICNV, CBU, NZD could be some options you could explore.

Regards,

Srikishan

[Former Member]

Thanks Srikishan - I will have a look at the link...