Transporting Production Process Designs In SAP Digital Manufacturing – Part 1: How It Works Today

If you've ever deployed a production process design to quality, held your breath, and wondered how to get that exact version — reliably, traceably — into production, this post is for you.

Introduction

SAP Digital Manufacturing customers commonly run two or three tenants. Many teams operate a quality system for validation alongside a production system where designs run on the shop floor. Others extend this with a dedicated development tenant where new process designs are authored before they reach quality. Moving a design reliably across that chain — and knowing exactly which version is running where — is one of the most operationally important tasks a Production Engineer performs.

SAP Digital Manufacturing addresses this through a structured PPD transport workflow built on SAP Cloud Transport Management (cTMS). This guide covers the full picture: how to connect the systems, how to trigger and complete a transport, and what the system is doing for you behind the scenes. It also consolidates best practices gathered from across the feature's lifecycle, so you can set up your transport pipeline the right way from the start.

Two Ways to Transfer PPDs — Choosing the Right One

SAP Digital Manufacturing offers two distinct mechanisms for moving production process designs between tenants. This blog focuses on cTMS-based transport, but it is worth understanding how the two compare, since many teams start with manual export/import and later evaluate whether to adopt cTMS.

	Manual Export / Import	cTMS-Based Transport
Setup required	None beyond DM access	cTMS service subscription + BTP destinations, nodes, and routes
How files move	You download an export file from the source tenant, then upload it manually to the target	Automated through the cTMS pipeline — no file handling
Import modes	Manual only	Manual, Scheduled, or Automatic
Version traceability	Version Mapping field records source version and source system after every import	Version Mapping field records source version and source system after every import
User carry-over	Initial transport copies all source users/work groups; subsequent transports merge them	Initial transport copies all source users/work groups; subsequent transports merge them
Audit trail	Version Mapping on every transported PPD	Full transport log in cTMS, plus Version Mapping on every transported PPD
Best for	Ad-hoc or one-time transfers, landscapes without BTP admin access, simple two-tenant setups	Systematic DEV → QA → PROD pipelines, automated release cadences, regulated environments requiring traceability

A few things to keep in mind when comparing them:

Process type scope: Only cloud production processes can be transferred. Edge production processes and automation sequences are not supported by either mechanism and must be recreated manually in the target system.
The authorization rule is the same for both: a user must be listed in either the source or target PPD's defined users or work groups to overwrite an existing design. This rule was not changed by the cTMS enhancements.
The status eligibility rules (blocking transport of Failed, Awaiting Deployment, and Awaiting Undeployment PPDs) apply to both mechanisms.

If you are currently using manual export/import and want to evaluate the cTMS route, see the SAP Help Portal — Export and Import Production Process Designs for the manual process, and continue with the rest of this blog for the cTMS setup.

How PPD Transport Using cTMS Works — The Big Picture

Before stepping through procedures, it helps to understand the cTMS transport architecture.

When you trigger a transport from the Design Production Processes app in SAP DM, the system serializes the selected PPDs and pushes them as a transport request into SAP Cloud Transport Management (cTMS). cTMS then carries that request to your target tenant, where it is imported and materialized as new or updated PPDs.

The channel between SAP DM and cTMS is a transport destination in SAP BTP — a named connection that tells cTMS where the target tenant lives. The path a transport follows from source to target is defined by transport nodes (one per tenant) connected by a transport route.

cTMS supports three import modes:

Import Mode	How It Works	Best For
Manual	A human user logs into cTMS and clicks Import Selected	Ad-hoc transports, first-time setup
Scheduled	A technical user runs imports on a defined schedule	Regular release cadences, overnight promotions
Automatic	A technical user imports immediately upon receiving the request	CI/CD pipelines, fast-follow deployments

All three modes are fully supported for PPD transport. Scheduled and Automatic modes use a technical user in cTMS rather than a human one — both are valid and handled correctly by the system.

Part 1 — System Connection Setup

What You Need Before You Start

Roles and permissions

You need the following in place before transporting:

Global account administrator access on SAP BTP (for service setup)
The Production_Engineer role in SAP Digital Manufacturing
You must be listed as a user (or a member of a work group) on each PPD you want to transport. A user without this assignment can export a PPD but cannot overwrite it.

Note: The user who triggers the transport in SAP DM and the user who performs the import in cTMS can be different people.

cTMS Setup — Step by Step

PPD transport via cTMS has been available since the 2411 release. If your landscape is already set up, skip to Part 2. If you are configuring transport for the first time, complete these five steps in order.

Step 1 — Subscribe to SAP Cloud Transport Management

In your SAP BTP global account, subscribe to the SAP Cloud Transport Management service in the subaccount that will host cTMS. Follow the initial setup guide in the SAP Cloud Transport Management documentation to activate the service.

Step 2 — Create a cTMS service instance and service key

In your BTP subaccount, go to Instances and Subscriptions and create a Cloud Transport Management service instance. Once created, generate a service key. You will use the credentials from this service key in the next step.

Step 3 — Create transport destinations

Establishe the two destinations that make the transport pipeline work: one that lets SAP DM push requests into cTMS, and one that tells cTMS which target tenant to deliver the content.

Destination 1: Source subaccount → cTMS (allows SAP DM to push transport requests into cTMS)
In the source subaccount (BTP Cockpit → Connectivity → Destinations), create a destination with the cTMS service key credentials you generated in Step 2.
Destination 2: cTMS → Target DM tenant (allows cTMS to deploy content into the target tenant during import)
In the subaccount that subscribes to cTMS (BTP Cockpit → Connectivity → Destinations), create a transport destination with service key credentials of the target tenant subaccount.

Step 4 — Create transport nodes in cTMS

Open the SAP Cloud Transport Management application and define:

A source node representing your source tenant (e.g., development or QA)
A target node representing your target tenant (e.g., QA or production). Assign Destination 2 created in Step 3.

Step 5 — Create transport routes

In cTMS, create a transport route that connects your source node to your target node. This route defines the path a transport request will travel. You can chain multiple routes for multi-stage landscapes (e.g., DEV → QA → PROD).

For the complete setup reference, see the SAP Help Portal — Transport PPD Through SAP Cloud Transport Management.

Part 2 — Triggering a Transport

Step 1 — Select Your PPDs

Open the Design Production Processes app in SAP Digital Manufacturing. In the list view, select one or more PPDs you want to transport.

Supported process type: Only cloud production processes can be transported via cTMS. Edge production processes and automation sequences are not supported for transport and will not be transferred.

Capacity limit: Each transport request supports up to 20 production process designs at a time. If you need to move more than 20, split them into multiple transport requests.

Step 2 — Understand Transport Eligibility by Status

The system enforces transport eligibility at the moment you trigger transport. The rules reflect the intent of each status:

Status	Transport Behavior	Rationale
Deployed	Allowed	Stable, active version — the primary transport use case
Archived	Allowed	Archived version can still be useful to carry to target
Modified	Allowed	Has unpublished changes; target admin can review and redeploy
Draft	Allowed	Has unpublished changes; target admin can review and redeploy
Failed	Blocked	Broken state — no value in transporting a PPD that errored out
Awaiting Deployment	Blocked	Transitional state — transporting mid-operation is likely unintentional
Awaiting Undeployment	Blocked	Transitional state — same reason as above

If your selection includes one or more blocked-status PPDs, or PPDs that contain only automation sequences and edge processes, the system displays a warning dialog listing those designs and explaining why they cannot be transported. You can either remove them from your selection manually, or click Continue Anyway — the system will then proceed with the transport for the valid PPDs only and skip the rest.

Step 3 — Trigger the Transport

With your eligible PPDs selected, click the Transport button in the toolbar. Before the system creates the transport request, a dialog appears where you must:

Select the Source Node — choose the cTMS transport node that corresponds to your source tenant.
Enter a transport description — provide a meaningful name for the request so it is easy to identify in cTMS.

After confirming the dialog, the system creates the transport request in cTMS and confirms it with a message strip at the top of the screen. Click the link in the message strip to open SAP Cloud Transport Management directly.

Part 3 — Completing the Import in cTMS

Manual Import

In SAP Cloud Transport Management, navigate to your target transport node.
Locate the transport request created in the previous step.
Select the request and click Import Selected.
Monitor the import status until it completes.

Manual Import.png

Scheduled or Automatic Import

If your target node is configured with a technical user in Scheduled or Automatic mode, no further manual action is required. The system handles the import on the defined schedule or immediately, respectively.

Part 4 — What the System Does During Import

This is the section that a lot of customers are not aware of. Several important behaviors happen automatically during import — understanding them helps you avoid surprises.

Transported PPDs Always Land in Draft or Modified Status

Regardless of the source status, all PPDs arrive in the target system in Draft or Modified status. They are never automatically deployed in the target. This is by design: the target administrator has the opportunity to review the design, verify it in the target context, and make an explicit deployment decision.

User and Work Group Carry-Over

User and work group assignments are handled automatically during import, but the behavior differs based on whether this is the first time the PPD is appearing in the target:

Initial transport (the PPD does not yet exist in the target):
All users and work groups from the source PPD are copied to the target PPD. The target starts with the same access configuration as the source.

Non-initial transport (the PPD already exists in the target):
Users and work groups from the source are merged into the target. No existing target assignments are removed — if someone was added to the PPD in the target after the last transport, they keep their access.

Authorization constraint: Regardless of import mode, a user must be listed in the source or target PPD's defined users or work groups in order to overwrite it during import. As any user could potentially trigger the transport request in SAP Digital Manufacturing, this is a security rule that prevents any non-PPD-assigned users from overwriting the existing PPD.

Who Gets Added as a User After Import

Three parties are involved in a transport: the user who triggered the export in SAP DM, the user who triggered the import in cTMS, and optionally a technical user. The system adds all of them to the target PPD's user list by default — this ensures that everyone who touched the transport chain retains access in the target.

Part 5 — Tracking Versions Across Systems

Version management is one of the most commonly misunderstood aspects of PPD transport. Here is how it works.

Why Versions Diverge

When a PPD is first transported to the target, the target version starts in sync with the source. But as soon as the PPD is deployed and later modified in the target — or if the source PPD evolves independently and is transported again — the version numbers in the two systems no longer match. This is expected behavior, not a bug.

The Version Mapping Field

To give you a clear audit trail despite version divergence, the system maintains a Version Mapping field in the PPD detail header for every PPD that has been transported. To see it:

Open the transported PPD in the target tenant.
In the PPD detail header, locate Version Mapping.
Click Show Details to open a pop-up table with three columns:

Column	Meaning
Current Version	The version of this PPD in the target system right now
Source Version	The version of the PPD in the source system at the time of the last import
Source System	The subaccount ID of the source system

Version Mapping.png

The mapping is updated every time the PPD is imported. It always reflects the most recent transport — not a cumulative history.

If a PPD is copied (as opposed to transported), the copy starts a new origin and does not inherit the Version Mapping field. The mapping only exists for PPDs that arrived via transport or import.

Part 6 — Deploying After Transport

Manual Deployment

After import, your transported PPDs are in Draft or Modified status and ready for review. Deploy them individually through the Design Production Processes app as you would any other PPD: select the design, review its contents, and trigger deployment.

Best Practices and Recommendations

Planning Your Transport Pipeline

Model your landscape before setting up cTMS routes.
Define your DEV → QA → PROD chain explicitly as transport nodes and routes before you start transporting. Retrofitting a transport topology is much harder than planning it upfront.

Always transport in one direction — never reverse the sequence.
Follow your landscape chain (DEV → QUAL → PROD) strictly in that order. Importing from a higher-tier system back into a lower-tier one can overwrite tested, approved designs and is extremely difficult to recover from. If you need to move a fix from production back to development, port the change manually rather than reversing the transport route.

Transport across systems that are on the same version.
Ensure the source and target systems are running the same release version before initiating a transport. Transporting PPDs across different release versions is not recommended, as it may introduce compatibility issues that are difficult to diagnose and resolve. For example, avoid transporting a PPD after a quality deployment in the source system but before the corresponding production deployment has been applied to the target system.

Use one transport request for logically related PPDs.
Group PPDs that belong to the same process or release into a single transport request. This keeps your cTMS transport log organized and makes it easier to roll back a logical change by re-transporting a previous version.

Keep each transport request to 10 PPDs or fewer.
While the system allows up to 20 PPDs per request, limiting batches to 10 makes them easier to review, troubleshoot, and roll back if an issue arises. For large go-lives, plan your batches in advance rather than filling requests to the maximum.

Transport Eligibility and Status

Transport Deployed designs for production rollouts.
Deployed designs represent a stable, tested version of your process. A Draft or Modified PPD may contain incomplete logic, placeholder steps, or untested branches. Transporting a Modified or Draft design to a production tenant is possible but should be a deliberate, exception-case decision.

Do not attempt to work around the Failed/Awaiting status blocks.
If a PPD is in a Failed or transitional state, fix it in the source system before transporting. Attempting to route around the status check by exporting through another path will produce the same broken design in the target.

Automation sequences must be reconfigured manually in the target system.
Automation sequences are not included in a transport request and will not be carried over. After importing and deploying your PPDs in the target, recreate any associated automation sequences from scratch in that system. Plan this step into your release checklist so it is not overlooked.

Dependency Order

Transport and verify published production processes before transporting parent PPDs.
If a parent PPD references published production processes, transport those processes first. Before triggering the parent's transport, confirm that each sub PPD has been successfully imported, deployed, and registered in the service registry in the target system. A parent PPD whose sub PPD references are unresolved will fail deployment.

Dependent Objects — What Travels and What Does Not

DM services, user-defined services, and schemas are included automatically; web server objects are not.
When you transport a PPD, the system automatically identifies all cloud production processes and includes all DM services, user-defined services, and schemas that the transported cloud processes depend on — you do not need to package these separately. However, web server objects (such as third-party web servers or external interface configurations) are not included in the transport request. Create these objects manually in the target system, using the exact same names as in the source, before triggering the transport. Mismatched or missing web server object names will cause broken references after import. Similarly, if any automation sequences are invoked within the transported cloud processes, those automation sequences are excluded from the transport and will appear with a Deleted status in the target system. You must manually recreate these automation sequences in the target system to restore full functionality.

Version Traceability

Check the Version Mapping field before deploying in the target.
After each import, open the PPD in the target and verify that Source Version and Source System reflect the transport you just performed. This is your confirmation that the right version came across.

Do not copy transported PPDs to preserve version traceability.
Copied PPDs do not inherit the Version Mapping field — they start a new version history. If you need a variant of a transported PPD in the target, modify the original rather than copying it, or accept that the copy has no cross-system version trail.

User and Access Management

Verify user assignments in the target after the first transport.
On initial transport, the system copies source users and work groups to the target. However, if your target tenant has different identity providers or user names than the source (a common scenario in multi-region landscapes), check that the copied user IDs are valid in the target.

Add target-specific users before the second transport.
On non-initial transports, the system merges source assignments into the target without removing existing ones. Any users you add in the target after the first transport are safe — they will not be removed by subsequent imports.

Use work groups rather than individual user assignments where possible.
Work groups are easier to maintain across transport cycles and reduce the risk of someone losing access because their individual user record was not in the source PPD.

Import Mode and Automation

Use Automatic or Scheduled mode for repeatable release cadences.
Manual imports require someone to log into cTMS and click Import Selected every time. For teams doing regular releases, configuring a technical user in Automatic or Scheduled mode eliminates that step and reduces the chance of a missed import.

Quick Deploy

Always review the validation report before deploying.
The pre-flight validation catches dependency order conflicts, permission issues, and status problems before a single PPD is deployed. A few minutes reviewing the report can save hours of undoing a partially deployed batch.

Resolve circular dependencies before deploying.
If PPD-A calls PPD-B and PPD-B calls PPD-A, the system will surface this as a circular dependency error — there is no deployment order that resolves mutual references automatically. Until a proper solution is available, use the following workaround:

Adjust PPD-A — remove the PP Service calls from PPD-A that create the circular dependency.
Deploy PPD-A — deploy the modified PPD-A (with the dependency temporarily broken) to the target system.
Deploy PPD-B — deploy PPD-B to the target system.
Restore PPD-A — after PPD-B is deployed, modify PPD-A to add back the PP Service steps that call PPD-B.

Keep external dependencies deployed in the target before batch-deploying.
If any PPD in your Quick Deploy batch calls a PPD that is not in the batch, that external PPD must already be in a deployed state in the target. Check the validation report for external dependency warnings and pre-deploy any flagged designs first.

Summary

Transporting production process designs across tenants in SAP Digital Manufacturing is a structured, auditable process when the right setup is in place. Here is a quick reference for the key behaviors:

Topic	Key Point
Transport limit	20 PPDs per transport request
Status gate	Failed, Awaiting Deployment, and Awaiting Undeployment are blocked
Post-import status	All imported PPDs land as Draft or Modified — never auto-deployed
User carry-over	Initial: copy from source. Non-initial: merge from source, preserve target.
Version Mapping	Available in PPD detail header; shows Current Version, Source Version, Source System
Version mapping persistence	Stays until next import overwrites it; copies do not inherit it