SAP Release Change and Unicode Migration. A Customer Experience Report

SAP Release Change and Unicode Migration. A Customer Experience Report Applies to: Upgrade from SAP R/3 4.6C to ERP ECC 6.0 including unicode migration. Summary This article describes the experiences during a successful upgrade project from SAP R/3 4.6C to ECC 6.0 and a unicode migration at the same time. It does not go into technical details, it rather outlines the different phases of such a project. It also describes the pragmatic approach a mid sized company has chosen. The company is a independent family owned business with about 4000 employees world wide, operating in eleven locations worldwide. Author: Roland Hogg Company: Marquardt GmbH, www.marquardt.de Created on: 20. May 2008 Author Bio Roland Hogg is working with the Marquardt GmbH in the SAP Basis area and project management. He has 14 years of SAP R/3 experience. He worked for different companies in SAP Basis, system management, authorization management and application support. 2008 SAP AG 1

Table of Contents Introduction...3 Project overview...3 Target system:...3 Timeframe:...3 The main reasons for the project have been:...3 The first SAP Basis testsystem...4 The user testsystem...4 User tests...5 Development stop...5 Upgrade of the production system...6 Summary...8 What did we do right (besides all the standard tasks)...8 Lessons learned...8 Disclaimer and Liability Notice...9 2008 SAP AG 2

Introduction With this article I want to outline the experiences we made during our upgrade and unicode conversion. Also I want to give an example for a pragmatic approach to such a project (how it is probably made in hundreds of companies). When we started the project I was looking for similar experience reports of other SAP customers, searching for tools they have used or learning from their project phases. But I only found reports form large companies, describing manpower or tools which were far beyond the possibilities a midsize company can afford. Intentionally I did not include too much technical description, as this can be found in the appropriate SAP documents and on the web as well. Project overview Source system: SAP R/3 4.6C. MDMP system with the languages DE, FR, EN and RO installed. SAP IS Solution IS Automotive installed. DB Size about 750 GB, number of users about 1200. 2 Add-On products installed, and lots of self programmed ABAPs in the system. About 20 interfaces to other systems. Target system: SAP ERP 2005 (now ECC 6.0) with ECC DIMP on unicode. Only technical upgrade. Timeframe: The main part of the project ran in the timeframe from Mai 2007 until January 2008, the actual productive upgrade has been made during Christmas 2007. The main reasons for the project have been: End of standard support for 4.6C. Business need for getting a new basic underlying SAP core for the upcoming projects. Business need for the implementation of the Chinese language (ZH) (which is only possible with a unicode system). 2008 SAP AG 3

The first SAP Basis testsystem Actually, before we really started with the core project, we have set up the first testsystem (as a copy of the productive system), where we have made the first upgrade and unicode migration. This system was only intended for the SAP Basis and a couple of developers. Here we got a feeling for the upgrade runtimes, basically on these runtimes we decided the downtimes we needed. Also the developers could get an insight view about the tasks and the changes which would come up. One of the important issues, which have been clarified with this system, has been that the SPAU points could be solved. So, without having a big time pressure, we could document which modifications we had to keep and which ones we could return to standard. The user testsystem April 2007 we started to create the first user testsystem. This was also a copy of our productive ERP system, where we did an upgrade / unicode migration. For system copy / SPUM4 / Prepare / SPDD / Upgrade / Export / Import and SPAU we usually planned 10 days. Note that SPUM4, SPDD and SPAU have already been documented from the SAP Basis testsystem and that over 95 % of the issues have been clarified before. On this system also the development adjustments have taken place. We had about 1500 reports in the customer name space (starting with a Z or a Y), we assumed that we only had to adapt about 50 % to unicode. Now, how should we decide, which programs we had to work on with which priority? We created a list of all the affected programs. All the programs, which the developers knew by heart (that they are used on a regular basis) got the priority A. Then we have (on the productive system) reset the ABAP generation timestamp for the customer programs and waited 4 weeks. All programs which have been generated in this time got the priority B. Priority A and priority B programs we have adapted to unicode, for the rest we waited for the user tests. The code for resetting the generation flag: REPORT ZERP_BC_TOUCHSOME. tables: zbc_relprog, d010sinf, d010linf. data: iprog like zbc_relprog occurs 1 with header line. select * from zbc_relprog into table iprog. loop at iprog. update d010sinf set sdate = sy-datum stime = sy-uzeit where prog = iprog-name. update d010linf set sdat = sy-datum stime = sy-uzeit where prog = iprog-name. endloop. commit work. 2008 SAP AG 4

User tests The first user tests have taken place from mid of May until September. Together with the users we focussed on function tests, process tests have been mainly driven together with the module consultants. As a tool to manage the test cases we used MS Excel. We had several excel lists, containing the test cases for the different departments. The error list was one combined, consolidated excel list. With macros we managed to move the data from one list to another. Note that we did these tests only for getting the know-how to create and complete the development system afterwards. For every error which came up we answered (and documented) the question what has to be done to ensure that this error will not come up again in the final system. Of course we tried for each error case or program adjustment which came up, to correct it already in our productive environment if possible. Development stop Starting September 30, 2007, we had a development stop in our productive environment. This meant that we did not allow process changes in this environment anymore, just repairs. The testsystem changed its role to a repair system, so that we had a 2 system landscape left. The development system we created new. We copied the productive system to the development system (deleting the old development system), made an upgrade and a unicode migration there, and implemented all the know-how and experiences we have learned during the first test phase. After that we copied out of this system a new user test system. Then the second phase of the user tests started. These tests mainly had been done on two weekends, on these tests we mainly focussed on process tests. Tip for deleting development system: Think about stuff which is normally not transported to the productive system. E.g. we had in an earlier smaller project not thought about the customizing projects and documentation (which was only relevant in the development system and therefore never transported to production) It was also a very good idea to keep a copy of the old development system running, only accessible by the SAP Basis team. The development stop was subdivided into 2 phases: The first phase from October until mid of December we did allow repairs (transports into the productive system) In the second phase from mid of December until the real upgrade we did not. The experience from the development stop phase was very good. We got very few repairs, and as the users knew that no process changes are allowed, they did not come up with a lot of requests. Therefore the developers could focus on the release change. Actually, during this last test upgrade we got a special problem which we didn t get all the other upgrades before. We got corrupted runtime objects. This resulted in a SAP support call, they could provide us with a check and correction program. This error also happened later during the productive upgrade, but as we had the correction programs, this was not a problem anymore. 2008 SAP AG 5

Upgrade of the production system So everything was well prepared for the productive upgrade on Christmas. We had a cutover plan, we had the SPAU transports, the several transports with the corrected programs from the testsystem, we had a detailed plan of the tasks which had to be done in the productive systems after implementing these transports, and so on. Note: The cutover plan was a simple excel document, describing the different actions and who was responsible for the actions. Here an example: The upgrade did run well, but with the export some problems appeared. Actually we could solve these. Afterwards with the import we ve got some bigger issues. This resulted in the fact that we had to implement a new AIX patch and to restart the import. We lost about 12 hours due to this. When the import got to it s end, it was Dec 24 at about 11:00 o clock, we had been very glad that everything did run fine, we knew that in a couple of hours we could go home and have Christmas time. The last step of the import brought up a couple of errors, ORA 904, table not found. Using SQLPLUS we found out that the tables VBAP, VBAK and VBUP have not been available in the new, imported database. After a couple of additional checks, it was clear to us, that compared to the testsystem about 2000 tables have been missed. The tables have not been exported, so already the export programs must have had the error. But the tools, which did the export, have been finished successfully, there was nowhere a log file which indicated that there were tables missing. Therefore it was very clear to us at this time, that we could not use this system. The commands to check for the number of tables: <orasid>sqlplus / as sysdba spool <SID>_T.lst set pagesize 49999 select table_name from dba_tables where owner ='SAPR3' and table_name like 'T%'; spool off spool <SID>_NOT_T.lst select table_name from dba_tables where owner ='SAPR3' and table_name not like 'T%'; spool off This gives you 2 files, containing all table names of the user SAPR3. To find out more about the reason for the error we opened a support call at SAP with the priority very high. We opened it in English, we provided all the logs, which had been available on the machine. The support answered that they cannot see this problem in the log files (which was basically the problem), included a bunch of OSS notes, (which were not applicable for our case), that we should take the newest tools (we refused to change the tools, with which we had made a successful upgrade of the development system) and that we should retry the export (which else). 2008 SAP AG 6

Now we had the decision between the two possibilities: Either go back to the original 4.6C System and retry the upgrade on a later timeframe, or restore the backup of the system, which has been made before the export, and retry the export / import phase. There was a big unknown issue of this second variant. We did not know, what the reason was for the fact that in the export files the 2000 tables were not included. Also for this variant time was running out. We have told the users, that the system will be up and running on Dec 27 at 7:00 am. But we also knew, that we could stop at anytime and that within 2 hours we would have had the old 4.6C system up and running as if nothing had happened. We decided to use this variant. So we restored the system from the time after the upgrade, we had some guys working 24 th, 25 th and 26 th of December, redoing export and import and all the other work which is necessary for the unicode conversion. This included also the import of the SPAU transports and the manual corrections which had to be done after the import. Finally we finished the system in the late evening on the 26 th of December. Afterwards, during the night, we used the backup of the system to create a new up-to-date testsystem for the final system acceptance tests. Meanwhile we also got from the management a prolongation of the time for production start from 7:00 in the morning to 12:00. We needed this time slip as for different reasons we didn t want to start with production right away. We wanted to do the system acceptance tests and the acceptance meeting before start of production. On the 27 th of December at 6:00 am we started worldwide with the system acceptance tests, after 3 hours of testing we got green lights from all the departments. So we could release the system at 10:00 am for production. 2008 SAP AG 7

Summary Finally we successful finished the upgrade and the unicode migration of the productive system. We had a phase where we were on the edge to fail. But we had an excellent team of internal and external people which were able to turn the project into the right direction. Many thanks to all which had been involved. What did we do right (besides all the standard tasks) During the upgrade project we executed a large number of tests, aiming to cover all the functions and processes which are used in our company. This was an excellent work, which has lead to the fact, that we had very few problems after the upgrade, much less than we had expected. We did a couple upgrades before we got to the productive upgrade. This know-how was very good. Overall time planning / Cutover plan was very good We created a Master Guide, containing all the links to the other documents. This included a detailed description of all the tasks, which had to be done immediately after upgrade. This was basically the summary of all the lessons learned from the test systems. Communication to the users with a newsletter was very helpful. Lessons learned We did a couple of upgrades, but no last test upgrade on a comparable environment of the production configuration. We assume that a couple of problems we had, were due to the much faster IO capability of the hardware (compared to the test machines). We had some time periods where one single guy was working, which is basically ok. But, whenever he gets to a problem where he is searching for solution, he should call within 60 minutes his colleagues. Meanwhile we have used our experience, we have finished the upgrade and unicode migration of our second productive system, the HR system moved from 4.7 also to ECC 6.0. 2008 SAP AG 8

Disclaimer and Liability Notice This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document. 2008 SAP AG 9