Skip to Content

The Attack of the Clones: Episode 1


In my experience as an SAP consultant, I have been so lucky to be involved, together with friend of mine Sergio Ferrari, in a lot of upgrade projects and I can say for sure that they have in common the cloned programs.

Since most of the work of the ‘”upgrade men” (aka ASU team) focuses so much on the adjustment of these “uncomfortable” objects, in this blog series I will focus on the feelings and the approach of the clones maintenance during the upgrade projects.

The making of a clone

First of all, we should start by giving the definition of a cloned object in SAP system.

A clone is a customer specific object copied from an SAP standard one and then modified to satisfy a business requirement.


Since SAP always advises its customers to avoid modifications to the SAP standard code, before the introduction of user-exits, the only known way for a SAP developer to satisfy the customer’s requirements without making repairs, was by creating a suitably modified copy of SAP the standard code, the “clone”

The most common reasons for cloning a SAP standard program are:

  1. Copying SAP standard reports in customer name space it’s more easy if compared to modifying SAP standard or implementing a user-exit; copying a program is faster and doesn’t need to fill out tons of documentation to explain the reasons why you need that SSCR registration key or to implement that enhancement
  2. By implementing the modifications in the cloned program, the standard one remains “alive and kicking”

And in my experience I’ve never found a customer’s SAP system without clones; it’s as the clones are part of the “customs and traditions of that place” (system).

Kind of clones and…upgrade issues

Normally we have two kinds of cloned programs:

Full-Cloned Program:


When the developer creates the copy of the standard program, creates also all the underlying sub-objects such as the includes, the menu area, etc. in the customer name range; these types of clones are quite consistent and probably they won’t have syntax errors in the new release

Half-Cloned Program:


Here probably we had a lazy developer, so the standard program was cloned creating in the customer name range only the changed sub-objects.


After the upgrade, for these cloned programs, the risk of error or inconsistencies is very high; the original standard object changes and the cloned programs become often inconsistent.

Another situation is represented by the cloned programs that do not have syntax errors, because the upgraded version of the original program SAP has been enhanced with new features. In this case the clone works like in the old release but doesn’t include the features introduced by the new release that necessarily should be integrated (clone refresh).

Clone refreshing: The two sides of the coin

If you are approaching an upgrade project you must decide between:

  1. Technical upgrade: Focused on the minimization of the risk and retention of the existing functionalities (conservative approach)
  2. Functional upgrade: focused on total cost of ownership, by acting on the complexity of the system (e.g. reduction of modifications and custom applications)
  3. Upgrade with strategic business improvements:  focused on the review of the processes and on the adoption of new strategic applications

Most of the customers choose the technical upgrade, a quick approach to the upgrading, mainly for cost reduction, but also to minimize the impact on the ongoing and future implementation projects.

What is the approach to be taken in case of technical upgrade and adjustment of the clones?

If you apply a conservative approach, that is, adjusting the cloned program only syntactically but without integrating the new features, you inevitably create some differences between the standard programs, which are always young and the cloned ones, which become older, because every upgrade increases the wrinkles (the Two-Face in Batman).

Therefore if you adjust the clones without integrating the new features, after one or several upgrade projects, you might have the standard one enhanced, for example, with beautiful ALV, and the cloned program that is still using the WRITE statement!!!


And your users that are complaining all the time: << I don’t like this program… Upgrades are useless… SAP never improves …>>

To be continued…

In the Episode 2 I will discuss the ways to manage the cloned objects during the upgrade projects.

You must be Logged on to comment or reply to a post.
  • I like so much the blog that explain in simple words and beautiful images such a technical topic.

    I enjoyed also the metaphorical Two-Face concept with the nice left side (fresh new SAP standard version) and the ugly right side (clones created years ago and not refreshed during the upgrade project).

    • Thank you Sergio.

      SCN should know that I became an upgrade expert, because you have taught me a lot of tricks in all the projects we’ve done together

  • Awesome blog Andrea!

    I like the examples, they really give an idea of what are of the “dark sides” of upgrading even to non experts

    keep it up!


    • Thank You Massimo!

      Creating a clone, for the developer (Sith), is like viewing the dark side as good.

      Remember the Jedi, uses “the Force” for knowledge and defense…of their systems 😉



  • Thanks Andrea: it’s never boring to read your blogs. A perfect wedding of clear and deep technical exposition and funny metaphores. Well done, as usual.

  • Hi Andrea,

    I want to ask you a question about clone finder… what does “similar”, “very similar” and “partly similar” mean?

    I’d like to have a glossary about this terms.

    Thanks in advance.