Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 4 of 5

The evidence chain from request to production

8 min

When an auditor, a process owner or a future support analyst asks "why did this change go into production, and how do we know it worked?", the answer is the evidence chain: a linked set of records that trace a production change back through its approval and tests to the original request. If any link is missing, the chain is broken, and the change cannot be shown to have been controlled.

  1. RequestChange record: what, why, who asked, business priority
  2. Assessment and approvalImpact and risk documented; business owner and change manager approve
  3. BuildConfiguration or code in DEV, recorded in transport requests linked to the change
  4. TestTest cases and results in QAS: functional, regression, and acceptance by the business
  5. Deployment approvalGo decision recorded with the test evidence reviewed
  6. ImportTransport import log in PRD with date, time and who imported
  7. Verification and closurePost-implementation check; record closed
The evidence chain. Each step leaves a record that points to the step before.
The Sign-Off Table · thesignofftable.com/academy/sap-rel-101

The links that matter most

The weakest link is usually between the change record and the transport requests. A transport is the technical container that carries configuration or code from DEV to QAS to PRD. If transports are not linked to a change, nobody can say which approved change a production import belonged to. Good practice is to create transports only from or with reference to an approved change, and to include the change ID in the transport description. SAP's change tools enforce this: in Solution Manager ChaRM, transports are created from change documents; in SAP Cloud ALM, transports are assigned to features, and SAP recommends transport restrictions so that changes are tied to a feature ID.

LinkEvidenceWhere it usually lives
Request to approvalApprover, date, risk ratingChange record
Approval to transportTransport numbers listed on the change; change ID on each transportChange record and transport description
Transport to testTest cases executed on the QAS system that holds the transport, with resultsTest management tool, linked to the change
Test to deploymentGo decision referencing the test resultsChange record or release record
Deployment to productionImport log showing the same transports, in sequenceTransport management system logs
The links of the evidence chain and where the evidence normally sits.
The Sign-Off Table · thesignofftable.com/academy/sap-rel-101

Tested what was deployed

The evidence chain has one subtle requirement: the thing that was tested must be the thing that was deployed. If a developer fixes a defect found in QAS by changing the object again in a new transport, the test evidence for the first transport no longer describes what will go to production. The retest must cover the new transport. Likewise, if the import sequence in production differs from QAS, the tested combination is not the deployed combination.

Post-implementation verification

The chain does not end at import. A short post-implementation check in production confirms the change behaves as expected with real data: Maria creates one fleet order and checks the price, or Dan confirms that the changed account determination posts to the right G/L account. The check is quick, but it closes the loop and catches environment differences that QAS could not show.

  1. Is every transport in the release linked to an approved change?Yes → next question · No → remove the transport or link it with approval
  2. Was each change tested on the latest version of its transports?Yes → next question · No → retest before go
  3. Is the production import sequence the same as in QAS?Yes → approve the release · No → align the sequence or retest the new combination
A release-level evidence check before the import window.
The Sign-Off Table · thesignofftable.com/academy/sap-rel-101

What would you do?

During Contoso's release go/no-go, Priya finds a transport in the import list that is not linked to any change record. The developer says it is "a small fix that was tested". What should happen?

Key points
  • The evidence chain links request, approval, transports, tests, deployment approval, import and verification.
  • The weakest link is usually between change records and transports; link them by design.
  • Test what will be deployed: latest transport versions in the same sequence.
  • Close the loop with a post-implementation check in production.

Check your understanding · not graded

Lesson check

  1. 1. Which artifact links a production import back to its tested requirement?

  2. 2. A defect fix in a new transport means what for testing?

  3. 3. What is a post-implementation check?

  4. 4. What should happen to a transport not linked to any change?