Decommissioning with cclm in solution manager sp12

November 2014
Custom Code Management
Decommissioning
Best Practices with
SAP Solution Manager 7.1 SP12+

Custom Code Management - Decommissioning
Copyright/Trademark
Table of Content
1. CUSTOM CODE MANAGEMENT AT A GLANCE ...................................................................................4
CUSTOM CODE MANAGEMENT APPROACH.........................................................................................................4
THE “GREEN CITY” MODEL................................................................................................................................5
2. DECOMMISSIONING OF CUSTOM CODE ..............................................................................................7
BACKGROUND OF CUSTOM CODE CREATION .....................................................................................................7
IMPACT OF CUSTOM CODE................................................................................................................................7
BENEFIT OF DECOMMISSIONING ........................................................................................................................8
THE PROCESS OF DECOMMISSIONING ...............................................................................................................9
Four phases approach..............................................................................................................................................9
Decommissioning with SAP Solution Manager ......................................................................................................10
Phase 1 - Analyze ....................................................................................................................................12
The Methodology....................................................................................................................................................12
Analysis Phase supported by SAP Solution Manager............................................................................................13
Phase 2 - Identify .....................................................................................................................................15
The Methodology....................................................................................................................................................15
Identification Phase supported by SAP Solution Manager.....................................................................................17
Phase 3 – Monitor and Wait.....................................................................................................................18
The Methodology....................................................................................................................................................18
Monitoring and Waiting Phase supported by SAP Solution Manager ....................................................................20
Phase 4 - Decommission .........................................................................................................................21
The Methodology....................................................................................................................................................21
Decommissioning Phase supported by SAP Solution Manager.............................................................................21
SUMMARY......................................................................................................................................................22
3. GOVERNANCE MODEL .........................................................................................................................22
GOVERNANCE AND STRATEGY ........................................................................................................................22
Governance supported by SAP Solution Manager.................................................................................................23
4. ADDITIONAL INFORMATION.................................................................................................................24

Copyright/Trademark
This document describes possible approaches to decommissioning custom code in a customer’s landscape.
This approach is based on SAP’s experience with different customers in this area.
In the following chapters you will be taken through the most important steps to successfully implement a
decommissioning project, to understand the SAP Solution Manager tools, which are able to support this
project, as well as the most important terms and methodology.

Copyright/Trademark
1. CUSTOM CODE MANAGEMENT AT A GLANCE
Custom Code Management Approach
SAP’s approach for Custom Code Management
SAP supports you achieving your Custom Code Management AIMs by Avoiding, Improving and Minimizing
the custom code elements and individual enhancements in the SAP standard solutions run by your
company. Following the lean principles this AIM will be accomplished by the phases of transparency &
measurement, optimization and control. It provides numerous tailored tools and Best Practices for an
effective holistic Custom Code Management (CCM) from requirement to retirement.
Using these tools you can analyze your specific custom code and modifications with regard to their usage in
your systems and thus get an overview of the totality of customer developments. Based on the results of the
analysis, an identification of the customer developments that are actually used and controlling them better
using the functions provided by SAP Solution Manager can be easily achieved. The objective is to improve
the quality and technical implementation while reducing the quantity and impact of custom code. Also the
important part to avoid modification and moving closer to SAP is described. This supports you achieving
sustainable cost reductions for the operation and maintenance of your SAP system landscape. Leveraging
the innovations to control the gaps and minimizing the existing modifications ensure the value of IT and
increase in business value.

Copyright/Trademark
A holistic view on Custom Code Management: From Requirement to Retirement
Today's IT system landscapes are seldom comprised of homogeneous solutions. Beyond established
software modules, gaps in the landscape are closed ad-hoc or standard business processes enhanced in
line with requirements. Your custom developments are an important element in your system landscape.
Such developments become necessary when your standard software cannot map certain business
processes as desired and there is no specialized, ideally certified, solution on the market. A complex
amalgamation of standard software, enhancements and custom code quickly develops, driven by the need to
respond to changing business requirements in a timely manner. The result is fast implementation of program
code with a less pronounced focus on sustainability and transparency. Important factors such as complete
documentation, the impact of changes on core business processes and maintainability are not taken into
account until planned or unplanned events change the overall system landscape and leave a multitude of
questions regarding custom enhancements unanswered.
Planned, recurring events such as minor and major software updates, or the introduction of new standard
functions or new innovations, can lead to increased testing requirements and significantly higher
implementation costs for your custom developments. Unplanned events such as the need to implement new
legal requirements, the use of new technology or the need to adapt interfaces for external reasons also
frequently present unexpected challenges with regard to custom enhancements. SAP proactively supports
you in the targeted handling of all of these aspects.
The “Green City” model
In light of the known characteristics (number, quality, type of implementation, degree of documentation, and
so on) of custom enhancements and custom code, four primary dimensions were defined that can be
measured and evaluated. The four dimensions are quantity, quality, rating of the impact on core business
processes, and classification of the technical implementation in relation to the SAP standard. The model also
considers the aspects of management and software lifecycle.

Copyright/Trademark
The visualization of custom enhancements and custom code with these metrics corresponds to the abstract
representation of a city with buildings of various heights, colors and locations within the city. Every city
reflects an individual system within your system landscape.
SAP’s methodology for Custom Code Management: “The Green City Model”
Dimensions of the city model
Staying with this metaphor, as the forward-looking mayor of your own city comprised of multiple custom
enhancements and custom code, you have a number of ways of beautifying or redeveloping the city. To
keep this “beautification of the city” from devolving into a costly and arbitrary process, in the following we will
present the individual dimensions, tools and services with which SAP supports you in your pursuit of a well-
run, cost-effective and forward-looking system landscape.
Quantity
In the quantity dimension, customer-specific objects are recorded according to their object characteristics
and categorized according to their technical implementation.
Quality
The quality of program code is an often neglected, but highly important factor in the development of custom
adjustments. In this dimension, SAP has made it possible to measure quality in a comparable way and
thereby maintain quality standards.
Criticality and impact on core business processes
Your core business processes must be stable, ensure maximum availability and correctly map your
functional requirements at all times. SAP supports you in the analysis of the most frequently used system
processes and shows you which of your frequently used core business processes are impacted by
modifications or enhancements. You receive important information that is helpful for planning software
updates or optimization.
Technical severity
SAP NetWeaver provides a multitude of enhancement options that in some cases go far beyond classical
Customizing, enabling you to enhance and adapt standard processes to meet your requirements. Beyond
the ability to implement and define implicit and explicit extension points (BAdIs, user exits, enhancement
spots), you have the freedom to change SAP standard code through logged and unlogged modifications.
Each of these system modifications has specific strengths and weaknesses, which should be evaluated
based on maintainability, risk and complexity.

Copyright/Trademark
2. DECOMMISSIONING OF CUSTOM CODE
The majority of the created custom code remains in the system, although it might not be used currently or
will not be used in the future. In order to get rid of unused or obsolete custom code a well-defined
decommissioning strategy must be in place.
To define a decommissioning strategy it is absolutely necessary to have transparency on the existing custom
code objects, especially on the usage of each object in your system landscape based on an efficient custom
code management.
The following chapters will explain how to set-up an overall and holistic decommissioning strategy and how
this strategy will be supported by the capabilities of Custom Code Lifecycle Management in SAP Solution
Manger.
Background of Custom Code Creation
Many SAP customers modify or enhance their SAP standard software. For example, they may create
company-specific reports or custom (externally or internally developed) add-ons. Using custom code and
modifications enables companies to adapt business processes to market requirements. The result of this
natural development is a multitude of customer objects and modified SAP standard objects in circulation.
However, requirements change so quickly that many customer objects and changes to SAP standard objects
quickly become obsolete. Experience shows that after just a few years, a third of custom code is either no
longer in use or has been modified, and not only due to fast-changing requirements but also because new
versions of the SAP standard software contain objects that render custom code useless. This can lead to
unnecessarily high maintenance costs, which in turn cause high operating costs.
For customers, it can be difficult to keep up with the pace of modifications to the standard system and
produce custom code. Numerous changes and customer objects also raise the cost of upgrades and
importing Support Packages. Before a system can be upgraded to a newer SAP version or a Support
Package can be imported, all custom code must be checked and manually adjusted. Then all objects have to
be checked one-by-one to ensure that they do not cause problems in the new context.
Many of our customers keep to the statement “Never change a running system”. On the one hand side this
might be correct, but unused or obsolete custom code objects add to the maintenance cost of a system by
possibly becoming affected by system change events – such as upgrades or major business-driven events.
In addition unused objects can increase the security exposure of a system by becoming unmanaged and
unmonitored portals for malicious attacks.
Impact of Custom Code
A custom code object costs more than any standard software object”

Copyright/Trademark
Unused custom code has a big impact on your system, includes high risks and adds significantly to your bill,
with:
• Maintenance and adjustment effort during change events.
(E.g. System upgrade, new EhP, system merge).
• Maintenance effort and cost during operation
(E.g. bug fixing, due to dependency of coding -> coupling complexity of custom code with standard
code)
• Security and destabilization risk of execution (no control) -> Missing authorization concepts
• Testing effort due to unknown usage behavior -> Initial test plans may not covering business reality
• Data consistency risk when executing unknown and old code.
(E.g. legacy migration reports, excel upload reports)
• Training effort to build and keep up to date development and support skills -> Handover of
development responsibility and corresponding training activities
• Increasing the complexity and building roadblocks on the way to a more simplified landscape or
new technology landscape. E.g. Cloud, HANA).
• Creation of unnecessary documentation
• Inaccurate forecast and estimation of future development activities based on uncertainty or
incorrectness
• Legal aspects to provide audit ability and certifications for processes (e.g. PCI DSS, Payment Card
Industry Data Security Standard)
Reality of custom code impact: Experience from typical customer systems
Our recommendation is not to stay with “Don’t touch a running system”, but instead follow the lean
management of CC and “Don’t invest in ‘waste’”.
Benefit of Decommissioning
Looking at the impact described in the chapter above it is quite obvious what will be the benefit of
decommissioning. The main benefit will be to decrease the overall TCO for managing custom code. A simple
calculation is to multiply the days/hours, which are need in one year to maintain a single custom code object
with the number of obsolete custom code objects.
Please be aware that this number will in most cases not appear on any bill or receipt. Instead you will free up
recourses (time, persons) from development to focus on other tasks or projects. You can prove the success
and the value of decommissioning by checking the work that was done for example during one year.
Example for benefits after decommissioning:
• Increased average number of project per year in the IT department
• Decreased number of days for implementing new release
• Decreased number of days to prepare upgrade of a system

Copyright/Trademark
Main benefits for reduced custom code objects
• Less maintenance and adjustment efforts for custom code
• Less security or destabilization risk
• Less data consistency risk
• Less testing effort
• Less complexity
If you can provide transparency on usage there are also a lot of benefits, which should be taken into account
when looking not only on the unused objects, but also looking on the used objects. These benefits can be
included in the business case for decommissioning, especially to convince the business.
Main benefits for transparency on used objects:
• Focus on highly used objects for maintenance -> higher system stabilization
• Focus on highly used objects for testing -> higher test accuracy
• Check test execution –> lower risk for insufficient testing
• Check unusual process usage -> higher template compliance
The Process of Decommissioning
Four phases approach
The goal of decommissioning is to identify the custom code objects, which are possible and desirable to
eliminate from the system.
The four main characteristics of an object to be identified are:
1. Not used during a defined time period
2. Similar or even identical to an existing SAP object
3. Created long time ago but not active in any productive system
4. Obsolete because of existing standard functionality
For each characteristic the framework has to be defined:
For unused objects:
What does it mean not used? – Ex.: Zero usage or used less than a certain threshold (accidental usage)?
What is the right analysis period to check usage? – Ex.: At least 12 months to include closing activities, e.g.
cover year-end closing?
For similar objects:
What is the degree of similarity for the objects, which you should look at? – Ex.: Only 100% clones will be
candidates for decommissioning, or shall all clones with a similarity greater than 90 % be considered?
For not deployed objects:
What does it mean long time ago? – Ex.: Only objects which are created two or more years ago?
For obsolete objects:
Is the standard functionality already implemented or at least available?
A successful decommissioning strategy is divided into four main phases:
1. Analyze your custom code and get transparency
2. Identify custom code objects for decommissioning
3. Monitor identified custom code for a specific timeframe, to ensure that the object is not executed
4. Decommission the objects

Copyright/Trademark
The four phases for efficient and effective decommissioning
Decommissioning with SAP Solution Manager
Prerequisites
Custom Code Lifecycle Management (CCLM) is designed to support the decommissioning process with the
decommissioning cockpit. The decommissioning cockpit is available in SAP Solution Manager 7.1 SP12.
CCLM has to be set-up and running for the complete system landscape (DEV-QA-PROD) in which the
decommissioning process shall be implemented.
As an additional prerequisite data from the workload statistics must be available and the usage and
procedure logging (UPL) must be running for all managed systems where usage data will be considered.
Custom Code Lifecycle Management
Start CCLM with transaction “CCLM” and you will directly see an overview of the current custom code
situation represented by the City Model, which is displayed in the middle of the UI.
The City Model gives first information about overall number of Custom Code Objects in all systems and for
each analyzed system. In addition it provides information of the usage of Custom Code Objects overall and
for each analyzed system.
The City Model of the selected systems, presented in CCLM workcenter
From this overview screen it is possible to directly jump into the decommissioning cockpit, to start the
decommissioning process.
Supported object types for decommissioning
CCLM will not support all Custom Code Objects for an automated decommissioning approach within the
decommissioning cockpit. For Custom Code Objects and Custom Code Duplicates for example the object
type for tables and webdynpros are not supported. CCLM will also not support enhancements
(SAPSeverityLevel = 1) and modifications (SAPSeverityLevel = 3) in the decommissioning cockpit. For all

Copyright/Trademark
other object types please check always carefully by yourself if they can be decommissioned, as UPL cannot
provide usage data for all object types.
It is recommended to start small with transactions and reports first. It might also be beneficial to focus in the
beginning on just one development class.
Once the process is established, other object types or development classes can follow this approach.
All supported objects in CCLM are marked with a specific attribute “RetirementPossible=X” in CCLM.
Lifecycle status
To control the lifecycle of a custom code object including the decommissioning process a continuous
lifecycle is provided for all objects in CCLM:
1. Status “00” = New Object: Will be set if an object will be found for the first time in a lead system
2. Status “10” = Under development (Not available yet)
3. Status “20” = Active in Non-Production: (Not available yet)
4. Status “40” = Active in Production: Active in at least one systems which is not a lead system
5. Status “60” = Recommended for Decommissioning: If an object is part of a result of a
decommissioning analysis (result of phase 1)
6. Status “70” = Identified and Waiting: If an object was identified for decommissioning (result of phase
2, or transferred into phase 3)
7. Status “80” = Phasing out: Object is now ready for decommissioning
8. Status “85” = Object was backed up
9. Status “90” = Deleting: Object is listed in deletion transport
10. Status “99” = Deleted: Object is deleted in all systems. Deletion flag will be set as well.
Status 00 and 40 will be set automatically when object was found in system.
Status 60 will be set automatically by analysis run out of decommissioning cockpit if object is part of the
result list.
Status 70 and 80 must be maintained manually during the decommissioning process.
Status 85 will be set automatically when backup transport was created out of CCLM decommissioning
process.
Status 90 will be set automatically when deletion transport was created out of CCLM decommissioning
process. This is only possible for transactions and reports. For all other objects the deletion transport has to
be created manually by the user and after that the status has to be set manually to 90 by the user.
Status 99 will be set automatically if the collector jobs for CCLM realize that this objects does not exist in any
analyzed system, which is monitored by CCLM.
The main user interface is the decommissioning cockpit in CCLM, which presents an overview on the
number of objects in the different lifecycle status.

Copyright/Trademark
Decommissioning Cockpit in CCLM
The decommissioning cockpit provides also additional information about the number of decommissioning
analysis that are currently running and about the current custom code usage for all systems and for the
different SAP Severity Levels.
The following chapters describe the different phase.
In the first part of each chapter the methodology will be described without any specific link to any tool and in
the second part it will be described how CCLM in SAP Solution Manager 7.1 SP12+ can support this phase.
Phase 1 - Analyze
The Methodology
In order to start your decommissioning project it is absolutely necessary to get transparency on your current
custom code situation.
To identify the right objects it is necessary to get at least answers to the following questions:
• How many custom code objects exist in the different systems?
• Which custom code objects are not used and which are used in the different systems?
• How many clones are in the system and how many objects are similar to a SAP object?
• Which objects only exist in your development system, but not in any of your productive systems?
• Which objects are obsolete because of existing standard functionality?
In order to get these answers several analyses have to be executed across the whole system landscape.
The information gathered from the different system shall be stored and linked to the different custom code
objects.
SAP’s recommendation is to include period closing activity in the analysis, especially with respect to a
significant usage analysis.

Copyright/Trademark
Analysis Phase supported by SAP Solution Manager
CCLM is supporting the following standard use cases to identify objects, which are candidates for
decommissioning:
• Unused objects in specific systems
• Objects not active in specific systems
• Objects similar to SAP objects (similarity percentage can be selected)
• Objects created prior to a specific date
At the moment CCLM does not support to detect objects, which are obsolete because of existing standard
functionality.
In addition to these standard use cases the selection of objects can be defined independently from these use
cases by filtering objects via existing attributes of CCLM.
Decommissioning cockpit:
The complete decommissioning process will be started and controlled via the decommissioning cockpit.
Entering the decommissioning cockpit will present an overview on the current situation.
From the overview of the number of existing decommissioning analysis a list can be selected or a new
analysis can be initiated.
Creation of decommissioning analysis:
The decommissioning process is treated as a kind of a specific project. Creating a new analysis will start the
decommissioning process and with that the process will enter the analysis phase.
For creating a new analysis some generic settings have to be defined like name and description. To select
the objects the systems and the selection criteria has to be entered as well.

Copyright/Trademark
Create new analysis
Saving the analysis will start the analysis run. The Lifecycle Status of all selected objects in an analysis run
will automatically set to 60.
Display result list:
The object list of the decommissioning analysis is shown in an additional screen. All available
decommissioning analysis is shown in a list. In order to work with the selected objects of the analysis the
analysis has to be selected first and then it is possible to show the object list at the bottom of the screen.

Copyright/Trademark
Work with objects in analysis list
For every object in the result list different information can be collected and maintained in CCLM. It is also
possible to create decommissioning packages and assign owners to work on these packages.
End of analysis phase:
At the end the analysis phase objects can be rejected from the analysis or transferred into the next phase of
the decommissioning process. Transferring into the next phase means that the status of these objects will be
set to “Identified and Waiting” and these objects are now subject of further investigation.
Reject objects:
Rejecting an object means that this object will be kept and will be taken out of this analysis. The status of this
object will be set back to the status before. In most cases this will be status 40.
Phase 2 - Identify
The Methodology
Based on the analysis done in phase 1 there are four main criteria for an object to be identified for
decommissioning.
1. Objects which are not used
2. Objects which are a similar or even identical to an SAP object
3. Objects which are not in production system, but exist a long time already in development
4. Objects which are obsolete and can be replaced by SAP standard functionality
If at least one of the above mentioned criteria is true for an object it is identified as a candidate for
decommissioning.

Copyright/Trademark
When implementing a decommissioning strategy SAP recommends for all identified objects starting small
with a proof of concept and gaining experience before applying the strategy to all identified custom code
objects. Starting small in this case means just select some objects e.g. the objects of a dedicated
development class and focus within this development class on transactions and executable programs first.
Identifying an object for decommissioning does not mean at the end that this object will be eliminated from
the system. Before this decision can be made some additional information for each marked object needs to
be collected. The information needed in this step may be different in each customer situation.
Example for needed additional information for each object:
• Comment (text)
• Object type
• Activated in system(s)
• Application component
• Development class
• Origin (business requirement, legal requirement, country specifics,)
• Author
• Business owner/responsible
• Type of object (correction, support program, new application)
• Creation date
• Date of last change
• Criteria for deletion (unused, clone, not in production)
Some of this information can be collected automatically; some of them can only be collected manually. All
detected custom code objects should be stored in a central result list together with all relevant information.
This is not a comprehensive list as this may vary in each specific customer situation. The purpose of this
information is to provide all aspects needed to come to a decision to decommission the object.
To automate the process of identifying objects for decommissioning it might be possible to detect rules or
patterns, which help to make a decision.
The following rules and patterns are examples for objects, which are candidates for decommissioning:
• Reports not tied to a role
• Table maintenance programs not tied to a role
• Objects with syntax errors
• Executable programs without transaction and not assigned to a batch process
The business experts and development should do the decision for deletion jointly. Both parties should
confirm the decision.
Remark: The decision for transaction and assigned program should be taken together.
If the decision was taken it should be recorded as a decommissioning status for each object together with
the expert who made the decision and a short reason for the decision.
Examples for possible decommissioning status and reason:
• Open -> to be categorized
• Open -> pending decision
• Keep -> configuration transaction
• Keep -> country specific
• Keep -> correction program
• Keep -> still needed in specific cases
• Wait-> clone can be replaced by SAP object

Copyright/Trademark
• Wait -> technical obsolete
• Wait -> functional obsolete
• Wait -> alternative available
• Wait -> back to SAP standard possible
• Decom -> clone, which can be replaced by SAP object
• Decom -> technical obsolete
• Decom -> functional obsolete
• Decom -> alternative available
• Decom -> back to SAP standard possible
This is also not a comprehensive list but it shows how the process should be set-up.
Identification Phase supported by SAP Solution Manager
Work with object list:
In the identification phase additional information of the objects will be collected. This information shall be
stored for each object of the analysis run in the single source of truth, which is CCLM.
Therefore all maintainable attributes are maintainable in the object list. All attributes and their values can be
displayed for each object directly from the object list
Here are some examples of maintainable attributes:
• Retirement Comment
• Retirement Package
• Retirement Package Owner
• Origin (e.g. business requirement, legal requirement, country specifics, ...)
• Business owner
• Object Classification (e.g. correction, support program, new application, …)
• Original Source System
During the identification phase an object can still be rejected. The behavior is the same as in the analysis
phase.
In order to get the respective information it is possible to notify the package owner via e-mail to take care of
collecting all needed information.
It is possible to download the object list to Excel for example to send this Excel to the retirement package
owner.

Copyright/Trademark
Show attributes in object list
End of identification phase:
If all necessary information for an object is collected a final decision has to be made if this object is now
ready for decommissioning or if it shall be rejected. If it is ready for decommissioning the lifecycle status can
remain “Identified and Waiting” or can be set to “Phasing Out”.
Phase 3 – Monitor and Wait
The Methodology
All objects, which are now detected for decommissioning, will now be transitioned into the monitoring status.
The monitoring or waiting period has to be defined upfront.
SAP’s recommendation is to wait at least 3 months, but this is depending on the selected analysis period. If
a long analysis period is defined you might go for a short waiting period. At least either the analysis or the
waiting period should cover year-end closing activities.
During the monitoring and waiting phase it should be checked constantly if the situations for the flagged
objects have not been changed. This means:
• The object is still unused, if this was the main reason
• The object is still a 100% clone, if this was the main reason
• The object is still not in the productive system, if this was the main reason
• The object is no longer used, because it is replaced by standard functionality
For all flagged objects it is recommended to track the usage or better block the usage and if possible track
the users as well.

Copyright/Trademark
Possible approaches to track the usage:
1. Rename the candidates marked for decommissioning (e.g. xx_old)
Example: “Report_1” to “Report_1_old”
This is easy to implement with less effort. If someone knows that the report is still available with a new name
it will still be possible to execute the report. This might lead to a misinterpretation of the usage during the
waiting phase.
This is not the recommended approach as each for each object a new custom code object has to be created.
2. Set message at the start of the program prevent execution and trigger the exception process
Example:
Code-Example for sending a message
This is a little bit more effort to implement this in the system, but it helps to control the usage of these
programs during the waiting phase.
There is an impact for the business, as all users will get a pop-up, explaining the reason why this report is
blocked. This impact may lead to some irritation of the business user.

Copyright/Trademark
3. Logging and alerting of candidates without impact for the business
Example: Create a z-table to collect usage information during the waiting phase.
Insert/Update table statements at the start of the program with call date and time
Example for logging table
This is the possibility, which needs the most effort to implement, but without any business impact. This
solution is designed to monitor the usage of each object and the respective user.
Monitoring and Waiting Phase supported by SAP Solution Manager
CCLM is supporting the monitoring of usage of an object. As soon as an object is part of an analysis run the
usage of this object will be monitored until it will be rejected or finally deleted. If an object is used during the
decommissioning process it will be marked with a red alert.
The duration of the monitoring and waiting phase is defined in the settings of each analysis run. If necessary
the waiting time can be changed individually for each object.
End of monitoring and waiting phase:
If all necessary information for an object is collected and the waiting phase ended, a final decision has to be
made if this object is now ready for decommissioning or if it shall be rejected. If it is ready for
decommissioning the lifecycle status should be set to “Phasing Out”.
Setting Lifecycle Status

Copyright/Trademark
Phase 4 - Decommission
The Methodology
Although the decision was taken the objects should not be just deleted, there should be always a back-up
which allows to get the objects back into the system.
SAP’s recommendation is to follow the steps described below:
1. Define back up
2. Create back up transport
3. Link back up transport number to the object in the deletion list
It is recommended not to create one big transport, but group the objects in several logical groups (e.g.
objects from the same development class, objects belonging to the same application component). For each
logical group a different transport should be created, but each transport should not include more than 50
objects.
Decommissioning Phase supported by SAP Solution Manager
For all objects with lifecycle status “Phased Out” the deletion can now be initiated.
Work with object list
All objects with status “Phased Out” can now be grouped to start the deletion part. The number of elements
in one group is limited to the maximum number of objects in a transport.
If a back-up is mandatory a back-up transport of the grouped objects can be created automatically. The
number of the transport will be recorded in CCLM for each object. If the transport was created successfully
the status will change to “Backed Up”. If the transport was not created successfully a specific message will
be send to the user. From that point in time no change of the group will be possible. If there are changes
necessary the group has to be canceled completely and the number of the transport will be deleted from
CCLM.
For groups with objects of status “Backed Up” (or “Phased Out” if a back-up is not mandatory) a deletion
transport can now be generated. A deletion transport can be created automatically from CCLM for
transactions and programs for all other object the deletion transport has to be created manually by the user.
The number of the deletion transport will be recorded in CCLM, if it is started from decommissioning cockpit.
After creation of the deletion transport the status will be set to “Deleting”, automatically only if created from
decommissioning cockpit or manually if created manually.
Deletion of objects:
After the deletion transport was transported into the complete landscape and the deletion was executed in all
systems the object will still remain in CCLM.
After a retention period of 10 days all references to a system of the objects will show a deletion date” and
finally the deletion flag of the object itself will be set to “deleted” and the lifecycle status will be set to “99” in
CCLM for the respective object. The retention period can be changed in the CCLM customizing table
AGS_CC_CUSTOM.
Retrieving of objects:
If objects will be retrieved then as soon as they will be collected and found again in the system landscape the
status for these objects will be set to “00” again and the deletion flag will be set back to “initial”.

Copyright/Trademark
End of decommissioning phase:
At the end of the decommissioning process the analysis shall be set to complete. All objects in this project
which are not deleted (status “99”), should be rejected, so only the objects with status “99” should remain in
this project.
Summary
Every decommissioning project should be based on the four main phases as described above.
Structure of a decommissioning process
In each phase different activities have to be performed. These activities are supported by Custom Code
Lifecycle Management in SAP Solution Manager 7.1 SP12. In order to get the right information to
decommission custom code objects the usage information for every object is essential. Therefore the
activation of the Usage and Procedure Logging (UPL) from SAP is a prerequisite for the support by the
capabilities of SAP Solution Manager.
It is recommended to start small with transactions and reports to get experience in the decommissioning
process. Once this process is established it can be expanded to other object types.
3. GOVERNANCE MODEL
Governance and Strategy
Every decommissioning project needs clear governance and a clear strategy.
Effective Custom Code Management governance ensures the quality of custom code functionalities and
controls the growth and usage of custom code during the whole lifecycle. The purpose is to review and
analyze the setup of existing Custom Code Management processes and to optimize Custom Code
Management governance according the latest SAP Best Practices. Before the development organization can
start to design and realize custom code for its specific needs, functional gaps or competitive advantages in
how the customer conducts his business, it is important to establish, that these development activities follow
certain rules or standards.

Copyright/Trademark
Decommissioning is not a one-time project support by different tools; it must be embedded in a complete
governance project for Custom Code Management. This is only possible if all supporting tools are integrated
in this governance model as well. If this is not the case it will be very difficult to keep the custom code city
“green” and “clean”.
Integrated custom code tools should be embedded in a governance model
Governance supported by SAP Solution Manager
To support the governance a project statistics is provided.
The project statistics shows the number of objects, which have been analyzed in the beginning.
In addition it will collect the following numbers:
• Number of rejected objects
• Number of objects in different Lifecycle Status 60, 70, 80, 85, 90, 99
For each decommissioning analysis a target of how many object are targeted to be deleted with this analysis
must be defined.
The target achievement (number and percentage) and the % of target achievement will be displayed.
Objects statistics of a decommissioning analysis

Copyright/Trademark
In addition it is possible to set-up the interactive continuous improvement (ICI) dashboards to define overall
targets for the number of custom code objects. These dashboards allow to control and visualize the
achievements of the implemented decommissioning strategy.
ICI dashboards
These dashboards can be accessed via the Custom Code Management Workcenter.
4. ADDITIONAL INFORMATION
Additional information on efficient Custom Code Management can be found at:
http://scn.sap.com/community/abap/custom-code-management
http://scn.sap.com/docs/DOC-54888
Additional Information on working with Usage and Procedure Logging can be found at:
http://scn.sap.com/docs/DOC-54826
https://scn.sap.com/docs/DOC-59249
If you need more information on the features of CCLM in Solution Manager 7.1 SP12 please have a look at:
https://scn.sap.com/docs/DOC-59247

© 2014 SAP SE. All rights reserved.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP
BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP
products and services mentioned herein as well as their respective
logos are trademarks or registered trademarks of SAP SE in Germany
and other countries.
Business Objects and the Business Objects logo, BusinessObjects,
Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and
other Business Objects products and services mentioned herein as
well as their respective logos are trademarks or registered trademarks
of Business Objects Software Ltd. Business Objects is an SAP
company.
Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL
Anywhere, and other Sybase products and services mentioned herein
as well as their respective logos are trademarks or registered
trademarks of Sybase Inc. Sybase is an SAP company.
Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are
registered trademarks of Crossgate AG in Germany and other
countries. Crossgate is an SAP company.
All other product and service names mentioned are the trademarks of
their respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials
are provided by SAP SE and its affiliated companies ("SAP Group")
for informational purposes only, without representation or warranty of
any kind, and SAP Group shall not be liable for errors or omissions
with respect to the materials. The only warranties for SAP Group
products and services are those that are set forth in the express
warranty statements accompanying such products and services, if
any. Nothing herein should be construed as constituting an additional
warranty.
www.sap.com

Decommissioning with cclm in solution manager sp12

More Related Content

What's hot

Similar to Decommissioning with cclm in solution manager sp12

Recently uploaded

Decommissioning with cclm in solution manager sp12