1. Pre-Upgrade analysis Study the existing landscape & the To-Be Landscape Plan the soft freeze & Hard freeze transport strategy Run the pre-upgrade tool to ide ntify the no. of programs which would be reflecte d for UCCHECK , Upgrade fixes etc. If you do not have an in-house tool, then you may consider developing one. This tool would have details of Obsolete FM's, sea rch for CALL TRANSACTOIN stat ement, obsolete ABAP statements etc. Based on such details the tool will search for all the programs which have such FMs/Statements etc & then it will provide a list of impacted objects Number of cloned objects ( Copy of Standard programs w hich are modified to meet additional requirements) Number of Standard Objects mo dified ( Core Code Modification done by Customer in standard objects ) Number of objects which would be impacted due to updation of Unicode flag Number of BDC p rograms Based on the no. of objects reflected, you can plan the technical team s ize/dura tion etc. This will help during project planning The Functional consult ants can go through the config. settings / level of custom ization etc. This wil l help to identify any specific test scenarios & amount of testing required. Ide ntify the number of interfaces/ 3rd party systems interacting with the SAP sy st em Identify the printer/Barcode scanner etc compatibility with the new system Ba sis consultant may go through the system & identify the need for additional ha r dware/sizing etc. Based on the inputs from Technical/Functional/Basis consultant s you may prepare a draft Project Plan Prepare a landscape document ( AS IS & TO BE ) Also prepare the Technical & Funtional analysis document which can be shar ed wit h the team 2. Project Plan/Resource planning You may have to schedule mee tings with Customer to understand there timelines & project plan. i.e. Overlappi ng of any other projects, hardware availability, Pri ority of any other projects etc In consultation with Customer finalize the timelines for each phase incudin g the number of mock runs etc Finalize the project plan & share the same with Cu stomer Identify the POC from both sides for each phase/task/activity Prepare the resource plan Start the offshore connectivity setup & onboarding of team member s You may share the landscape & other documents with the team members so that th ey get acquainted with the system. 3. SPDD phase During this phase execute the S PDD transaction. The SPDD transaction would retur n All the Standard Data Dictio nary objects viz Data Elements/Domains/ Structures / Tables/ Append structures e tc which have been modified by Customer. The technical team has to decide whethe r they want to RESET TO ORIGINAL or ADOPT MODIFICATION. This two options are ava ilable to fix the objects reflected in SP DD transaction. Here the Technical tea m has to do a Version comparison of the ob ject & analyze whether they require t he custom change. If the custom change is r equired in ECC 6.0, then select ADOP T MODIFICATION else select RESET TO ORIGINAL ( i.e. you do not require the custo m change which was done in the old system. I nstead you want the standard versio n of the object in ECC 6.0 system ). Ensure that you put all the objects in the correct SPDD TR To avoid doing SPDD again in the subsequent systems, you have to release the SPD D TR in a different way Goto SPDD tcode & click on "Select for Transport", place the cursor on the task of the Main TR & then release the Task. Similary place the cursor on the main TR & then click on 'Select for Transport' . This will ensure that the SPDD fixes do

ne in DEV are automatically imported at OS level in the subsequent system. Provi de the TR number to the BASIS team & they would ensure to import the SPDD TR at OS level. SPDD activity has to be done only in 000 client. Ensure that you do n ot do it in any other client. The system would be completely open & it wont ask for access keys to modify stan dard objects. So be careful while fixing SPDD obj ects & ensure that you do not t ouch any other object which is not part of SPDD. 4. SPAU SPAU is performed in the normal client i.e. DEV client. Execute tcode S PAU once BASIS gives a go-ahead You will get a list of affected programs. The pr ograms are standard objects which are modified by customer with some custo m cha nges Analyse the changes & identify whether you need the custom changes (Adopt m odifi cation ) or you want to go ahead without the custom changes ( Reset to Ori ginal ) Ensure that you include all the fixes in a Transport Request - SPAU Prov ide the TR number to BASIS, so that they can import the same TR in subsequen t s ystems SPAU generally reflects Programs/Includes/Screens/FM's/BADI's/Messages/Cl asses e tc 5. UCCHECK Execute tcode UCCHECK This will provide a list of impacted objects. This activity would require 1 to 2 weeks depending on the number of cu stom objects reflected in UCCHECK Ensure that all the fixes are included under a single UCCHECK TR Testing of the fixed objects have to be done by developer & f unctional consultan t Modlogs & documentation to be maintained in the programs w hich are modified/fixe d 6. Custom objects remediation Apart from UCCHECK object s you need to check custom programs which are reflected by the upgrade tool Fix the programs & include it either in UCCHECK TR or another TR which would be impo rted after UCCHECK TR All the custom program fixes have to be tested Ensure that the documentation/commenting/Modlog etc is properly maintained 7. Testing Unit testing to be done as per the Test scripts UAT to be done as per the test script s If Solution Manager is used, then the tcodes have to be executed from SolMan R esults to be documented whereever applicable PDF outputs/Print/Barcode scanning/ Background Jobs/ Workflows / Interfaces etc has to be tested thoroughly 8. Post Upgrade activities There are some activities which cant be included in a Transp ort request. Such ac tivities have to be manually executed in each system after upgrade. These activi ties are called as Post upgrade activities. eg. Regenerati ng ABAP Queries after upgrade - This cant be captured in a TR, hence has to be d one in each system Prepare a list of Post Upgrade activities & update the detail s along with Primar y/Secondary Contact, Task details, System against which you can update whether t he task is completed or pending. This tracker would help to monitor the status Down time has this activity as well. So ensure that you have documented all the post upgrade activity detail so that you spend less amount o f time during PRD po st-upgrade activities. Try to automate whereever possible. 9. Different trackers required Cloned program modification tracker Custom Change s in Standard program moved to Implicit Enhancements UCCHECK tracker

SPDD tracker SPAU tracker Access key request tracker Transport tracker Post Upgr ade activities tracker OSS message tracker Unit Testing/UAT tracker Test script preparation tracker