Iterations: sandbox to production

An upgrade is rehearsed before it is performed. Each system in the path is an iteration with its own test focus, and each one should leave the next one better prepared: a shorter runbook, known adjustments, known runtimes, fewer surprises. Teams that treat development and quality updates as mere stepping stones learn the same lessons three times; teams that plan iterations learn them once.

Iterations and their focus

Iteration	System	Test focus	Output for the next iteration
Sandbox	Temporary copy of production	Technical feasibility, runtimes, first adjustment list, first functional smoke	Issues list, runtime estimates, early fixes
Development	CMD	Modification and custom code adjustment, unit tests, developer checks	Adjustment transports, fixed custom code
Quality	CMQ, then CMR	All test streams at full depth, performance, data validation, UAT	Signed-off evidence, final runbook, go/no-go input
Production	CMP	Smoke tests, validation, hypercare monitoring	Closure and lessons learned

Test focus per upgrade iteration.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-304

Why a sandbox first? The first technical run discovers issues and measures runtimes without disrupting the delivery landscape. Development and quality systems carry projects and support work; a failed first attempt there blocks everyone. A sandbox copied from production also has production-like data, which makes runtime and data-related findings realistic. Under RISE, request it early, because creating it is a service with lead time.

Development: the locked system

The upgrade guide warns that at a certain point during the update, the development system is locked and repository objects cannot be changed. If production still needs emergency fixes during that time, the guide recommends a temporary copy of the development system to supply them, with dual maintenance: fixes made in both the temporary and the original systems. For a longer project, a temporary quality system can be added too. That affects testing: the support team needs a way to test emergency fixes for the old release while the project tests the new one.

While CMD is locked, emergency fixes come from a temporary development copy and must be repeated in CMD, so both releases need a test path.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-304

Carry lessons forward

Adjustment transports: SPDD and SPAU work done in development is offered to later systems, so quality and production updates do not repeat it.
Runtimes: each run's uptime and downtime phases are measured; the quality run should be close to the production plan.
Runbook: Luis keeps one runbook with every manual step, owner and duration, updated after each iteration.
Issue list: every issue found has a fix and a test that proves the fix in the next iteration.
Test set: smoke tests from the sandbox become the first checks in quality and production.

An issue found in one iteration should end as a transport and a runbook step, so the same issue cannot reappear in the next system.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-304

Week 1–2Sandbox updateTechnical run by SAP ECS; smoke tests; first runtimes and adjustment list.
Week 3Development updateDevelopment locked; modifications adjusted; custom code fixes; unit tests.
Week 4–7Quality update and testingUpdate with adjustment transports; all streams; DTV; UAT; performance.
Week 8Go/no-goEvidence reviewed; decision recorded; production downtime confirmed.
Week 8 weekendProduction updateRamp-down, update, follow-up, smoke tests, validation, release to users.

An example eight-week plan for a feature pack stack at Contoso.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-304

Hands-on lab · ACCELQ

Carry one smoke Scenario through every update iteration

Each iteration should start with the same smoke checks, run against a different system. In ACCELQ, App Environments stand for the systems and a Global Property supplies each one's URL, so one Scenario follows the update from sandbox to production without edits.

Practice on SAPUI5 Shopping Cart demo app (public, no login), standing in for every system in the path

If you haven't set up ACCELQ yet, do the setup lab first.
In Project Administration > Application Environments (Project Admin rights), set up one environment per iteration: Sandbox, CMD, CMQ and CMP. If your trial won't let you add environments, use the ones that exist and map them on paper.
In Resources, create a Global Property AppURL and give every environment the Shopping Cart demo URL. On a real project each would be a different system, and a practice run never points at production.
Take a smoke Scenario you already have, or build one that opens a category, adds a product and verifies the cart shows it. In the Scenario, click the URL on the Initiate Browser Session step and point it to the Global Property.
Run the Scenario once per environment, in update order. Name the iteration in Purpose, for example FPS02 Sandbox smoke.
Before the CMQ run, add one check you learned from the sandbox, such as an Intent mode verification on the cart total. This is the lesson's rule: an issue found in one iteration gets a test in the next.
Compare the Test Reports. You should see the same Scenario, the right environment in each sidebar, and the extra check from CMQ onward. Note how long each run took, because runtimes are one of the things an iteration carries forward.

Done when You have one Test Report per environment for the same smoke Scenario, each naming its iteration in Purpose and showing the matching App Environment, with the added check present from CMQ onward. Keep the links as your iteration closure evidence.

Learn more in ACCELQ’s docs: Setting up Application Environments · Understanding Global Properties in ACCELQ · Opening browser with dynamic URL in ACCELQ

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Working with SAP ECS

Under RISE, SAP ECS runs the Software Update Manager through service requests. The upgrade guide describes ECS triggering SUM 24 hours before the requested execution start so that uptime activities complete before downtime begins, and break-points where ECS expects the customer's input or action, such as SPDD, the development lock and SI-Check results. Before downtime, the customer performs ramp-down: stopping application background jobs, locking business users, clearing stuck queues and update errors. Those steps belong in the runbook and in the test plan, because each has a check afterwards.

Service requestContoso requests the update for a system with the planned schedule.
UptimeECS starts SUM ahead of downtime; break-points need Contoso input.
Ramp-downContoso stops jobs, locks users, clears queues and update errors.
DowntimeECS completes the technical update.
Follow-up and testContoso performs follow-up activities, then runs the iteration's tests.

Customer and SAP ECS steps in one update iteration under RISE.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-304

What would you do?

The sandbox update shows a downtime of 14 hours, but Contoso's agreed production window is 10 hours, Saturday 20:00 to Sunday 06:00. What should the team do?

Key points

Plan iterations: sandbox, development, quality, production, each with its own test focus.
A sandbox copy of production finds technical issues and runtimes without disrupting projects.
Development is locked during the update; use a temporary development copy and dual maintenance for emergency fixes.
Carry adjustment transports, runtimes, runbook, issues and smoke tests forward.
Under RISE, ECS runs SUM; the customer handles break-points, ramp-down, follow-up and testing.

Iterations and their focus

Development: the locked system

Carry lessons forward

Working with SAP ECS

Lesson check