Parallel Support Package Upgrades

[david_zepeda]

Dear Experts,

We are in the early planning stages for applying support packages to our two SAP environments: once that is ECC / FICO, and the second which is Business Warehouse and BPC. Generally speaking we following an N-1 strategy to identify target packages from current early watch reports.

From a schedule perspective, we were aiming to apply support packages into each environment on a parallel schedule (Dev environments upgraded on same date, QA on same date, and production on the same date). There are concerns being raised that this strategy carries to much risk with it. I am looking for feedback either confirming the use of this strategy or affirming that risk would be too great.

As always, thanks for your contribution.

DZ

[yakcinar · Accepted solution]

Hello David,

First of all backup is important. If you take backups of your systems you loose sometime but you always have chance to restore your system and start whenever you stopped for downtime.

Second, since you are starting from development and then test systems, you can test your processes carefully on these non-production systems and minimize the risk as much as possible. Here you will need coorparation of technical and functional teams. SP upgrade process is more important for functional team then technical.

Besides above explanation if you have enough technical members also to perform the SP upgrade in parallel, it is not so much risky in my opinion.

There is always risks in SP upgrades. But necessities overcome these risks.

And also upgrade tool SUM minimizes this risk by minimizing downtime of the systems.

You can reset the upgrade till downtime.

Don't worry. Find senior technical and functional guys and continue.

Regards,

Yuksel AKCINAR

[david_zepeda · Accepted solution]

Yuksel,

Thanks very much for your rapid response. You might know the answer to this related question. Our Basis team is insisting that we implement a code freeze from the moment we apply support packages to Dev until we apply them to Prod. We do and have applied freezes for version (full) upgrades, but we haven't done this extensively or at all for support packages.

Any thoughts on this?

Thanks again,

DZ

[yakcinar · Accepted solution]

Hello David,

They are right indeed.

If you don't want to struggle with the problems about version differenses, it would be better freezing changes during SP upgrade project.

For custom developments freeze is not so important but for standart code changes there could be problems.

The real behaviour changes from customer to customer.

Some applies strict freeze rules. But the others can break the rule for urgent changes, for customer changes.

Functional consultants must be aware of changes if they change sth during the upgrade project.

Regards,

Yuksel AKCINAR

[david_zepeda · Accepted solution]

Yuksel,

Our primary concern during the upgrade event (from Dev to Prod) is supporting production. That consists of Data changes, configuration, custom development. By and large, we do not update SAP standard objects. If I understand correctly, we would need to disable the lock manually in order to accommodate that behavior in our environment, correct?

Thanks,

DZ

[yakcinar · Accepted solution]

Hello David,

During upgrade of each individual system (dev, qa and prod) there will be development lock (SUM tool asks to do this) for 1-2 days. You mustnot break this for the sake of the upgrade. But this rule is for the upgraded system only. This means you will not be able to change anything on development system during this lock phase. Or you will not be able to import any changes to qas and production system during the lock phase of upgrades of mentioned systems. Off course changes only for urgent maintenance issues.

As I said before better to be able to freeze during upgrades of all systems in the landscape.

This also does not mean that you will not be able to correct fatal, crucial errors onn production system.

Regards,

Yuksel AKCINAR

[Former Member]

Hi David,

My largest concern, which doesn't seem to be accounted for here, is testing and the ability to reproduce the process accurately and with minimal mistakes.

If you perform the upgrade simultaneously on all 3 systems, where is your testing occurring?  With support packs comes changes to current SAP code that can (and will) introduce it's own set of bugs.  We've seen bugs introduced in support packs that literally break come core functionality.  You have to do regression testing to identify these somewhere.  If you have an N+1 landscape, this would alleviate that, somewhat.

The second concern would be nailing down the process of actually performing the upgrade.  You'll normally perform a first upgrade in a Sandbox or Development system, and create a cookbook, detailing the steps, error handling, etc. of what you just went through.  Then in each system that doc gets modified, so that (in theory) by the time you hit production, you'll be ready for anything that gets thrown at you.  This becomes especially important using SUM, as opposed to SPAM. 

I'd be very careful, and very leery of performing the upgrade in all 3 simultaneously.

Hope this helps,

MM

[david_zepeda]

Matt,

Thanks very much for your feedback. Some additional information about the support package upgrade plans.

There are two systems involved here: one that contains FICO, and the second that has both BW and BPC. The respective Dev environments won't be upgraded at the exact same time. However when we get to the QA environments, we are planning to do both at the same time, including the full slate of regression testing. The QA environments will be open for testing 5 weeks before we apply support packs to production, again at the same time.

I'm not sure if any of that information changes the degree of risk you foresee relative to an effort like this?

Thanks,

DZ

[Former Member]

Hi David,

Perhaps I was not understanding correctly.

Are you asking if there's a risk of simply doing BPC at the same time as ERP?

-or-

Performing DEV, QA, and Production all at the same time? 

It sounded, up at the top, that you were considering doing DEV, QA, and Production (of both systems) all on the same day.  That's what alarmed me, as it didn't seem like there was any regression testing (which would be horribly painful and a large risk, depending on the size of the stack).

We generally like to do our standalone Netweaver stacks concurrently with our ERP stacks, but that remains a somewhat personal preference, and a source of debate.  As in, if we do ERP EHP7 stack 11, we'll find the corresponding Netweaver stack, and perform that on our portals, BW, etc. all at the same time.  In my humble opinion, this minimizes risk simply because everything then has the same core stack below it. 

It's a lot of information, and I hope this makes sense.

MM

[yakcinar]

Hello Mathew,

I understood from David's first message is that simultaneous upgrade is between ERP and BW-BPC.

Not all dev-test-prod at the same date.

He tells "(Dev environments upgraded on same date, QA on same date, and production on the same date)".

Regards,

Yuksel AKCINAR

[david_zepeda]

Matt,

My apologies for the confusion. My query is correctly categorized as being the first item you mention (simply doing BPC at the same time as ERP). We won't be trying to do all of this this in the same day or weekend. Quite to the contrary, we have the entire upgrade event, end to end, stretched out over a couple of months time.

Thanks,

DZ

[Former Member]

That was my fault for misunderstanding, hence why I was so worried.

So yes, I actually prefer to do the standalone with the ERP stacks, the risks are simply in the timing and testing.  You'll need to make sure that regression testing covers both, and that the integrations are thoroughly tested.

Thanks so much,

MM