... and we are also using the upgrade as general system cleanup. Here's how we've prepared the upgrade - early stages: An upgrade is when all the system's coding is checked and all functionality is to be retested. This is a list of check-points or points of attention that we've composed to get the whole upgrade (and it's impact) on our planning boards (in the form of an upgrade script - next article). There is (some) relevance in the sequence:
Preparing for the upgrade
- First of all - do not expect an upgrade to fix problems that are currently around. If there are problems with the current system - they need to be addressed (solved or at least noted) before doing the upgrade.
- Size the system - Count the number of programs, funtion modules and transactions. Also check out the article about line counting - counting the number of ABAP lines in a system.
- Find the programs that do not need to be upgraded -
- Programs that should have been removed but haven't yet
- Programs no longer in use
- Programs that will no longer be useful after the upgrade
- Conversion programs and temporary fix programs
- Check the SAP modifications that were done on your system - potentially they all need to be redone...
- Find brothers and sisters: programs that have been copied when changes were done - just to make sure that the old version was still available. Try to merge the functionality of brothers and sisters into one.
- Find the standard SAP copies - programs that have been copied from standard SAP and altered somewhat. These need extra attention when an upgrade is done. Look out for programs that have standard SAP includes as well as Z* (or Y*) includes. This step does not apply to programs alone - function modules end up being copied as well - effectively changing standard SAP functionality. An upgrade is where these are likely to be flushed out..
- Check naming conventions and try to find out whether "upgrade risk" can be determined from naming conventions:
- Conventions for reports (low risk) versus update reports (medium risk)
- Conventions for reports using Batch Input Maps (medium risk)
- Conventions for shell reports (often using Batch Input)
- Check new technologies and how old ones can be replaced:
- Batch input maps to perform updates can be replaced by BAPI technology ?
- Manual interfacing (upload/download from and to flat files) can be processed as Idocs ?
- SapScript can be moved to Smartforms ?
- Look-alike reports can be merged together ?
- ...
- For the reports that have not been named according to conventions: check whether naming conventions are still up to date (update conventions if necessary) and start renaming the respective reports.
- Reduce risk of upgrade problems by checking all programs - there should be no errors on the program check (also part of the overhaul check)
- Check data integrity of all programs - where necessary perform an overhaul on the programs.
- Check the remaining overhaul steps (including authorization and locking, hard coding, etc.) and perform overhauls where necessary.
- Agree on test scenario's and test the old system to gather the results before the actual upgrade is started.
The actual upgrade
It's not hard to spend a lot of time preparing the upgrade, but there is always work to be done after installing the new version as well. Every developer has been told that "It used to work fine and now it's not working anymore" - very difficult to work on from a developers point of view - because it is often very difficult to check/test the old situation. An upgrade is where the above scentence will be repeated many many times (allbeit it slightly twisted forms). Here's something that is very easy to underestimate: the renewed system should be accepted when the all test scenario's checked ok. These test scenario's have been run (executed/performed/tested) on the old system, and results have been logged. Everybody needs to understand beforehand that adding new test scenario's after the upgrade leads to unplanned work - which potentially has nothing to do with upgrading. When it does come to finding out new things - the priority should be to finish actual upgrade steps first.
- Run archiving jobs to remove old data from the system
- Run test scenario's and log the results
- Perform the actual upgrade
- Run test scenario's and log the results
- Resolve any problems on the above test scenario's (only when faulty of course)
Data conversions
When a system is upgraded, the table contents of any table that happens to be on board of the system are automatically converted and will become available in the new system. As SAP may have changed their data structures, these table structures get upgraded as well.
For custom tables, there is no conversion needed (as SAP will never introduce a new field on a custom build table). However - you still may want to revisit the tables in your system.
- Have indexes been created which are no longer needed ?
- Any tables "no longer used" ?
- What about data elements and domains - everything according to naming conventions ?
- All (data elements and domains) still in use ?
- Basic data modeling rules have been applied correctly ?
- All amounts have a unit of measure and values come with a currency ?
You may even consider moving your address data (name, street, postcode and city) to SAP's central address management.
A few pointers to remember: if an upgrade is also used to perform an operation "cleansweep" - you will first have realize what state the current system is in. Alternatively a "technical upgrade" can be done, for which the whole testing circus needs to be done as well. So what is the state of the current system ? How about data integrity ? Have you tried the "spagetti test" on some of the developments (see the previous issue ?)