How to make a support package upgrade plan

[TMNielsen]

Hi

I'm sure this is the right forum, but please help if you can.

I can find a lot of technical documentation on making support package upgrades via SPAM, SPDD, SPAU etc. etc.,

- BUT I can't really find any overview description of the major parts of an upgrade plan.

As example my experience tells me that after upgrade of a development system, some kind of a "frozen zone" starts, and when the QA and production systems are upgraded this "frozen zone" ends. During the "frozen zone" no transports should be allowed to be moved from Development->QA->Procution.

But I can't find any documentation describing this kind of rules.

Of course I realize that a project plan for raising the support package level 1 step is different from "jumping" 43 support packages, but there must be some general steps and rules valid for any upgrade project.

Where can I find this general project plan description?

Best regards

[markus_doehr2 · Accepted solution]

This solely depends on your internal "upgrade strategy" - and I don't think there's a difference between applying one or 43 support packages.

We do that almost like your describe, freeze the development, apply SPs in DEV and QA, keyusers check the functionality and then they are put into production.

For EHP-Upgrades we do it at first on a system copy based on the production to check out which technical problems arise and fix them (notes, OSS calls etc.) before we actually start with our current landscape. That can mean that we have to do the upgrade a few times on the sandbox.

Markus

[TMNielsen · Accepted solution]

Hi Markus

Thanks for your reply confirming that what we do is right.

But what I really need is link to some official SAP document saying the same.

It is of course nice to know what is best practices, but I need some written documentation to convince people who thinks "frozen zones" and testing is just a waste of time.

Best regards

Thomas Madsen Nielsen

[markus_doehr2 · Accepted solution]

> But what I really need is link to some official SAP document saying the same.

> It is of course nice to know what is best practices, but I need some written documentation to convince people who thinks "frozen zones" and testing is just a waste of time.

SAP can't tell the customers how they have to arrange their internal development, they offer OPTIONS how to do that but they don't say what the customer has to do.

Depending on the size of your development team, the number of modifications you did/do in the system and the size of the company they may even be partially right.

Usually companies are audited (depending on the country) and those audits require a certain amount of change management documentation and a procedure, how it's done. This varies from country to country, you may e. g. need to follow regulations like US-GAAP, you may have special requirements for change document in FI etc. etc.

So I'd check first the legal side, what's required and then set the system and the environment up accordingly. Legal arguments are always good to convince people, that they get in trouble if they don't follow

Markus