SAP Transport of Copies: When to Use It and What It Hides

Decision context

A transport of copies moves a snapshot of the current object versions into a target system without releasing the original request. The developer keeps working, the object stays assigned to its original task, and testing can start earlier.

The price is traceability. The target system now holds content whose provenance is a copy, not a released request, and nothing in the target says which version of the original it corresponds to. Two weeks later, with three copies imported, the question of what is actually in quality assurance is genuinely hard to answer.

This page describes what the instrument does, the four ways it diverges from the original, and the small set of rules that keep it useful. Adranum's contribution is to keep the package identity attached to the validation result, so a test that passed against a copy cannot be presented as a test that passed against the release.

What it actually does

A transport of copies is created in SE01, SE09, or SE10 as its own request type, given an explicit target system, and filled with objects copied from an existing request, a task, or a manual selection.

The object list is a copy taken at the moment you fill it. It is a snapshot, not a link. Later changes to the original do not appear in the copy.

• The original request is not released and its ownership is unchanged. The developer can keep changing the object.
• The target system is set explicitly on the copy rather than inherited from the standard consolidation route, which is why a copy can go somewhere the normal route would not send it.
• The import writes the copied object versions into the target and creates version history there, exactly as a normal import does.
• Nothing in the target distinguishes an object that arrived by copy from one that arrived by a released request, unless your process records it separately.

The four divergences to plan for

Each of these is a normal consequence of the instrument rather than a defect. They only become problems when nobody accounted for them.

• Deletions do not travel. If the developer deletes an object from the original request after the copy was made, the copy already imported into the target stays there. The target accumulates objects that will never reach production.
• The copy ages the moment it lands. Every further change in the original makes the tested version and the release version different, so a test result against the copy is not a test result against the release.
• Order can invert. A copy imported now and the original released later is fine. A copy imported after a later request already changed the same object in the target overwrites the newer version with an older one.
• Nothing enforces the follow-up. If the original request is never released, the target keeps content that production will never receive, which is one of the more common causes of a quality system that no longer resembles production.

Rules that keep it useful

The instrument is legitimate and often the right answer. These rules are what separate a controlled preliminary import from an untracked one.

• Record the original request number on the copy's short text, so the target's content can be traced back without asking the developer.
• Never send a transport of copies to production. There is no released original behind it and no reproducible path from source to production.
• Re-import from the released original before any test result is treated as evidence for a release decision.
• Check the object overlap before importing. If another request in the queue touches the same objects, decide the order deliberately rather than discovering it from the version history.
• Set a maximum age. A copy older than the current sprint should be replaced rather than trusted.
• Track outstanding copies as open items. The list of copies imported whose original is still unreleased is a useful weekly report and is usually longer than expected.

What the workflow must cover

• Package identity. Bind each validation result to the exact package it ran against, so a result from a copy cannot be read as a result from the released request.
• Object overlap detection. Compare the objects in a pending import against the objects in other queued or unreleased requests before the import decides the order for you.
• Deletion visibility. Surface objects present in the target that no longer appear in any releasable request, which is where copies accumulate.
• Open copy tracking. Keep the list of imported copies whose original is still unreleased as an explicit open item rather than tribal knowledge.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Confirm a preliminary import is genuinely needed rather than a scheduling convenience.
2. Create the copy with the original request number in the short text and an explicit target.
3. Check object overlap against the queue and the unreleased requests.
4. Import, test, and record that the result is against a copy.
5. Release the original and re-validate against the released package before the release decision.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Copy request number and target
• Original request reference
• Object list snapshot
• Object overlap report
• Import log and return code
• Validation result and its package identity
• Open copies whose original is unreleased
• Objects in target with no releasable source

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• A transport of copies has no released original behind it, so it is not a production path under any circumstances.
• The copy cannot carry deletions made in the original after the snapshot.
• Version divergence between the copy and the eventual release is a process matter. No tool prevents it, it can only make it visible.

Buyer checklist

• Does the copy record which original request it came from?
• Which objects in the target arrived only by copy?
• Has anything been tested against a copy and reported as tested against the release?
• How old is the oldest imported copy whose original is unreleased?
• Was object overlap with the queue checked before import?