Why Upgrade?

What compels a firm running multiple versions and multiple products of SAP to upgrade its ERP and other usage types? The (not always) obvious reason is the need for new functionality, which can better support company business needs and help them thrive in an ever growing competitive landscape. Basically, they want their business to run better than other businesses in their market. So a brief note on the release strategy for SAP applications, which follow a “5-1-2” maintenance concept: “5” years of mainstream maintenance; “1” year of extended maintenance at an additional two percent of the maintenance fee; and finally, “2” years extended maintenance at an additional four percent fee. Not cheap, but it may be cheaper than a big upgrade project. After that, if you still don’t want to let go of the SAP release, there is always customer-specific maintenance, which is expensive.

I am sure that most of the decision makers are not aware of this information, and that is why I’m  writing this post.  SAP customers need to know of the additional investment they would have to make to keep their SAP system, running status quo.  I would encourage you, and your bean counters, to do the math on considering your SAP installations. After that, I am sure you would be compelled to focus on the upgrade (if not now, when?).

New Functionality

The main reason for upgrading has almost always been the additional functionality.  There are other reasons as well, like instance consolidation, virtualization, and requirements based on hardware, software and O/S.  Every SAP release brings new features, challenges and opportunities.  The need to upgrade is mostly driven by business needs, which in turn require new functionality in your SAP environments.  This empowers your company by transforming your processes and moving your company to higher levels of efficiency, richer reporting with new and improved analytic tools like BIA and HANA, and ability to make timely and informed business decisions.  The choice must be made whether to implement and develop the new functionality or perform an upgrade. This is not always an easy evaluation and the amount of customizing you do will certainly drive this decision.  This is the so-called “solution gap” and you have to ask, is the solution gap large enough to justify the SAP release upgrade?  And since SAP upgrades are time consuming and usually complex, is it worth investing time, money and resources to address this solution gap with an upgrade?

Yesterday’s Technology

SAP systems need to be constantly customized and enhanced in order to support evolving business needs. The time will come when the installed instances will no longer be able to suit your needs.  Staying on the same release is unsustainable from an infrastructure point of view as you will be required to stay on older hardware, software, and O/S.  If you have systems with many external touch points, it becomes more difficult over time to keep these working, especially if you are running much older SAP software.

Support Costs

As I pointed out earlier, there is a maintenance limit to every SAP instance, and the extended support leads to significant additional costs.  Here lies the tipping point between an upgrade and paying for the extended support. There are two choices: upgrade or a customer specific maintenance.  The latter is not very attractive as it implies increased cost for a depleted service level, as SAP no longer provides support packages for releases that are out of maintenance.  Surprisingly 35 to 40 percent of SAP customers are compelled towards an SAP upgrade based on this factor, which would be either ending the maintenance period for their SAP release or incurring the additional maintenance cost.

What it Takes

Testing and end user training represent the major part of any upgrade project. These processes take the most time and effort.  During the upgrade, do not implement new features, modules or applications.  The primary focus should be the upgrade task, and the new features should be implemented afterwards in a separate project.  Like any install/upgrade process, you should start at the first system in your landscape, like DEV or the Sandbox.  After upgrading the DEV system, you need to test all relevant SAP applications, custom developed objects and integration to other applications (SAP and non-SAP). If you have used Solution Manager (most companies don’t), I  recommend  using this investment by leveraging the testing and TAO on SOLMAN.  While you resolve the issues arising from the release upgrade, the production system is still running in the old release, hence change management procedures need to be set up to support the production system.  This can be done by moving to a “5” system landscape (a subject I’ll cover in another blog.)

SAP Upgrade

The technical portion of an SAP upgrade is typically less than 25 percent of the work.  The other 75 percent goes to testing and training for the new release, as upgrades affect the business applications and processes. As you start an SAP upgrade project you must realize the following:

• Every member of the SAP upgrade team conforms to the upgrade methodology.
• You have SAP Solution Manager installed and running as part of your SAP installation.

The SAP technical upgrade consists of five major phases:

1. Preparing of the Environment
2. The Prepare Process
3. Up Time of the Upgrade
4. Down Time of the Upgrade
5. Post Processing Activities

Let’s break them down.

Preparing the Environment

Proper preparation of the upgrade is required or you will run into problems.  An upgrade is a time-consuming and complex task, hence the need to be organized and maintain good documentation of your work.  SAP has a wide range of upgrade services within their portfolio, such as Go-Live Functional Upgrade Check, SAP Safeguarding, SAP upgrade Hosting and many more.  The list is constantly being updated to cover various audiences and scenarios. Check out https://service.sap.com/upgrade-erp/ for their latest set of offerings.

Project Plan

After reading the materials, as well as comparing my own experiences with my colleagues on several upgrade projects we came to a consensus of developing 3 phases:

• Phase 1 – A high level view of upgrading all the different SAP systems (DEV, QA, PRD) and the satellite systems (BW or SCM etc.)
• Phase 2 – A detailed task list for each instance within the overall landscape describing the activities needed to be carried out before, during and after the upgrade.
• Phase 3 – Describe the technical upgrade itself, as it contains the action taken during the technical upgrade.

Collaboration

Upgrade projects need the commitment and support of management and all the teams that are impacted by it. Some of these teams include the project management team, technical upgrade team, and functional team.

Sizing

DO NOT skip this section.  I have run into so many issues around sizing, so if you think you don’t need to size, you are wrong.  Resource requirements increase with every SAP release, and if you have a productive SAP environment, this increase is difficult to change and quantify.  Sizing depends heavily on which SAP modules and business processes are used, the number of concurrent users, and the amount of business data (transactional data).  Analyzing the current situation is the first step in estimating the load increase. This is why we emphasized having SAP Solution Manage running before you start thinking of an upgrade. Apart from providing the analysis on the current system through Early Watch Reports, Solution Manager is also necessary to get the upgrade key (migration key) from SAP.  In addition to this, SAP also provides some online tools for capacity planning which can be accessed from https://service.sap.com/quicksizer, and besides this, many performance and tuning transactions exist in SAP like DB02; ST03N; STAD; ST04, SM04, ST06,etc.

The Prepare Phase

The technical process imports the tools required for the upgrade and performs extensive checks to see whether the system is ready for upgrade.  Careful preparation of the upgrade is the best guarantee that it will run without any errors.  The prepare program uses a series of checks to support the preparation of the upgrade; it can be used without affecting the productive environment.  The advantages of executing PREPARE are:

• It uses the same upgrade tool as the upgrade (technically it is the special run mode of the upgrade program R3up.).
• It displays and highlights the objects that would appear during the modification adjustment.
• It forecasts the number of database conversions, space requirements, and requests allocation of additional space if necessary.
• It can be executed while the system is being used for productive purposes.

The PREPARE phase can be broken down into seven different sub-phases, as schematically displayed in figure 1.

                                                             Figure 1: Upgrade Process

The PREPARE starts from the input phase in which information on the system to be upgraded and key generation activity are performed through Solution Manager. Then, some basic consistency checks are done.  In the initialization phase, along with some basic checks on the source system, the SAP and database releases are verified and the needed space for the upgrade tools is verified (this is a critical step, have double the DB storage available.)  The import phase imports all the tools needed for upgrade into the database and installs them in the upgrade directory.  In the extension phase, the add-ons, support packages, user modifications, and languages are installed in the source and integrated into the upgrade.  The extension phase is the most important phase in PREPARE as the target release of every SAP component and add-ons is decided.  The extension phase leads into the integration phase in which all the support packages, add-ons, customer modifications and additional transports are integrated into the upgrade.  The integration and extension phase are closely related.  The installation phase comprises the shadow instance and shadow schema being created into the database.  At this point, all the verification tools are used to verify the source environment meets the upgrade requirements.  The general check module identifies many things like versions of systems, looks at the locked objects and availability of free space for database, lists tables which are not converted, DDIC and repository object with conflicts in the new release, etc.  The luxury we have in the PREPARE is that it can be run and reset any number of times.  Before the actual upgrade, the successful execution of the PREPARE phase insures somewhat smooth sailing during the upgrade.

Up Time of the Upgrade

This phase calls for activities like:

• Importing of all new data dictionary objects, programs and languages together with the latest support packages into the system, all in a non-active stage.
• Comparison of the new data dictionary object with those changed by the customer through modifications and notes.
• Resolution of data dictionary conflicts.
• Activation of data dictionary objects still in a special non-active stage.
• A mass pre-upgrade conversion of large tables (ICNV).

Down Time of the Upgrade

• Activating all new repository objects (dictionary and development objects).
• Changes at database level, e.g. creation or conversion of tables.
• Conversion program to adopt data into the system according to the changes data model.
• Technical activities e.g. parameter changes, etc.
• Importing of custom modifications to the development objects.
• Key user testing

Post Processing

Release the system to end users to start post-production work in the new release.

An upgrade of SAP to a new release is tricky.  With this blog, I have tried to show some of the motivating factors which an organization may need to review before committing to an upgrade project.  Furthermore, I have identified some of the key phases and activities that need to be carried out within a SAP upgrade project.