Go-Live Readiness for SAP Commerce Cloud: The Checks That Decide the Weekend

Pilots run the same checklist on their thousandth flight as on their first, which is exactly the point: go-live failures are almost never exotic. They are the DNS TTL nobody shortened, the ImpEx step that lived only in a developer's head, the rollback plan that had never been executed, the alert that was configured but routed to nobody. This guide is the readiness discipline for an SAP Commerce launch, distilled from the CX Works go-live material and organized the way a go/no-go meeting actually runs.

The One Non-Negotiable: A Rehearsed Deployment on a Production Twin#

Everything else on this page is secondary to a single condition: you have a written deployment procedure, and you have executed it, completely, on a staging environment equivalent to production (same code version, same catalog scale, same customer volume, same configuration). Every step, every wait, every validation. If a re-run was needed, staging was reset to production-equivalence first, because a procedure proven only on a half-reset environment has proven nothing.

The procedure document itself is boringly specific, and its specificity is its value. It names, in order:

• The ImpEx files to run, and when in the sequence
• The exact options selected in the system update
• Every manual change, however small, with its owner
• Cronjobs to trigger by hand, full Solr indexes to run
• Database index modifications
• New purge and retention processes to activate (per the data maintenance guide)
• Post-step validation: smoke tests, a full order transaction, search, returns, and every third-party integration exercised

Manual undocumented steps are where launches die; the document converts tribal knowledge into a runbook the QA and operations teams can follow without the author in the room. (If your pipeline maturity is at the level of the continuous delivery guide, most of this document is automated; the document then records what the automation does, which the go/no-go meeting still wants to see.)

Release Machinery for the Day After#

Launch day gets all the attention, but the release process is judged by week two, when production traffic exists and the fixes start flowing:

• Branching and release strategy decided before launch. Deployments are simple while there is no production traffic; design the post-launch flow (hotfix path, release cadence, promotion gates) during the calm, not during the first production bug.
• Promotion gates that hold: builds move environment to environment only with unit, integration, and automated functional tests green; QA promotes to stage, operations triggers production. The workflow must deliver to test environments faster than developers produce changes, or CI becomes the bottleneck that teaches people to bypass it.
• Rolling deployments for the routine case. Code-only changes with no data-model impact deploy with zero downtime, one node at a time, proven on staging before ever being trusted on production. Major releases (data model changes, platform updates) get the full ceremony instead: structured testing plus a load test on staging refreshed with production data.
• Maintenance windows, operationalized. If a release does need downtime: maintenance pages configured (and configured in the CDN, not just the origin), full redirects to the site-down page for long windows, and the operations team involved in testing the procedure rather than receiving it by email.

Rollback: Write Down the Uncomfortable Truths#

A rollback strategy that has not absorbed these three facts is a wish:

1. Snapshot before deploying. Database backup and media snapshot as the first step of the production procedure, every time. Restores take real time, so a restore-based rollback is a decision with a cost, which is exactly why it must be rehearsed once (see the upgrade execution guide's go-forward point and time-box pattern for making the decision in advance).
2. Code-only changes roll back easily. Redeploy the previous build; the platform's deployment model makes this cheap.
3. Type-system changes mostly do not. Once a type-system change has landed in production and data has flowed, the realistic remedy is a fix deployed forward, not a restore that discards the day's orders. Consequence for readiness: data-model changes get disproportionate scrutiny in lower environments (QA plus load testing), because production is where your rollback options run out.

Cutover Mechanics: The Internet-Facing Details#

The category of item that is trivial to do early and catastrophic to remember late:

• DNS TTL below five minutes on the domain being cut over, lowered far enough in advance that the old TTL has expired everywhere before launch. A 24-hour TTL discovered on launch morning means a day of split traffic.
• SEO continuity plan. Every indexed URL of the old site either keeps working or 301-redirects to its successor, with the redirect map tested before launch and the new site's URL patterns designed not to collide with the old ones (a different context path is the clean way to guarantee it). Skipping this burns years of accumulated ranking in a weekend.
• User migration behaviour decided and worded. Migrated customers frequently must reset passwords on first login (password hash migration rarely survives the trip; see the data protection guide's encoding notes). The login form's messaging must say so plainly, or launch week's support volume doubles. And resist the blast email asking everyone to reset on day one: deliberately inviting your entire customer base to visit during launch is load testing in production with extra steps.
• Endpoints and certificates final: IP filter sets reviewed (storefront open, Backoffice and admin endpoints restricted, per the first-deployment guide), custom certificates loaded and serving.
• Third-party pen test done. A security test by someone who did not build the site, against the release candidate, with findings triaged before go/no-go. Your customizations are the attack surface the platform's own testing has never seen.

Monitoring: Configured Is Not Ready#

The gap between "monitoring exists" and "monitoring is ready" is where the first incident gets extended by an hour:

• Alerts defined for the failure signatures you already know (Kibana/OpenSearch patterns, Dynatrace problem rules, per the observability guide), routed to named humans who have acknowledged the routing.
• Dashboards for launch: the baseline views plus order throughput, so the war room watches business outcomes, not just CPU.
• Business transaction validation after the production deployment: the monitored user journeys (search, PDP, cart, checkout) verified against their SLA targets in production, as a deployment step, not a hope.
• An after-incident report format agreed in advance, for deployment issues and outages both. The habit of writing down what happened, blamelessly, within days is what converts launch problems into organizational knowledge instead of folklore.

On-Premise Addendum#

Self-hosted launches carry the infrastructure checklist CCv2 absorbs: current patches across the full stack (app server, web server, Solr, database), OS versions inside the supported matrix, configuration management (Ansible or friends) driving deployments, Solr and web-server configs in source control, build and deploy scripts in source control, and per-node configuration (node IDs, connection strings, JVM parameters) templated with token replacement rather than hand-edited. Cluster behaviours (node discovery, task engine, cronjob node groups) deserve a dedicated pre-launch review, because they misbehave under exactly the load launch brings.

The Go/No-Go Checklist#

The compressed version, for the meeting itself. Every line is a yes, a documented exception, or a no-go:

Deployment

• Written procedure executed end to end on a production-equivalent staging
• Rollback snapshot steps in the procedure; restore rehearsed once
• Type-system changes in this release enumerated and QA'd with extra depth
• Post-launch release and hotfix process documented

Cutover

• DNS TTL lowered and expired
• SEO redirect map tested; no URL pattern collisions
• User migration flow tested; login messaging correct
• IP filters, certificates, maintenance pages (including CDN) final

Quality

• Full regression green on the release candidate
• Load test on staging with production-shaped data (see the performance engineering guide)
• Third-party security test findings closed or accepted in writing

Operations

• Alerts routed to named, acknowledged owners
• Launch dashboards ready; business transaction validation scripted
• Support coverage rostered for launch window and the following week (the high-traffic guide's operations model applies)
• After-incident report format agreed

Data

• Retention and cleanup jobs active from day one (the data maintenance guide's list)
• Data protection obligations verified: consent flows, erasure jobs, anonymized lower environments

The list is deliberately unglamorous. Every item on it exists because some launch, somewhere, was ruined by its absence, and the teams whose launches make no news are simply the ones who checked.