There is always an expectation of a high number of upgrades in the SAP community and SAP themselves have expected this to happen a number of times in the last few years.
The challenge for SAP is that a large number of emerging technologies only run on the latest version of SAP: SOA on ERP 6.0 and the Business Warehouse Accelerator on BW 7.0; the new improved WebUI of CRM 6.0 and 7.0. However it is difficult to demonstrate ROI based on new features alone and it is generally projects with direct business value that can easily demonstrate ROI. Upgrades are often put on the back-burner to make way for other projects.
The challenge for the IT professional is to justify such an upgrade in terms of cold hard cash and to demonstrate a ROI. In 2010 this may be much easier than it has been, because a number of versions are simply falling out of support. Thus rather than having to explain the intangibles of future business benefit - which may be substantial - IT may be able to rely on SAP to deliver the new versions that the business needs.
In addition to this, the global recession of 2009, which seems to be slowly lifting in 2010, has ensured that many upgrades that would have happened in 2009 have been pushed to 2010 and that there is a pent-up demand for innovation and creative thinking.
SAP support - time is running out
Today though one of the issues is SAP support. Those businesses still on R/3 <4.7, CRM < 6.0 and BW < 3.5 won't be able to rely on any SAP support at all by the end of the year (unless they have customer specific maintenance agreements) - look at the table below for more details.
SAP CRM 4.0 - 31.12.2009 (not extended)
SAP CRM 5.2 - 31.12.2010 (not extended)
SAP R/3 4.6C - 31.12.2005 extended to 31.12.2010
SAP R/3 4.7 - 31.03.2009 extended to 31.03.2013
SAP ERP 2004 / ECC 5.0 - 31.03.2010 extended to 31.03.2013
SAP BW 3.5 - 31.03.2010 extended to 31.03.2013
In addition, those businesses on R/3 4.7 or ECC5, on CRM 5.0 and BW 3.5 will have to pay for extended maintenance as of this year. In basic terms unless they are on the latest version by the end of the year, they will be either paying extended maintenance fees, or be out of support.
Where to from here?
If you recognise that you need to bring your SAP landscape up to date, for whatever reason, then what next? Here, I show 3 different broad approaches to upgrades and where they might be best used.
The technical upgrade
In certain circumstances, the technical upgrade is a great way to get to a supported version and then subsequently consider additional business value. I extol technical upgrades in BW scenarios in particular - especially from BW 3.x to 7.x.
There is little benefit of trying to perform a 7.x functional upgrade at the same time in most instances, because it dramatically extends the testing window and complicates the signoff procedure, and requires careful timing between business and IT.
Instead for BW I recommend a pure technical upgrade. The query conversion and authorizations can come later and the back-end (DTP/DSO/transformation) changes can happen when you are ready.
The functional upgrade
When upgrading from CRM 4.x or 5.x -> 6.x or 7.x, it is unusual for the upgrade to be possible without functional rework. This is because the much-hated PCUI interface that beleagued 4.x and 5.x has been replaced by the much-loved WebUI interface of 6.x and 7.x.
Actually that's not quite true because 5.1 and 5.2 had aspects of the WebUI but only a small number of SAP customers run that. Still, in most cases a CRM upgrade means functional rework, for huge business benefit.
The main question then is - how much of the business logic was in the PCUI interface. If your CRM system has been developed well, then the business logic will be in the back end. If not - you will have swathes of logic in the PCUI layer which will have to be either moved to WebUI (bad practice) or moved to the back-end (good practice), with the WebUI layer built on top. The amount of effort that this involves depends entirely on your CRM environment.
The considered upgrade
Most ERP environments sit in a middle ground called the considered upgrade. Most R/3 environments - especially ECC 5.0 - can be upgraded to ECC 6.0 as a technical upgrade.
The question is whether or not a pure technical upgrade is the right thing to do and the answer lies in the detail. By performing an upgrade analysis of your custom objects and comparing them to ECC 6.0 standard business processes, you can map out whether the functionality that you customized is then standard business process in ECC6. If that is the case then you have to consider whether to bring that functionality back to standard.
In most cases, businesses choose to bring some aspects of functionality back to standard, reducing customization in the upgraded environment and simplifying future change.
The SAP upgrade assistant permits Enhancement Packages to be applied as part of an upgrade, in some instances. My advice is always to consider the target version and try to get on the latest EHP if possible, which is quite different to getting onto the latest Support Package Stack (SPS).
To unicode or not to unicode
Most non-Unicode versions of SAP are supported until at least 2015, though you should check PAM for your specific version at https://service.sap.com/pam. On this basis you need to consider when to move to a Unicode version of SAP. My advice is to move at the point of a significant event.
The most significant event is during a heterogeneous migration, e.g. moving from UNIX/Oracle to Windows/Oracle. During this process, moving to Unicode is a matter of checking an extra box and performing some further testing.
If you don't expect to perform a heterogeneous migration before 2015 then the next best option is what is known as a Combined Unicode & Upgrade (CUC). This is to say that you can perform the Unicode conversion at the same time as an upgrade.
Last down the list is performing a Unicode conversion on its own. This is generally only performed when the business has a requirement for non-Latin code pages at that point in time, usually for a global rollout to a new country e.g. China.
SAP Solution Manager 7.0
Solution Manager adds huge value to future upgrades. Despite the challenges around Enterprise Support that SAP faced in 2009, Solution Manager remains an excellent way to perform future upgrade assessments. Consider whether to bring your business processes into Solution Manager as part of your upgrade and thereby reduce the cost - and risk - of applying future support packages.
Upgrades are complex entities that require a lot of technical effort and a significant business investment in both cost and time, in many cases. Choosing the right upgrade path will both significantly reduce your cost of performing an upgrade, but also decrease the time-to-value that your organization experiences.
For all these reasons, I think that 2010 is the year of the upgrade.