Stage and Live: Move Site Changes from Preparation to Public
How SGEN separates work-in-preparation from the public site, and how promotion moves approved changes between them.
Stage and Live is the boundary between work being prepared and work currently in force on the public site.
Stage holds the prepared version of the site. Live is the version visitors see right now.
The two are not the same site twice. They are two separate environments, with one direction of travel: promotion moves a prepared version from Stage into Live. Recovery moves Live back to a prior known-good version if a promotion needs to be reversed.
This page explains the model, where to find it, how to perform a promotion, and how rollback works when a release must be reversed.
Read it end-to-end the first time you encounter the surface — the moment-by-moment shape of a promotion is short, but knowing the recovery path before you need it is the difference between a calm rollback and an anxious one.
| Field | Value |
|---|---|
| Audience | public |
| Area | operations |
| Updated | 2026-05-21 |
| Status | draft |
What is this for?
Stage and Live is the SGEN release-control surface. It governs the movement of site state from a prepared environment into the public environment, and back again when a release must be reversed.
Reach for this surface when:
- A version of the site has been prepared and needs review before it goes public.
- An approved version of the site is ready to be promoted into the public environment.
- A current public release needs to be reversed and the site returned to its last known-good state.
- Stakeholders need to inspect what is currently in preparation, what is currently live, and which version came before.
- A release window opens and the team needs to coordinate the moment the public site changes.
- An audit question arises about who promoted what and when.
Why a separate surface for environment movement
Environment movement is rarer than content editing, higher-stakes than content editing, and needs a different ceremony around it. A page publish affects one page. A promotion affects the whole site. The surface for promotion is built to slow the operator down at the moment that matters — confirming the staged version, confirming the rollback target is in place, recording the operator and time — because a promotion that goes wrong has site-wide consequences. A separate surface makes the slow-down deliberate rather than an afterthought, and the audit trail makes the consequence reviewable later.
Good use cases
- Reviewing a prepared version before a major site update reaches visitors.
- Promoting an approved version into the public environment under explicit operator command.
- Reversing a release that has caused an unexpected change in public behavior.
- Confirming, for a stakeholder, exactly which version is currently live and which version is staged behind it.
- Auditing who promoted what, when, and which environment received the change.
- Coordinating a release window where multiple operators need to read the same surface and agree on what is in flight.
- Preparing a release-week brief for a stakeholder by reading the surface and the audit trail together.
- Pausing between staged preparation and public release for an external review cycle — the staged version sits visibly on the surface during the review window.
Patterns that show up across teams
Three patterns show up across teams that operate Stage and Live regularly. The first is the scheduled release window — a fixed time on a fixed day when promotions happen, with everything else queued for that window. The second is the change-and-confirm cycle — promote a staged version, confirm the public site reflects the change, then sign off on the release in the team channel. The third is the staged-environment-as-preview pattern — the staged environment doubles as a preview surface for stakeholders to review before the public site changes. All three patterns are good fits for the surface, and they often combine on the same site.
What NOT to use this for
- Editing individual pages, blog posts, or modules — open the admin for the relevant content type.
- Publishing or unpublishing a single content object — see Publishing Lifecycle.
- Switching the active theme or template — open the appropriate authoring surface, not Stage and Live.
- Day-to-day content edits — those flow through the admin and SG-Builder. Stage and Live governs environment-level movement, not individual content state.
- Routine content publishing on a high-frequency content type like a blog — those publishes happen inside the active environment through the standard authoring surface, not through Stage and Live.
- Reading single-page performance numbers — analytics and reporting live on different surfaces, not on Stage and Live.
- Resolving a user role or permission question — role configuration is its own settings area, separate from release control.
How this connects to other features
- Environment Model — the underlying concept of staging versus production. Stage and Live is the operator surface for that model.
- Deployment & Release Overview — the broader build → validate → promote → recover sequence. Stage and Live is the promote and recover step of that sequence.
- Publishing Lifecycle — content-state governance (draft, publish, update). Stage and Live inherits the same state-clarity discipline at the environment scale.
- SG-Dashboard Stage & Live reference — the structural reference page for this surface inside SG-Dashboard.
How the surfaces compose end-to-end
The full path from an idea to a public-site change can cross several surfaces. Content authors work inside the admin or SG-Builder, where the Publishing Lifecycle governs draft → publish → update on each content object. When a release window opens, the prepared environment containing those publishes is moved forward through Stage and Live, and the public environment receives the change as a whole. The Environment Model is the underlying concept that makes this composition coherent — staging and production are distinct, the movement between them is governed, and the operator surface for the movement is Stage and Live.
Each surface owns its scope. Authoring surfaces own content. Publishing Lifecycle owns content state. Stage and Live owns environment movement. Reading the surfaces in that order is the path from a draft idea to a public-site outcome.
Before you start
- You need an authenticated SGEN session with release permissions on the target site.
- A staged version must exist before promotion. If nothing is staged, there is nothing to promote.
- The target site must be selected in the dashboard scope before Stage and Live actions become available.
- You must know what changed in the staged version. Promote into Live only after the staged version has been reviewed.
- You must know the prior live version. Rollback returns the site to that prior version.
- The team channel or release log should be open. Promotion and reverse events deserve a parallel record outside the surface itself, so the rest of the team sees the change at the moment it happens.
- The public site should be reachable from your operator location. If the public site is not reachable for you, you cannot confirm the promoted change on the public side.
- A second operator should be reachable if the release window requires sign-off from someone other than you. Two-operator releases need both operators ready before the promotion is triggered.
Pre-flight checks before triggering promote
Five quick checks tighten the safety of a promotion. Confirm the staged version on the surface matches the version that was prepared (the version identifier should match the one referenced in the team channel). Confirm the change owner has signed off and the sign-off is recorded somewhere outside the surface. Confirm the rollback target is present — if no rollback target is available, the recovery path is narrower if the promotion goes wrong. Confirm the public site is responsive right now, before the promotion changes its state, so any post-promotion non-response is information rather than noise. Confirm no other operator is on the surface for the same site.
These five checks take under a minute and rule out the most common avoidable failures.
Where to find it
Stage and Live lives inside SG-Dashboard under the site you are managing. Open SG-Dashboard, select the site, and open the Stage and Live surface from the site navigation.
The surface shows three things in one view:
- The staged version waiting for promotion.
- The version currently in force on the public site.
- The action available right now (promote, reverse, or none).
- A version identifier and timestamp for each of the three versions.
- A record of which operator performed the most recent action on the surface.
- An indication of whether the rollback path is available for the current site.
Reading the surface at a glance
The three-version view answers most release-state questions without further action. The staged version label tells you what is queued. The current-live label tells you what visitors are seeing. The prior-version label tells you where rollback would land if reverse were triggered now. Each label carries a version identifier and the time that version became current, so the surface reads as a release history compressed into three rows rather than a separate audit log.
For multi-site operators, the same surface shape appears for every site in the dashboard, so reading state across a portfolio is a repeatable scan rather than a per-site interpretation.
Surface availability and timing
The surface is available as soon as the dashboard scope is set to a site that has a staged or live environment configured. New sites that have not yet produced a staged version show the surface with the staged slot empty and the promote action hidden. As soon as a staged version exists, the surface starts to reflect the full three-version view. The reverse action appears once a prior live version is retained — typically after the first promotion completes.
There is no separate setup step for the surface itself. It mirrors whatever environment state the site has, and shows the actions that the current state supports.
Steps
The most common operation on this surface is promotion of a staged version into Live. The procedure below walks through it once end-to-end. Rollback follows the same shape with a different destination.
What a clean promotion looks like as a sequence
A clean promotion has six discrete moments. The operator opens the surface and reads the staged version. The operator confirms the staged version matches the version they intend to promote. The operator triggers the promote action. The surface reports movement in progress. The surface reports completion with the new current-live version named. The operator confirms the public site reflects the change. Each moment is observable, so a promotion that stalls or fails leaves a clear trail of which moment was the last one to complete.
Reading the sequence as six discrete moments rather than one continuous action is the cognitive frame that makes the surface predictable. The operator knows what to look for at each step, and an unexpected outcome at any step is information that names the next action.
1. Open Stage and Live for the target site
From SG-Dashboard, pick the site you want to promote. Open the Stage and Live surface for that site.
Confirm two things before going further: the staged version on the surface is the version you intend to promote, and the currently live version on the surface is what you remember being public.
If either is unexpected, stop. Resolve the question before triggering a promotion.
The site-selection step is the most common source of misfired releases — promoting to the wrong site is a recoverable error but a noisy one. Confirm the site name on the surface matches the site you intended to open before reading further.2. Review the staged version
Open the staged version in a review tab. Inspect the pages, modules, or settings that changed. Stage is built so this review happens before the public site is affected.
Confirm with whoever owns the change that the staged version is approved for public release. Promotion is the moment the public site changes — review happens before that moment, not after.
For a release that touches many pages, a review checklist is worth more than a free-form walkthrough. The checklist names the pages to review, the specific elements to confirm on each page, and the sign-off owner for each item. The checklist is the record that the review happened, separate from the promotion record on the surface.3. Trigger the promotion
With the staged version approved, trigger the promote action on the Stage and Live surface. The dashboard records the request and prevents a second promotion from being submitted while the first is in progress.
While the promotion runs, the surface shows movement-in-progress state. Do not navigate away on the assumption that the action is complete — wait for the completion state.
The single-in-flight guard is intentional. It rules out the most common race condition — two operators triggering promote in close succession — by enforcing one promotion per site at a time. If you trigger promote and the surface shows the action already in flight, a second operator beat you to it. Read the surface to confirm which version the in-flight promotion is moving, and coordinate before any further action.4. Confirm the new live version
When promotion completes, the surface updates to show the newly promoted version as the current live version. The version that was previously live becomes the prior version available for rollback.
Confirm on the public site that the promoted change is visible. Note the time and version reference in your release log — the dashboard also records this for audit purposes.
Open the public site in a clean session — a private window or a different browser profile — so any cached version on your normal session does not mask the promoted change. The clean-session check is the surest way to confirm the public site reflects the promotion. If the public site does not show the change on a clean-session read, the promotion may have completed at the surface but stalled at a cache layer between the surface and the public site; that distinction is information worth capturing in the release log.5. Reverse if required
If the new live version causes unexpected behavior, return to the Stage and Live surface and trigger the reverse action. The public environment moves back to the last known-good prior version.
Rollback is explicit. It is not a guess and not an auto-revert. An operator triggers it, the dashboard records it, and the public site returns to a state that was previously in force.
6. Record the release outcome outside the surface
The dashboard records every promotion and reverse. A parallel record in the team channel or release log captures the operator-side context that the surface does not — why the promotion was made now rather than later, who signed off, what stakeholder communication accompanied it. The two records together produce a full audit trail: surface for state, team log for intent. When a release retrospective happens weeks later, both records read together tell the complete story.
What success looks like
A successful promotion has four signals:
- The Stage and Live surface shows the previously staged version as the current live version.
- The public site reflects the promoted change when opened in a fresh browser session.
- The promotion event is recorded against your operator account with the time it completed.
- The prior live version is visible on the surface as the rollback target if reversal becomes necessary.
Beyond the in-surface signals, a clean release has secondary outcomes that downstream teams should be able to verify on their own. The release log entry exists with a timestamp matching the surface record. The support team can answer "what changed at that time" by reading the dashboard, not by asking the operator. The next staged version starts from the version that was promoted, so the staging environment does not silently drift behind production. Each of these is a downstream confirmation that the promotion was complete, not partial.
| Outcome | What you see on the surface | What you see on the public site |
|---|---|---|
| Promotion in progress | Movement state, action disabled | No change yet |
| Promotion succeeded | New current-live version, prior version available for rollback | Promoted change visible |
| Promotion failed | Failure message, prior live state preserved | No change |
| Rollback succeeded | Prior version now current-live | Public site reverted |
| Rollback in progress | Movement state, action disabled | Prior public state still visible |
| Rollback failed | Failure message, current-live unchanged | Current-live still in force |
| Read-only inspection | Three versions visible, no action triggered | No change |
Confirming the public-side outcome
After the surface reports a completed promotion, open the public site in a fresh browser session — a private window or a different browser profile is the cleanest way to bypass any cached pages. Visit the page or pages that should reflect the change. The promoted content should render without a hard refresh, and the page metadata should match the staged version.
If the public site does not match the surface state within a reasonable window, do not promote again. The mismatch is information — read it before acting.
What to do if it does not work
Stage and Live actions can fail at several points. Each has a specific recovery path.
| Failure mode | What it means | What to do |
|---|---|---|
| Permission denied on promote | Your role does not have release rights on this site | Ask a site owner with release rights to perform the promotion |
| No staged version available | Stage is empty for the selected site | Confirm the staged version was prepared on the correct site |
| Promotion runner failed mid-flight | The deployment service hit an error before completion | Do not retry blindly — confirm current-live state on the surface first, then retry from a clean state |
| Network interruption during promote | Connection dropped while movement was in progress | Wait for the surface to refresh, confirm the recorded state, then act |
| Rollback target missing | No prior version is retained for this site | Rollback is not available — recovery must come from a separate restore path |
| Staged version older than current-live | A newer version was promoted while this staged version sat in review | Re-stage from the current-live baseline before promoting, so the promotion does not regress in-force work |
| Surface shows two operators contending | Another operator opened the same surface concurrently | Coordinate with the other operator before either of you triggers an action — only one promotion can be in flight per site |
| Promotion succeeded on surface, public site unchanged | The public site is serving a cached version | Wait for cache propagation, confirm a fresh-session read, only retry if the surface itself shows failure |
| Reverse action greyed out after a recent promote | The rollback retention window has not yet recorded the prior version | Wait for the surface to refresh, the prior version normally appears as a rollback target within a short window |
| Site scope reset during a long review session | The session timed out and dropped the selected site | Re-select the site in the dashboard scope and confirm the surface reflects the right site before acting |
When to escalate rather than retry
Most failures resolve with a clean refresh and a second attempt. A few signals say the right move is to stop and escalate instead of retrying. If two consecutive promotion attempts fail with the same error message, the failure is structural and a retry will not change the outcome. If the surface and the public site disagree for more than one refresh cycle, the disagreement itself needs a person to look at it, not another button press. If a rollback completes on the surface but the public site still serves the broken version after cache propagation, the recovery path has not finished and a separate restore path is the next step.
Escalation is part of the workflow, not a failure of it. Stage and Live is designed so that an operator can stop safely at any ambiguous moment without making the situation worse.
Examples
Example 1: Promoting a marketing campaign update
An agency operator has prepared a new landing page and three updated blog posts on the staged version of a client site for a Monday campaign launch. On Monday morning, the operator opens Stage and Live for the site, confirms the staged version contains the campaign changes, has the client confirm sign-off, and triggers the promote action. Within seconds the surface shows the campaign version as current-live and the prior version listed as the rollback target. The operator opens the public site in a fresh tab, confirms the new landing page renders, and notes the promotion in the campaign launch log.
Example 2: Reversing a release that broke a checkout step
A site operator promotes a staged version that includes a redesigned checkout. Within ten minutes, the support team reports that customers cannot complete an order on mobile. The operator returns to Stage and Live, confirms the prior version is still available as the rollback target, and triggers the reverse action. The dashboard records the reverse, the public site returns to the prior checkout, and the broken version is removed from current-live. The operator then files the issue against the checkout change for fixing in a future staged version, rather than patching live.
Example 3: Reviewing what is currently in force for a stakeholder question
A client asks a multi-site agency operator which version of their site is currently public. The operator opens Stage and Live for that site and reads off the current-live version, the staged version waiting behind it, and the prior version that would be the rollback target. No editing happens, no movement is triggered — Stage and Live is also a read surface, used to answer release-state questions without triggering any change.
Example 4: Coordinating a two-operator release window
A larger agency runs a release window where one operator owns the staged version and a second operator owns the promotion decision. The first operator prepares the staged version on Friday and confirms in the team channel that the surface shows the expected staged version. On Monday morning, the second operator opens Stage and Live, reads the staged version, has the change owner sign off, and triggers the promote action. Because the surface enforces one in-flight promotion per site, the two operators never collide — the second operator sees the staged version exactly as the first operator left it, and the promotion is recorded against the second operator's account. The team channel ends up with a clean trail: who staged, who promoted, what time the public site changed.
Example 5: Recovering from a misfired rollback decision
A site operator promotes a staged version on Wednesday morning. By midday, the support team reports a stylistic issue on the homepage and asks for a rollback. The operator triggers the reverse action and the site returns to the prior version. Within an hour, the marketing team explains the change was intentional and asks for the version to be promoted again. The operator returns to Stage and Live, finds the previously promoted version still available as the staged version, confirms it matches what was promoted earlier in the day, and triggers promote a second time. The dashboard records both events — the promote, the reverse, the second promote — as a complete trail with operator account and time on each. No ambiguity is left about why the public site moved twice in one day.
Reading the audit trail for a past release
Every promotion and every reverse leaves a record on the Stage and Live surface, attributed to the operator account that triggered it with the time the action completed. The audit trail is the answer for any question that takes the form "what was in force on this site at this moment?" — the team can read it without needing to interrupt the operator who performed the action. The trail also makes post-release retrospectives a single-surface exercise: a retrospective for a release week opens the trail, reads the sequence of promotions and reverses, and produces a clean timeline without re-deriving the history from team-channel messages.
Operator handoffs between time zones
Multi-region teams often hand off a release window across time zones. The handing-off operator confirms the staged version is the version intended for promotion, leaves a note in the team channel, and stops. The receiving operator opens Stage and Live, reads the staged version, confirms it matches the handoff note, and triggers the promotion when conditions are right. The surface is the single source of truth across the handoff — neither operator needs to take screenshots, copy version identifiers, or re-derive state. The handoff note describes intent; the surface confirms current reality.
How Stage and Live differs from content-level publishing
A common confusion is the difference between promoting a staged environment and publishing a single content object. The two operations exist at different scopes and serve different purposes.
Content-level publishing moves one page, one blog post, or one module from draft to live within the current environment. It happens many times a day, often by many operators, and the change is scoped to that single content object. See Publishing Lifecycle for the content-level operation.
Stage and Live operates at the environment level. It moves a prepared environment as a whole — every content object, every configuration, every module state — from staged to live in one governed action. It happens on a much slower cadence, typically tied to release windows or major site updates, and the change affects the entire environment at once.
The two operations are designed to coexist. Day-to-day content publishing happens inside the active environment. Stage and Live is the operation for moving a whole prepared environment forward when the prepared version is ready to become the new active environment.
For an individual page change, a single blog post, or a configuration tweak that does not need environment-level review — use content-level publishing through the relevant authoring surface. For a major site update that touches many objects at once, a redesign launch, or any change that has been prepared in a staged environment for review — use Stage and Live to move the prepared environment into the public role.
If the question is "do I publish this page or do I promote the staged environment?" — the answer is the scope of the change. One object means content-level publishing. A whole prepared environment means Stage and Live.
Common mistakes that this distinction prevents
Two patterns of confusion are worth naming. The first is treating every change as a release event and routing every page edit through Stage and Live — this slows day-to-day work and concentrates routine activity into a heavyweight surface that is shaped for occasional use. The second is treating every release as a page edit and skipping environment review for a change that touches many objects — this skips the review window that staged environments exist for and turns a release into an unreviewed push.
The fast read: the lifecycle handles content, Stage and Live handles environments. Match the surface to the scope of the change and the friction of both surfaces stays at the level it was designed for.