This is the first in a series of posts that I will write regarding upgrading your SAP system.  2010 is anticipated as the year of the upgrade (you heard it here first – maybe not) as many SAP customers saw an upgrade as an easily avoidable expense in the midst of the economic carnage of the last 12-18 months.  Also, SAP is on a push to get customers off earlier releases and up to ECC 6.0 and various EHP (enhancement packs) to make upgrades a thing of the past.

Excuse a note of skepticism about the end-of-upgrades-as-we-know-them, I suspect the path and the mechanism to get new functionality will change.  The text book methodology and approach will change, but I suspect SAP customers will be hesitant to let go completely of previous approaches to upgrades.  Sounds like a topic for a future blog post.

In these posts I’ll address some of the upfront considerations before you embark on an upgrade, then progress on to ways to leverage some of your existing assets to make the process as successful as possible.  Along the way I’ll discuss the impact on your SAP landscape, non-SAP systems, and other ongoing projects you may have in motion.  As a wise man I once worked for said–and I’m paraphrasing–“we don’t want to rebuild the plane in midair.”  Trying to get it in the hangar without passengers onboard is a noble goal, but perhaps not completely realistic.

For more on SAP Upgrades download the white papers:

SAP Upgrade Checklist

Customization Risk Analysis in an SAP Upgrade Project

As always, comments and feedback are welcome, but I ask you to be civil.  Your experiences are not the same as mine, I can learn from you and I hope you can learn a little from me.  Let’s begin.

SAP Upgrades: Start with the End in Mind

There are plenty of reasons why you want to upgrade your SAP system and those reasons will probably drive your approach, how you position the project and execute.  Influencing factors include, but are not limited to:

• The current release is old and is either on extended SAP maintenance or is about to go on to extended maintenance
• Recent changes in SAP licensing are an incentive to upgrade
• Other parts of your systems environment and infrastructure are changing and an SAP upgrade makes some of these changes easier or enables them
• New functionality is required to support acquisitions
• New functionality is required to decommission legacy systems
• New functionality is required to expand the SAP footprint in your organization
• Custom development is becoming too cumbersome to maintain and can be decommissioned by standard functionality in the new release

In short, there are likely to be several reasons why you want to upgrade and your organization has other considerations over and above those listed.  By identifying the drivers for your upgrade you should be able to work out who most wants it to happen as well as those who are not supporters.  On top of this you work out who has the most to gain from it in the short, medium and long term. All this is useful for putting together the pitch

SAP Technical Upgrade versus SAP Functional Upgrade

There is much discussion around the pros and cons of performing a technical upgrade versus performing a functional upgrade.  To some extent I view this as a false choice: a technical upgrade is always going to involve some functional upgrade work – it is a matter of degree.  (The only escape clause here might be if you have truly installed SAP with no custom code, but I have yet to find an installation with no custom code).

The big selling point of a technical upgrade is that it is the quickest option and the least intrusive.  All true, but nonetheless you still need to go through the upgrade process several times to ensure it works without problems and you need to test the upgraded system to ensure that you can still run your business processes.  Even an SAP system with limited amounts of custom code needs to report out on the custom code forcing you to do some work and make decisions about it.  Typically the work and decisions have one of several possible outcomes:

• The custom code is still needed because the new release does not support the required functionality, hence you have to keep the code and test it with the new release.
• The custom code is no longer needed because the new release delivers the required functionality.  Consequently, code is decommissioned and you have to test the standard process.
• The custom code has to be modified in some way to work with the new release.  Again this leads to some testing and business process verification

Each custom object should fall into one of three buckets outlined above and this starts to identify work plans and activities.

A note of caution on the identification of custom objects: development environments often contain half-finished and abandoned objects, work-in-progress, and objects that never moved.  These objects can unnecessarily inflate the list of objects that need to be reviewed, so getting a list from production or the QA system can produce a more accurate list.

So even in the context of a technical upgrade I’ve run into the need for some functional work.  If my overall upgrade project objectives include deployment of new functionality I have the same considerations as a technical upgrade but now I have to scope, design, develop, integrate, test and deploy the new functionality.  Clearly this means more work, more time and more expense before the upgrade goes live.

In short, I like to think about technical and functional upgrades as two overlapping circles in a Venn diagram: the size of the overlap is what I am trying to control when I label my project a technical upgrade or a functional upgrade.

Finding Your SAP Upgrade Path

Another factor when planning the SAP upgrade is where you are starting from and where you want to get to.  There may not be a direct migration path from your current SAP release to your target release, in which case you need to identify the interim stepping stones and the impact that has on overall elapsed times and complexity.  Based on the uniqueness of your environment there may be actions you need to take at the interim release before you can get to the end release.

Making the Pitch for an SAP Upgrade

In my experience there is rarely a single concise driver for making an upgrade and each SAP installation has different factors influencing the decision.  Finding the right pitch with a convincing cost justification is pretty tricky: a (mainly) technical upgrade is often pitched as a precursor to greater things (delayed gratification, if you like), whereas a functional upgrade delivers value more quickly.

Addressing the demands of your decision makers and your budgets is always challenging, but you should also remember that upgrades are part of the TCO with SAP.  At some juncture you need to upgrade and finding a time in the business and IT calendars to focus resources on the project is unavoidable.

Next Steps Preparing for an SAP Upgrade

In my next post on upgrades I’ll discuss how you can leverage and re-use some of the work done on prior projects that can accelerate your upgrade.