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.