Executing an SAP Commerce Upgrade: Testing, Deployment, and the First Two Weeks After

The assessment guide in this series sizes an upgrade; this one lands it. The pattern across failed upgrade projects is remarkably consistent: the code migration itself goes roughly as estimated, and the damage happens in the phases teams under-plan: testing against unrealistic data, a deployment procedure executed for the first time on production night, no agreed rollback trigger, and a support model that dissolves the team the morning after go-live. Each of those has a known fix, and together they are this guide.

Execution Phase Discipline#

The engineering work (fix, refactor, migrate, commit) follows directly from the assessment's issue list, so only the rules that keep it on rails:

• Test continuously, not just in the testing phase. Unit and integration suites run throughout execution; the dedicated testing phase exists to certify a candidate, not to discover basic breakage that a nightly build would have caught weeks earlier.
• Two bug populations, strictly separated. Every bug found gets reproduced against a reference environment running the untouched source version. Pre-existing bugs go to the normal backlog; only upgrade-caused regressions block the upgrade. This single triage rule is what stops the upgrade from mutating into an unbounded remediation project.
• Watch the quality trend. The Sonar baseline from the assessment should not degrade under schedule pressure; new blockers introduced during migration get fixed with priority, because "we will clean it up after go-live" has a documented success rate.
• Write the deployment procedure as you go. Every manual step the migration required (SQL fix-ups, ImpEx, HAC scripting console runs, orphaned-type cleanup) goes into the deployment plan the moment it is discovered. Upgrade deployments differ from routine releases precisely in these extra steps, and a procedure reconstructed from memory in week twelve misses some of them.

Testing: Certifying the Candidate#

The testing phase runs on a production-like environment, accessible to the business users who will accept it. The sequencing that works: deployment testing first, then regression, then acceptance, security, and performance in parallel. And the iron rule: a failed test that produces a new release candidate restarts the affected test chain. Re-testing only the fix is how subtle regressions ride into production.

Test data: realistic and repeatable#

Two properties, both mandatory, frequently traded off against each other by accident:

1. Realistic. Production-shaped volumes (orders, carts, customers, promotions) with emphasis on the data that caused trouble historically. PCI and privacy rules usually forbid raw production data, so the practical answer is the anonymized-restore pipeline from the data loading guide, or generated data at production scale.
2. Recurrently loadable. Every test type needs to start from the same data state, or failures stop being comparable between runs. Package the test dataset as toggleable ImpEx wired into initialization or system update, so "reset the environment" is a build target rather than an afternoon.

Deployment testing#

Nothing sours a signed-off release faster than the build failing in production for procedural reasons. Before functional testing even finishes:

• The people who will run the production deployment execute the full plan, end to end, on a lower environment. Not a colleague, not a dry read-through: the actual operators, so questions surface while they are cheap.
• Issues traced to procedure rather than code get fixed in the plan, now.
• The run is timed, step by step. Those timings schedule the production window and the checkpoint calls, and later feed the rollback time-box.
• The rollback is rehearsed too. If the plan says "restore database and media, redeploy source version", that restore gets executed once for real in a lower environment. A backup strategy is only as good as its last tested restore.

Regression, acceptance, and the other two#

Regression is the certification gate: the full automated suite against the candidate, plus scripted manual passes over the storefront fundamentals where automation is thin (login, browse, search, cart, checkout with payment). Automate relentlessly here; this suite runs against every candidate, and manual-only regression is why testing phases overrun.

Acceptance depends on the upgrade's shape. A like-for-like upgrade reuses the original acceptance criteria unchanged, which is the point of like-for-like: the business tests that nothing moved. An extended upgrade (new features taken during the migration) needs new test cases and criteria per feature, defined back in planning, not improvised now. Business users execute; business QA signs.

Security testing is not optional on upgrades, and not only because the target version might carry an unknown issue: the migration itself touched authentication, session handling, and Spring Security configuration (the assessment guide flags that refactor for a reason). The full security suite runs against the candidate, and the expectation is that the target version tests better (newer libraries, years of fixes), which is worth demonstrating rather than assuming.

Performance testing answers whether your source-version baselines still hold: same journeys, same volumetrics, same environment shape (the performance engineering guide's machinery applies unchanged). Mild degradation is a business decision to accept knowingly or fix; significant degradation below the source baseline is a timeline conversation, because shipping a known-slower site and "planning to fix it live" is how peak season finds you.

Deployment: The Production Window#

The plan is the deliverable#

By deployment night the plan has been executed at least twice (deployment testing, plus every lower-environment promotion used as a dry run), so the production run is choreography, not exploration. Upgrade-specific steps that distinguish it from a routine release, all discovered and sequenced during execution: pre-deployment data migration, the code deployment itself, post-deployment data enrichment (ImpEx preferred, direct SQL as documented last resort), type-system cleanup of orphaned types, and verification checkpoints between stages.

Data migration placement deserves care: some changes must land before the new code (schema the new version requires), some after (enrichment the new code enables). The plan marks which is which, because running them in the wrong order is a classic 2 a.m. discovery.

Rollback: decide the trigger before you need it#

The rollback mechanics are straightforward: database backup and media snapshot as the first deployment step; on rollback, restore both and redeploy the source version, losing nothing.

The decision mechanics are where teams fail, so fix them in daylight:

• A go-forward point: the step in the plan beyond which rolling back costs more than pressing on.
• A time-box: how long the team works production issues before rollback becomes the decision. Fixing forward is the primary option once most of the plan has executed; the time-box exists so that choice has a boundary, and the roles that make the call are named in the plan.

Written down beforehand, this removes the worst dynamic of upgrade nights: an open-ended debate at hour six, with sunk costs arguing against tired judgment.

Production regression#

After deployment and data migration, a scoped regression runs in production, because lower environments cannot prove production integrations. The set that catches most issues:

• Anonymous customer: search the top keywords, view products, add/update/remove cart, anonymous checkout, order status, cancellation if offered
• Registered customer: register, log in, repeat the above
• Customer service: the same flows through assisted service, plus a refund and a return

Integration failures dominate this phase's findings (credentials, endpoints, and allowlists differ in production in ways staging never sees), which is exactly why the suite must actually execute, gently, against real systems. Non-blocking issues become tickets; blockers meet the time-box. When the suite passes, project management on both sides agrees the deployment is complete, and the final "open the site" steps execute.

Support: The Two Weeks That Protect the Investment#

An upgrade's incident probability spikes for days after go-live, and the standard application-management team is not staffed for it, because the people who know what changed are the upgrade team. The model that works:

• A dedicated post-go-live team blending upgrade engineers with application-management members, on explicit duty for the first days to weeks. Its job is fast diagnosis with full context: the person who refactored the Spring Security config is the right responder to the login incident.
• Everything found gets written down: bugs to the tracker, configuration and operational surprises to the knowledge base. This archive is disproportionately valuable; it seeds the next upgrade's assessment.
• A defined handover: when stability criteria are met (agreed incident rate, no open blockers), the special team dissolves formally into normal application management, and the project moves to closing. Without the explicit handover, the upgrade team stays informally on the hook forever, which burns people and blurs accountability.

Train the business users, deliberately#

Upgrades ship capability the business does not know it has, and untrained users either ignore new features or misuse them. Plan enablement per user group; the recurring examples:

Schedule a second training wave a week after go-live: by then users have real questions, and their intensive use of new features doubles as extended acceptance testing, surfacing the bugs polite UAT never finds.

The Checklist Version#

• Reference environment on the source version, for bug triage, all project long
• Test data: production-shaped, anonymized, reloadable via build target
• Production deployment plan executed end to end by the production operators, timed
• Rollback restore actually performed once in a lower environment
• Full regression on every candidate; chain restarts on every new candidate
• Acceptance criteria matched to upgrade type (like-for-like reuses; extended extends)
• Security and performance suites run against the final candidate
• Go-forward point, time-box, and decision roles written into the plan
• Production regression set agreed and gently executable against live integrations
• Post-go-live team named, handover criteria defined, training scheduled

None of this shortens the upgrade; all of it shortens the part that happens with the site down and executives on the bridge call, which is the part everyone remembers.