How to switch your SGEN theme safely

The short answer

Switch themes on STAGING first. Audit what's tightly coupled to the current theme. Snapshot before you flip. Then flip on live and verify within the first hour.

What is this for?

You're moving from Theme A to Theme B. Two months of custom styling, page builds, and brand work are on the line. The platform doesn't auto-warn before the switch — once you flip, the live site renders with the new theme immediately.

This page is the safe-switch protocol.

Good use cases

• Your current theme is being deprecated.
• You're rebranding and the new design needs a new theme.
• You inherited a site on an old theme and want to modernize.
• A new SGEN theme ships that matches your direction better.

Example 1 — Rebrand. A team moves from a minimal dark theme to a warm editorial theme to match their new brand identity. They follow the 6-step protocol: snapshot, inventory, staging switch, CSS adapt, Custom Codes check, live switch. Total elapsed: 2 days. No visitor-visible issues.

Example 2 — Deprecated theme. An older theme is being retired by the platform. The team has 30 days notice. They use the protocol to move to the recommended replacement theme, adapting the 8 theme-coupled CSS selectors found in audit.

Example 3 — Inherited site modernization. A new team takes over a site built 2 years ago on a legacy theme. They switch to a modern theme with SG-Builder support. Because Custom CSS was well-structured (design tokens separated from one-off rules), only 12 selectors needed updating.

What NOT to use this for

• Don't use a theme switch to fix a single bug. Patch the bug — or migrate forward with intent — but a wholesale theme change is high-blast-radius for one issue.
• Don't switch themes 2 days before a launch. Allow 1-2 weeks of buffer for cleanup.

How this connects to other features

• Custom CSS — survives the switch but may have theme-coupled selectors that need updating
• Custom Codes — survives but may target theme-specific DOM; audit before switching
• SGB Additional CSS — survives unchanged (scoped to the page, not the theme)
• SG-Core → Templates — what template HTML changes when a theme changes
• SG-Builder → Templates Library — page-level templates that may need rebuild with the new theme
• Operations → Backups — where the pre-switch snapshot lives

Before you start

• Have a snapshot ready before any changes. Create it under the admin → Operations → Backups → Create backup. Name it pre-theme-switch-YYYY-MM-DD.
• Know which 5 pages have the most traffic. These are your priority test pages after the switch.
• Open Custom CSS and note any selectors that reference theme-specific class names (.theme-old-foo, .old-theme-header) — these will break after the switch.
• Allow at least 1-2 weeks of buffer between the theme switch and any marketing launch or campaign.

Where to find it

• Theme picker: the admin → Appearance → Themes
• Theme settings: the admin → Appearance → Theme settings (brand kit, header, footer)
• Snapshot before switch: the admin → Operations → Backups → Create backup
• Staging push: the admin → Operations → Stage & Live

The safe-switch protocol — 6 steps

Steps

1. Snapshot the current site

Before any changes:

• the admin → Operations → Backups → Create backup
• Name it: pre-theme-switch-YYYY-MM-DD
• Confirm the backup is downloadable + restorable

If the new theme doesn't work out, this is your rollback.

2. Inventory what's coupled to the current theme

Open these surfaces and note theme-coupling:

• Custom CSS — search for selectors that reference theme-specific class names (.theme-old-foo, .old-theme-header). Those will be dead after switch.
• Custom Codes — any script that targets theme-specific DOM (e.g., document.querySelector('.theme-old-banner')).
• SGB pages — components that use theme-specific blocks. If your current theme ships a "Theme Carousel" block, the new theme won't have it; rebuild with native components.
• Menus — note position + nesting. Some themes render menus differently.
• Footers — if footer markup is theme-bundled, it won't carry over.
• Templates — if you've customized page templates, those may be theme-scoped.

Write a list. This is your fix-after-switch work.

3. Preview the new theme on staging

• Push the site to staging (the admin → Operations → Stage & Live → Push to staging).
• On staging, switch the theme.
• Walk every major page: home, 3-5 highest-traffic pages, blog index, blog post detail, contact form page, ecommerce/product page if applicable.
• Note every visual regression. Categorize: "design intent change" (acceptable — new theme has new opinions) vs "broken" (must fix).

4. Adapt Custom CSS for the new theme

The Custom CSS file survives the switch — its rules still load. But theme-coupled rules now target nothing.

• Remove dead selectors (references to old theme classes).
• Add new selectors for new theme classes where needed.
• Re-verify CSS custom properties (--brand-blue, etc.) still flow to all the new theme's components. New theme may use different variable names.

5. Verify Custom Codes

If Custom Codes target theme-specific DOM, update or remove them.

Common patterns to check:

• Tracking scripts attaching to specific buttons by class
• Chat widget positioning anchored to theme-specific elements
• Custom analytics that count theme-specific page sections

6. Switch on live + verify within 1 hour

• the admin → Appearance → Theme → switch to new theme
• the admin → Operations → Stage & Live → push staging changes to live (if you've been working on staging only)
• Verify:
• Top 5 pages render correctly
• Forms submit and notification email arrives
• Tracking fires (check GA4 / your analytics within 30 min)
• Mobile + desktop both look right
• Sitemap.xml regenerates correctly

If anything is broken: rollback to the backup from step 1. Don't try to patch under live load.

Anti-patterns

"I'll switch on live and fix issues as they appear"

No. Switch on staging first. Always. Theme switches are NOT cheap to revert under live traffic — your visitors hit broken pages while you're debugging.

"Custom CSS will catch any visual issues"

Only if you authored Custom CSS to be theme-agnostic. If your CSS targets theme-specific class names, much of it dies on switch.

"I'll delete Custom CSS and start fresh"

You'll lose 6 months of styling decisions for no good reason. Adapt, don't restart.

"The new theme looks similar enough"

Look at the source markup. Even "similar" themes ship different DOM structures. Your CSS targets DOM; visual similarity doesn't guarantee selector survival.

"I'll update Custom CSS after the switch"

The right order is: adapt Custom CSS on staging FIRST, then switch on live. If you switch on live first and then try to fix CSS, your visitors see the broken state while you're editing. Always adapt on staging, verify, then switch live.

"I only need to test the homepage"

Test at least 5 pages: homepage, a high-traffic content page, a blog post, a contact/form page, and a product or feature page. Each has different component patterns that interact with the theme differently.

• Your theme needs styling updates — change Custom CSS, not the whole theme.
• You want different colors — update CSS custom properties, not the theme.
• One page needs a different layout — that's an SGB rebuild on that page, not a theme switch.
• You want a new homepage hero — rebuild the hero component, keep the theme.

A theme switch is right when the underlying STRUCTURE of the site needs to change — different page templates, different menu rendering, different footer model. Not when you want a fresh coat of paint.

Where to find it

• Theme picker: the admin → Appearance → Themes
• Theme settings: the admin → Appearance → Theme settings (brand kit, header, footer)
• Snapshot before switch: the admin → Operations → Backups → Create backup
• Staging push: the admin → Operations → Stage & Live

Steps for a low-risk switch (summary)

1. Snapshot the live site.
2. Inventory theme-coupled assets (Custom CSS selectors, Custom Codes DOM targets, SGB theme-specific blocks, menu/footer customizations).
3. Push live to staging.
4. Switch theme on staging.
5. Walk pages — note regressions.
6. Fix Custom CSS + Custom Codes for the new theme's DOM.
7. Re-verify staging.
8. Switch on live during a low-traffic window.
9. Verify within 1 hour: top pages, forms, tracking, mobile.
10. If broken: restore from snapshot.

What success looks like

• Top 5 pages render correctly post-switch.
• Custom CSS still flows where it should — no orphaned selectors visible in DevTools.
• Forms submit; notifications arrive.
• Analytics + tracking fire on the new theme's DOM.
• Mobile breakpoints look right.
• No visitor-visible broken pages during the switch window.
• A team member who wasn't involved in the switch can use the site normally within 10 minutes.

What to do if it does not work

"My buttons lost their styling after the switch." Custom CSS targeted theme-specific button classes. New theme uses different classes. Update Custom CSS selectors.

"My tracking stopped firing." Custom Codes target theme-specific DOM. New theme's DOM differs. Update the selectors in your tracking snippet.

"My homepage layout is broken." New theme uses different header/footer templates. Rebuild the homepage's wrapper structure or pick a theme variant closer to your previous layout.

"My menu disappeared." Theme-specific menu position. Re-configure menu in Appearance → Menus → assign to new theme's menu slots.

"I want to roll back." Restore from the snapshot you took in step 1: the admin → Operations → Backups → restore.

Theme coupling audit — what to look for

Before switching themes, open each surface and look for these coupling signals:

Custom CSS coupling signals

/* These selectors WILL BREAK after a theme switch */.theme-brightside-header {... }.old-theme-btn-primary {... }#brightside-footer-widget {... }/* These are theme-agnostic and WILL survive */:root { --brand-espresso: #3b2010; }body { font-family: var(--font-base); }.btn-primary { background: var(--brand-espresso); }

Theme-agnostic CSS uses custom properties and semantic class names. Theme-coupled CSS uses the old theme's specific class names.

Custom Codes coupling signals

Look for JavaScript that targets theme-specific class names:

// This WILL BREAK after a theme switch (targeting theme-specific DOM)document.querySelector('.brightside-nav-toggle').addEventListener('click',...)// This is theme-agnostic (uses stable ID or data attribute)document.querySelector('[data-nav-toggle]').addEventListener('click',...)

If your tracking or chat scripts target theme-specific classes, update them to use data attributes or stable IDs before the switch.

Timing guidance

Worked example — theme switch

A team moved from their original dark minimal theme to a warmer editorial theme as part of a rebrand.

What they found in the inventory:

• Custom CSS: 2 theme-specific selectors (.old-dark-header, .old-dark-footer) — updated to new theme classes
• Custom Codes: 1 chat widget targeting .old-dark-nav — updated to a stable data attribute
• SGB pages: 3 pages using a "Dark Feature Block" that came with the old theme — rebuilt using native SG-Builder Hero + Text components
• Menus: 2 menus needed re-assignment to the new theme's menu positions
• Theme settings: brand colors and logo needed re-configuration in the new theme's brand kit

Protocol followed:

1. Snapshot created: pre-theme-switch-2026-04-15
2. Inventory completed in 45 minutes
3. Staging switch + CSS/Custom Codes adaptation: 4 hours
4. Review walk: 30 minutes; 2 minor visual regressions found and fixed
5. Live switch at 10pm (low-traffic window): 5 minutes
6. Verification at 10:05pm: all clear

Result: No visitor-visible issues. Total active work time: one afternoon.

Rollback plan

Have this plan ready before you switch live. If the switch reveals issues that can't be fixed in 30 minutes:

1. Don't patch under live load. Every patch adds risk; visitors hit the broken state.
2. Restore from the snapshot. The admin → Operations → Backups → select pre-theme-switch-YYYY-MM-DD → restore.
3. Restoration takes 2-5 minutes for most SGEN sites.
4. After restoration, the live site is back to the pre-switch state. Go back to staging to fix the issue.

A rollback is not a failure — it's the protocol working. The snapshot exists for exactly this reason.

After restoration, go back to staging, identify and fix the issue that caused the rollback, re-verify staging, and re-schedule the live switch for the next low-traffic window.

Related reading

• SG-Core → Templates — what templates change with a theme
• SG-Builder → Templates Library — page-level templates that may need rebuild
• Custom CSS vs Custom Codes vs SGB Additional CSS — what survives where