Tailoring by deployment

One playbook must serve very different delivery models. SAP S/4HANA Private Edition changes through transports and planned upgrades. SAP S/4HANA Cloud Public Edition changes on SAP's schedule. SAP BTP extensions change through pipelines. The policy stays the same for all three; the practices and templates are tailored. This lesson shows what changes and what never does.

What never changes

• Every change has a recorded test decision.
• Process owners accept; the TCoE gives a readiness assessment.
• Evidence meets the same seven-line standard and lives in SAP Cloud ALM.
• The same severity scale and defect workflow apply.

Private Edition: you choose the timing

Contoso runs SAP S/4HANA 2025 Private Edition under RISE. SAP delivers a new base release every two years with feature pack stacks about every six months, and RISE customers can request an upgrade from SAP, which performs the technical work while the customer tests. Change also flows continuously through transports from CMD to CMQ to CMP. The tailored practices are: a release test plan for each feature pack stack update, scheduled in the TCoE calendar; ATC and ABAP Unit results as entry criteria at transport release (owned by development); targeted regression per enhancement release; and the emergency test record for break-glass changes.

Public Edition: SAP chooses the timing

Contoso has no Public Edition system today, so treat this as a what-if for a future acquisition. Public Edition upgrades twice a year, in February and August. SAP gives about six weeks' notice, upgrades the test system first and the development and production systems a few weeks later, and that gap is the customer's regression window. The tailored practices are different in kind:

• The release test plan is fixed to SAP's dates. The pack, data and key-user bookings must be ready before the test system is upgraded.
• Use SAP's test automation tool first. SAP's test automation tool for Public Edition is included in the subscription. Its standard processes match SAP Best Practices test scripts and are read-only; custom processes are copied from standard ones or recorded. Results appear in SAP Cloud ALM next to manual test plans.
• Know what post-upgrade tests cover. With the customer's consent, SAP runs post-upgrade tests in the test tenant after each upgrade, but only for standard, unchanged processes. They do not replace regression of the customer's own configuration and extensions.
• Extensions are key-user and developer extensibility, so the evidence standard must cover custom fields, logic and apps that SAP's standard tests do not know about.

BTP extensions: pipelines and transport routes

Contoso's side-by-side extensions run on SAP BTP with the transport path CMC_DEV, CMC_TEST and CMC_PROD in SAP Cloud Transport Management. CMC_TEST imports automatically; Priya forwards to production only after test sign-off; CMC_PROD imports on a schedule in the approved release window. The tailored practices put automated tests in the pipeline (unit and service tests for CAP, UI tests for Fiori elements and UI5), make the forward to production the release gate, and require that the extension's end-to-end tests against CMQ (through destination CMC_S4HANA) join the regression pack.

Connected cloud applications

SAP cloud applications such as SAP SuccessFactors and SAP Ariba, and non-SAP services such as bank and carrier platforms, change on their own vendors' schedules. Contoso cannot control those dates, so the practices tailor two things: an interface regression set for each connection, triggered when either side changes, and a watch list in the TCoE calendar for each provider's release dates and notices. Theo's integration team owns the connections; the TCoE owns the regression set and the evidence.

The tailoring table