🚀 Transporting Configuration Between Tenants in SAP Sales & Service Cloud V2: A Change Project Guide

With SAP Sales Cloud Version 2 (V2), SAP continues its modernisation to reinvent the CRM experience—offering a cleaner, more modern interface and a scalable architecture designed for enterprise-level growth. As organizations adopt V2, one topic that frequently surfaces for implementation teams is how to reliably transport configuration changes between environments, particularly from Test (QA) to Production.

In this blog, we’ll walk through the essentials of executing a Change Project in SAP Sales Cloud V2, with a special focus on transporting configuration specifically for Case and Case Type services. You’ll learn how the process works, why it’s needed, and the best practices for ensuring a smooth transportation of changes.

🔍 What Is a Change Project in SAP Sales & Service Cloud V2?

A Change Project is SAP’s structured way of capturing and transporting configuration changes across environments. It allows you to:

• Record configuration updates in a designated source system (such as a staging or development tenant).
• Transport these validated changes into target systems like Test or Production.
• Use a multi-tier setup where one source tenant can push changes to multiple targets for the same customer ID.

In simple terms, think of a Change Project as a secure container holding all tested and approved configuration changes—ensuring that only validated configurations make their way to Production.

🔄 The Two-Step Transport Process

Transporting configuration in SAP Sales Cloud V2 happens in two key phases:

1️⃣ Initial Load

Before delta transports can be used, the system requires that all connected tenants — or any tenants that intend to participate in Change Project transports — are properly synchronised.

This is where the Initial Load comes in.

Here’s what happens during this phase (Source To Target):

• The initial load ensures that configuration data for the chosen service (e.g., Case or Case Type) is identical across the source and target tenants.
• It must be triggered by the customer because certain pre-checks or preparations may be required in the source environment.
• By default, the initial load takes the current configuration from the Source and applies it to the Target tenant(s).
• After completion, both tenants are fully aligned, with no extra or missing configuration.

Note: For most existing customers, the initial load is typically performed from the Production tenant to the Test tenant. This approach is considered safer because it does not pose any risk to the Production environment. Therefore, this direction of initial load—from PROD to TEST—will also be supported.

Once the Initial Load is done, you’re ready to move on to continuous change recording.

2️⃣ Delta Load

After synchronisation, any configuration changes you make in the source system are:

• Automatically captured within the currently checked-out Change Project.
• Stored as delta changes.
• Transportable whenever the administrator decides to push them to the target environments.

This offers flexibility and control—only the changes you want, when you want them.

🔄  Understanding the Initial Load Process

When you trigger the Initial Load, the system collects all existing configuration data for the selected service—even if those configurations were created before the Change Project existed. Keep in mind that the Initial Load must be executed individually for each service.

In this blog, we’ll focus on Case and Case Type services.

🗂️  What Gets Transported?

Case: The following code list configurations are included when transporting Case data:

1. Status Dictionary Entries
2. Status Schemas
3. Priorities
4. Source Settings

Case Type: Transport inclusions for Case Type include:

1. Case Type Code List
2. Case Type Template Versions
3. Action Catalog

These two services are registered separately so that dependent and independent configurations remain logically separated.

🔗 Case Type Service Dependencies

The Case Type service depends on several other services. Initial Load for Case Type can only proceed after the Initial Load of all dependent services is completed.

Dependent Services:

• Approval
• Autoflow
• Mashup
• Extensibility
• Form Admin

This ensures that all necessary underlying data is already present in the target tenant before Case Type configurations are transported.

Before proceeding with Initial Load for Case or Case Type, make sure to go through the Important Considerations and Initial Load Behaviour sections.

Now, let’s walk through the Initial Load and Delta Load processes.

🚀 Executing the Initial Load & Delta Load

🔎 Step-by-Step: Initial Load for Case

Step 1: Start Initial Load (Case)

After configuring source and target tenants as mentioned in Change Project, initiate the Initial Load for the Case service by navigating to Settings → All Settings → Change Project → Administration → Registered Services → Case → Start Initial Load. Confirm the pop-up.

A Change Project titled “Initial Load for Case” is automatically created in the Source tenant.
This captures all configuration items related to Status Dictionary Entries, Status Schema, Origin (Source Settings) and Priority

The Change Project will appear with the status WORK IN PROGRESS, meaning it’s ready to be published.

Step 2: Publish the Change Project (Source Tenant)

In the Test (source) tenant, Login and navigate to:

Settings → All Settings → Change Project → Administration → Initial Load for Case → Publish.

Step 3: Transport the Change Project

Continue in the Test tenant:

Settings → All Settings → Change Project → Administration → Initial Load for Case → Transport.

You will be prompted to select the target tenants. Choose the appropriate ones and proceed. In my scenario, I had two target tenants.

After transporting, the change project status in the source system changes to Transported.

Step 4: Activate in Target Tenant

Log in to the Production (target) tenant:

Settings → All Settings → Change Project → Administration → All Change Projects

You will see the Initial Load for Case project with the status Imported.

Once you're satisfied with the incoming configurations, click Publish to activate the changes.

Step-5: 🔁 Performing Initial Load for Case Type

Since Case Type depends on other services, you must first complete Initial Loads for all dependent services.

The system enforces this and hides any services whose Initial Loads are already complete.

🧪 Step-by-Step Behaviour for Case Type

Let’s assume that initial load is done From Target to Source for Case Type.

Since the steps for performing the Initial Load for Case Type are nearly identical to those for Case, I won’t repeat them here. Instead, I’ll focus on explaining the Template Version concept in Case Type, which requires a more detailed walkthrough.

Step 1 — Before Initial Load

Case Type ZABC exists in both source (Quality) and target (Production), with versions as shown in the pre-load state.

Step 2 — After Initial Load (Prod → Source)

After performing the Initial Load from Production to Quality

Here CHT Means Change Transport.

• The Source DRAFT version is removed, and the Target DRAFT version becomes the new DRAFT in the source tenant.
• All existing template versions in the source are moved to INACTIVE status, and the prefix “CHT” is added to each version that is deactivated.
• All incoming template versions from the target—whether ACTIVE, DRAFT, or INACTIVE—are created in the source exactly as they exist in the target.

This aligns both tenants to the same configuration baseline and visually user can co-relate the versions going forward.

🎉You’ve now completed the Case and Case Type Initial Load and successfully transported configurations between the tenants in SAP Sales Cloud V2!

🚀 Delta Load

When Delta Load is enabled:

• Any configuration changes made to Case or Case Type in the source tenant are automatically captured in the checked out Change Project—this happens when the project is checked out and the changes are performed. If a Change Project is not checked out, you will be getting an error as below.

  

   

  • Solution: Go to the Change Project list and either create a new Delta-type change project (which will automatically check it out for your logged-in user) or open an existing open change project and check it out. This step ensures the system can track and store your delta changes correctly.

• When the administrator decides to transport these updates or the delta change projects  to the target tenant, the captured changes are transported and published based on the admin’s choice.
• Since Case configuration handling is straightforward, I won’t go through those steps here.
• Case Type however, behaves differently. After the delta Change Project is transported and published in the Production (target) tenant, the template version statuses are updated as follows with continuing above example. 
• Version 4 transitions from DRAFT → ACTIVE
• Version 3 transitions from ACTIVE → INACTIVE

⚠️ Important Considerations

When you perform the Initial Load, the system imports all existing configuration for the selected service—including configurations created before the Change Project existed.

• Since Catalog is a master data entity and is referenced within Case Type configurations, it’s important that customers maintain the same Catalog Display ID across all tenants before implementing Change Projects for Case Type. The system relies on matching Catalog Display IDs between the source and target tenants when validating and transporting data, and this alignment is required for both the Initial Load and Delta Load processes for Case Type.

• Additional points:

  • Service Levels are not included in the Change Project scope.
  • Decision Table Configurations—Configurations such as Service Level Determination, Case Routing to Employee, and Case Routing to Team are not transported through Change Projects as they may contain tenant specific data. Also they support import/export using excel.
  • However, the decision table ID maintained against Case Routing to Team and Case Routing to Employee within the Case Template version is transported. You only need to recreate the corresponding decision table in the target tenant using the same DisplayId.
  • The Number Range name is included in the Change Project for Case Types; however, the actual number range values may differ between source and target tenants. 
    • Hence, In the target tenant – the number range remains editable under:
      Settings → Case Management → Number Range.
      

In this blog series, we’ll walk through how to execute these steps specifically for Case and Case Type configurations in SAP Sales Cloud V2.

🔄 Initial Load Behaviour

Before initiating the Initial Load, it’s important to understand how the target tenant will react to incoming configuration if the initial load is done in Source to Target Direction:

• New configuration in the target → will be added
• Existing configuration (common) → will be updated
• Configuration missing in the source but present in the target → will be deleted

Before any deletion occurs, the system performs a usage check.

If a configuration item is actively used in Case transactions or referenced by other configurations, the system will fail the Initial Load, indicating that the item cannot be removed.

✅ Best Practices 

• Transporting Deletions:  When transporting deleted configurations between tenants—typically during a delta transport—make sure to first verify in the target tenant whether the configuration you plan to delete is actively used. You can quickly check this by using Case OWL Advanced Filters, which provide visibility into all configuration fields related to both Case and Case Type.

🛠️ Admin Options When Conflicts Occur

If an Initial Load fails because a configuration is still in use, administrators generally have two options to resolve the issue. Below, we’ll walk through these options using an example where the Initial Load direction is Source → Target.

1. Recreate the configuration in the source tenant
   Usually, delete conflict in target occurs If a configuration cannot be deleted due to transactional dependencies. If that's the case recreate the same configuration in the source tenant and then retry the Initial Load.