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