Move Requirements between Projects

[Mustameer_Khan]

Move requirements between projects 

In real projects, things do not always go as planned. Sometimes requirements are created in the wrong project. Sometimes the project scope changes. Sometimes work is reorganized across teams. Until now, fixing this often meant recreating requirements manually, which took time and increased the risk of mistakes.

With this new feature, users can now move requirements from one project to another directly in SAP Cloud ALM. This saves time, reduces manual effort, and helps keep all information accurate and connected. Most importantly, it preserves traceability so nothing important is lost along the way.

When can a requirement be moved(Conditions)

To keep data consistent and processes clean, a few conditions must be met before moving a requirement.

1. The requirement must be in In Refinement status.
2.  No feature should be assigned to the requirement at the time of moving.

Who can move the requirements between projects 

To ensure proper control and governance, only users with the role of Project Lead or Project Administrator are allowed to perform the move action.

These rules make sure that only early stage requirements are moved. This avoids any impact on active development work and helps teams stay aligned.

What happens to related objects when a requirement is moved

When a requirement is moved to a different project, only the requirement itself is moved. Any existing relationships that the requirement has with other objects in SAP Cloud ALM are removed during this process. This means that links to objects such as documents,  Solution Processes, test cases, or other related items are not carried over to the new project. All these objects remain in the original project where they were created. They are not moved or copied to the new project.

In simple terms, the requirement travels alone. Everything else stays where it was. This behavior ensures that projects remain clean and consistent. It also avoids accidentally moving objects that are still relevant to the original project.

Simple example to explain this behavior  :  Imagine a requirement in Project A that has a Solution Process or a document attached to it. The document might contain business notes or design details and is stored within Project A. When the Project Lead or Project Administrator moves the requirement to Project B, only the requirement is moved. The attached document stays in Project A. The link between the requirement and the document is removed as part of the move.

If the document is still needed in Project B, it can be uploaded again or recreated there. This gives teams full control over what content belongs to which project. This clear separation helps teams avoid confusion and ensures that each project only contains the objects that truly belong to it.

Why this matters

Earlier in projects, it often happened that requirements were created across different projects during the initial phases. When the business later decided that some of these requirements actually belonged to a different project, there was no simple way to move them.

The only option was to mark the requirements as obsolete and delete them. Consultants then had to either download and upload the requirements into another project or manually create new requirements in the correct project. This process was time consuming, error prone, and often led to loss of context and traceability.

With the new move requirement feature, this problem is now addressed. Requirements can be moved directly to the correct project at an early stage. This makes the process much simpler from an individual perspective and also from a project perspective. Teams can respond faster to business decisions, avoid unnecessary rework, and keep their projects clean and well structured.

Business example

Imagine a customer running two implementation projects, one for Finance and one for Sales. During early requirement refinement, a requirement related to pricing logic is accidentally created in the Finance project. Later, the team realizes that this requirement actually belongs to the Sales project and has not yet been picked up for development.

With the new move requirement feature, the consultant can simply move the requirement to the correct Sales project. There is no need to recreate the requirement, re enter details, or worry about losing comments or history. The team saves time, avoids errors, and can continue refining the requirement in the right project without disruption.

We hope you enjoy this improvement and find it helpful in your daily work with SAP Cloud ALM. As always, your feedback is welcome and helps us continue to improve the product.