Skip to Content

Understanding Change Projects

This blog series is designed to help in understanding the concept and usage of change projects in business configuration. The idea of this series is to explain the features of the change projects, and some do’s and dont’s while working on it. This blog series will contain following articles:

  1. Introduction – Concept and Usage
  2. Change Project Types – Remote or Local
  3. Change Project – Merge and Sync with Production
  4. Change Project Life Cycle
  5. Change Project FAQ Page

Introduction – Concept and Usage

Change project is a mechanism to bring in new business configuration (scoping) changes into a production system once that production system is set to live. How should this “live” be inferred? To explain this, I need to explain the life cycle of the first implementation project in a customer production system.

When a customer requests a new production system, that system comes with an implementation project with title “First Implementation”. This implementation project can be seen in Business Configuration work center, Implementation Projects work center view.

In case the above production system is requested from a test system with solution profile copy option, then the implementation project in the production system will be a copy of the same name project from the test system. In case, this production system is a fresh request, then the implementation project will be a pre-configured project delivered from SAP. You can get more information on different kinds of possible tenant request scenarios here.

Once you have the above implementation project in your production system, you can continue with your business configuration setup. You can do scoping as well as fine tuning related changes. There are various milestones in an implementation project. These milestones are reviewed at different project stages. The last and final milestone of this “First Implementation” project is “Confirm Go Live”. This milestone  is only available in a customer production system but not in a test system. This milestone is set to confirmed once the customer solution is tested and accepted by business users community. Once this milestone is set, the implementation project status changes to “Live”.

Once an implementation project is set to live in a customer production system, this brings in certain constraints on carrying out changes in business configuration. A customer should be able to carry out maintenance of most of the fine tuning activities, i.e. maintaining a code list. However, a user will not be able to carry out any changes with respect to scoping in the implementation project. This restriction is set to minimize risk at the production scenarios at the customer. Bringing in new changes, without proper testing etc., will put the current production processes at risk.

Now, I come to the first sentence of my blog article, which states that change project is a mechanism to bring in business configuration (scoping) changes into a customer production system.

How do I create a change project? Once the first implementation project is set to live, the “New” button on the list in the Implementation Projects work center view will be enabled. This button is used to create a new implementation project, which is also called a change project to infer that this project is created to bring in some changes.

What happens when a user creates a new change project? This results in the creation of a new implementation project which in fact is a copy of the existing live implementation project. This way, a user starts to carry out changes on top of his existing live solution scope.


Will the changes I am doing in a change project impact my production system? The answer is no. The change project is not associated with the runtime of the production system. Or in layman terms, the processes in a production system work with the live implementation project. These processes do not access a change project at any point of time. This way, we are able to separate out the project which should be used to run processes and a project which can be used to carry out new changes. Once a change project is created, there is no automatic synchronization between this change project and the live project. This means, in case you make some fine tuning changes in your live project, those changes will not automatically come to the existing change project.

Can I have more than one change project in my production system? The answer is yes, however not recommended from SAP. Technically, you can have multiple change projects in a production system. Whenever you create a new change project, it copies the live implementation project and creates a new implementation project as per your given description. A valid use case of multiple change projects could be that a customer wants to carry out two separate line of changes and wants to keep these as different projects.


But you can already observe here that if you have multiple change projects then there would be issues with syncing these different change projects at any given time. Let’s try to understand the scenario from above picture. In the above picture, we see two change projects, CP1 & CP2. First CP1 was created, and after some time CP2 was created. As you can see, both these change projects started with the copy of the same First Implementation. Now, there can be chances that the state of the First Implementation at the time of creation of these two change projects was not the same. A user might have done some changes (fine tuning) in between the creation of CP1 & CP2.

At some point of time in future, a change project needs to be merged with the live project. And at the time of merge, user will run into conflicts in case a change project and live project is not in sync. Therefore, if you have multiple change projects, keeping those in sync would be a time consuming task.

Of course there are remedies to overcome this, however the conflict resolution among different change projects is not that easy. We will learn about syncing change project with live project in a latter article.

The next article in this blog series deals with the types of change projects and how you can perform testing for the changes carried out in the change projects.

You must be Logged on to comment or reply to a post.
  • Hi Saurabh,

    With my customer we are at the stage where we need to consider multiple change projects because of the start of different projects with different timelines, scoping and configuration. In your blog I read of the difficulties of keeping the projects in sync. But you also speak of remedies to solve the conflict issue. Would it be possible to already receive information on this, since we need to make decisions on very short term. That would really help me in my advise to the customer. Thx!

    • Hi Bianca,

      Technically, you may have multiple change projects at a time. However what needs to be understood here is how you will be doing testing of these multiple change projects simultaneously?

      Testing a change project is only possible when you transfer it to another system (i.e. test system). You cannot test a change project in a production system. We will come to know more on the testing part in next articles.

      In your case, if you open multiple change projects, you will need that many number of test systems to carry out testing on each individual change project.

      About the remedies, you asked in your question, there is a possibility of updating a change project from the active implementation project of the production system. This way a change project gets synced with the production system. However, if there are conflicts during this sync, resolving those could be time consuming.

      My suggestion would be to avoid multiple change projects until there is no other possibility to realize a customer's demand.

      • Hi Saurabh,

        Thanks for your quick answer! I understand that I need to have a test system to test my change project. And then in a later stage I can merge my change project with my production tenant. We have done this already once with our customer. But are you saying I need a separate test tenant per change project? I was under the impression that I could assign multiple change projects to one test system, our permanent test system. Is this not recommended? And why?

        • You need a separate test tenant per change project if you want to carry out testing of each change project at the same time. In case, you do not want to test all the change projects at the same time, you can move one at a time to your permanent test system, do the testing and merge it back. After this you can move the next change project to the same permanent test system. As you can see, this would be a sequential process, one change project at a time.

          If you want to go with sequential process, I would then question why to create multiple chance projects? you can also achieve this creating a new change project after the merge of the previous one. This is a simpler and cleaner approach.

  • Thanks Saurabh and Geetha for the comprehensive post.

    I have posted a short recommendation blog post in the SAP Business ByDesign space since this is relevant for ByD as well.

  • Hi Saurabh,

    Thanks for the valuable information.

    A query on the below lines

    "Once a change project is created, there is automatic synchronization between this change project and the live project. This means, in case you make some fine tuning changes in your live project, those changes will not automatically come to the existing change project"

    How can we bring the changes made on the live project to the changed project?

    • Thanks for this typo, I have corrected the article. For your specific query, there is no automatic sync between a change project and the live project. In general, this means that if you carry out some changes in your live project then you need to do these changes in your change project as well. However, there is a possibility of getting the changes from live project into your change project through activity "Update from Production". This activity will sync up your change project with the live project and will show you the differences. For each different, you will have a choice to either keep the content of your change project or overwrite it with the content from your live project. More on this activity is explained in article no 3 of this blog series.

  • There are regular questions regarding multiple change projects. Saurabh has given the recommendation to have only one at the time as a good practice to keep the organizational complexity for the different project teams low.

    Technically there is no restriction in the number of parallel change projects. I would like to give some addional information that might help to decide what a good practice for a certain change requirement is.

    The key message basically is: Use only so many change projects in parallel as you are able to coordinate... 😉

    Best regards,

    Tilo Reinhardt

    SAP Development
    BC Tools for ByD and C4C

    Can I use multiple change projects in parallel?

    Technically there is no limitation in the number of parallel change projects - neither local change projects nor change projects in change project test systems.

    Change projects are independent from each other. Changes in one project do not interfere with changes in parallelly existing change projects. This offers the opportunity to separate different changes in different areas and test them independently from each other in different test systems.

    Change projects always know the active configuration they are created from – typically the production system. The system offers the possibility to synchronize changes from the production configuration into the change project while the change project is active. This allows to update change projects with changes done in the production system in parallel.

    Change projects can be cancelled to abandon the configuration changes done so for in them.

    Once configuration changes in change projects are finished, they need to be merged with the active configuration in the production system. While this is done, all configuration constraints and checks are performed on the resulting configuration and the merge is prevented by the system in case errors are found. This prevents that an inconsistent configuration is deployed in the production system.

    Typically, such inconsistencies are result of parallel changes in the production system that contradict to changes that come with the change project. This can happen because of the independence of change projects mentioned above and a missing regular synchronization of the change project with the production configuration.

    To avoid such surprises, we recommend synchronizing your change project with the active configuration regularly as well as perform Merge Simulations on a regular basis as well. This will identify possible inconsistencies with the active configuration early.

    Since parallel change projects are independent from each other, changes in such parallel projects must be coordinated by the involved project teams in parallel outside of the system - especially when doing changes in the same settings! When the projects are to be merged one after the other with the active configuration, the merge will of course make sure that the currently to be merged project doesn’t create inconsistency in the active configuration.

    Best practice here is to reduce the number of parallel change projects to the bare minimum that is needed in order to reduce the complexity of organizational coordination. Many customers stick therefore to the “one change project at a time” paradigm and only use additional change projects for specific projects. An additional good practice is to keep the lifetime of a change project short and/or make sure that they are synchronized regularly.