How to switch SGEN theme safely and keep custom styles

In short. Switching a colour swatch overwrites the hand-tuned values in Styles & Layouts — colours, fonts, button shapes. To survive the switch: (1) create a full-site backup so you can roll back with one click, (2) pin the values you want to keep in a Custom CSS snippet before touching the swatch, (3) apply the new swatch. Custom CSS sits above Styles & Layouts in the cascade — the swatch changes what Styles & Layouts stores, but the CSS snippet wins on every public page load. That's the complete pattern.

On this page: What this protects · Before you start · Steps · What success looks like · Troubleshooting · Quick reference table

How to switch SGEN theme safely

Switching a theme takes one click on a colour swatch and one Save. That speed hides a side effect worth understanding. When you pick a new swatch, SGEN merges the preset's palette, button shape, and typography defaults into Styles & Layouts — the five-panel editor where you hand-tune colours, fonts, and spacing. Any value you customised in those panels can be overwritten by the incoming preset.

Custom CSS snippets are a separate layer. A swatch change does not touch them. But if your snippet references a Styles & Layouts token (like var(--color-primary)) without re-declaring the value, and the swatch overwrites that token, the colour on your public site will change even though your snippet is still Active.

The three-step pattern that prevents this: back up first, write a CSS snippet that pins the values you want to survive, then apply the swatch.

How the cascade works. SGEN applies styles in this order (lowest to highest priority):

1. Swatch preset defaults
2. Styles & Layouts stored values (overrides the preset defaults on save)
3. Custom CSS snippets (override everything above, on every public page load)

A swatch change rewrites layer 2. Layer 3 — your Custom CSS snippets — is never touched. Any value you declare in a snippet wins over the swatch, regardless of how many times you switch swatches. This is what makes the pin pattern reliable.

What is this for?

Use this guide any time you plan to change your site's active colour swatch — redesign, seasonal campaign, or brand refresh — and you have already customised any of the following in Styles & Layouts:

• Global Colors — Primary, Accent, Background, Text, Muted
• Button Styles — radius, hover colour, padding
• Typography — font families or sizes
• Layout — container widths or gutters

It also applies when a team member hand-tuned those values and you are not sure exactly which ones changed. The backup step protects you in either case — if the switch goes wrong, restore and the site reverts to its exact pre-switch state.

This guide also covers a header-config display quirk. After saving on the Appearance → Header page, the sticky-header and CTA-enable toggles can show their previous visual state even when the underlying setting saved correctly. Re-opening the Header page once is enough to confirm.

Good use cases

What NOT to use this for

• Do not skip the backup and rely on memory. Once a swatch is saved, the previous Styles & Layouts values are overwritten. There is no undo button. The only recovery path is a backup or a CSS snippet you wrote before the switch.
• Do not read the header-config toggles as ground truth after a save. The sticky-header, CTA-enable, and top-bar toggles can display their previous state after a save even when the value wrote correctly. Verify by looking at the live public site, not the toggle.
• Do not assume Custom CSS snippets are separate from the main backup. Snippets are database rows. The full-site backup includes every database table — your snippets are protected.

How this connects to other features

• Pick a theme — where you select the colour swatch. Choosing a new swatch triggers the Styles & Layouts merge; that doc covers the swatch grid, the save flow, and the eight chrome presets.
• Customize global styles — the five-panel editor whose stored values a swatch change can overwrite. Knowing which panel owns which token makes it straightforward to write a targeted CSS pin.
• Create a Custom CSS snippet — the override layer above Styles & Layouts. A swatch change never touches your snippets; pinning values there makes them swatch-proof indefinitely.
• Manage site backups — the full-site snapshot you create before switching. Every page, product, setting, Custom CSS snippet, and Styles & Layouts value is bundled into a single .sgen archive.

Before you start

• You are signed in as an SGEN admin with access to Appearance, Custom, and Migration.
• You know which swatch you are switching to and which one you are switching from.
• You have a note of any hex values, font names, or button settings you hand-tuned in Styles & Layouts. If unsure, open Appearance → Theme Editor and check Global Colors, Button Styles, and Typography before proceeding. Write the values down — you cannot retrieve them after the swatch overwrites them.
• You have an incognito or private browser window ready to verify the public site after each step. Regular browser tabs may serve cached CSS from earlier page loads, which gives a false result — incognito starts clean every time.
• The Migration module is enabled on your site (the Migration item appears in the left sidebar). If it is not visible, contact your SGEN platform administrator before continuing.
• If you are switching on a site with active ecommerce, confirm the timing is low-traffic. The switch itself is instant, but a visual regression during a high-traffic window is more disruptive.

Where to go

Three admin panels, visited in this order:

1. Migration → Backups — create the safety net before touching anything.
2. Custom → CSS — write the snippet that protects the values you care about.
3. Appearance → Themes — apply the new swatch.

Steps

1. Create a full-site backup

Open Migration → Backups and click Create a Backup! in the top-right corner. SGEN bundles your entire database — all pages, products, settings, Custom CSS snippets, and every Styles & Layouts value — with your uploads directory into a single .sgen archive. The page appears unresponsive while it runs (about 30 seconds); that is normal.

When the page reloads, a new row appears at the top of the list. Click the filename immediately and rename it to something descriptive:

sgen_yoursite.com-backup-20260505-140312.sgen → rename to:pre-storefront-switch-20260505

A descriptive name matters. Six months from now, pre-storefront-switch-20260505 tells you exactly what state it preserves and when — the date-only auto-name does not.

Keep the Backups panel open in a separate browser tab during the next steps — if anything goes wrong, you want Restore in one click.

Full detail: Manage site backups

2. Note the Styles & Layouts values you want to protect

Open Appearance → Theme Editor and check each of the five panels. Write down every value you hand-tuned — these are the values a new swatch can overwrite.

For example, if you have a custom brand red for CTA buttons, the values needing protection might be:

• Global Colors → Primary: #C83C3C — custom brand red for CTA buttons and links
• Global Colors → Accent: #552C32 — warm dark tone for hover states
• Button Styles → Primary border-radius: 6px (the Storefront preset uses 0px)
• Button Styles → Primary padding: 12px 24px

You do not need to write down values you are happy to let the new swatch overwrite. Target only the specific tokens whose current values you want to survive the switch.

3. Write a Custom CSS snippet to protect those values

Open Custom → CSS and click + Add New. Name the snippet something identifiable (for example, Pinned Overrides). Paste rules that re-declare the values you recorded in step 2.

These rules sit above Styles & Layouts in the cascade. When the new swatch merges its preset values into Styles & Layouts, your CSS snippet continues to override those tokens on every public page load.

Example — snippet that protects a red CTA button and tuned button shape:

/* Pinned Overrides Protects hand-tuned values from swatch changes. Priority: 1 — loads first, acts as the brand baseline. Status: Active. */:root { --color-primary: #C83C3C; --color-primary-hover: #A83030; --color-accent: #552C32;}body .btn-primary,body a.btn-primary { background: var(--color-primary); border-color: var(--color-primary); border-radius: 6px; padding: 12px 24px;}body .btn-primary:hover,body a.btn-primary:hover { background: var(--color-primary-hover); border-color: var(--color-primary-hover);}

The :root block re-declares the CSS custom properties your theme reads. Even after the swatch overwrites Styles & Layouts, the browser applies your snippet on top, restoring the hex values you specified. The explicit body .btn-primary rule adds selector specificity to override any component-level default that does not use the token.

Set Priority to 1 (loads first, acts as the baseline). Set Status to Active. Save.

Full detail: Create a Custom CSS snippet

4. Verify the CSS snippet is rendering before you switch

Open your public homepage in an incognito window. Confirm the CTA buttons show the pinned colour before you touch anything in Themes.

If the button colour is already wrong at this stage, stop. Check: Status is Active; the CSS has no tag-like strings that the save handler stripped; priority does not conflict with another Active snippet. Fix the snippet and confirm the public site before proceeding — once the swatch changes, you lose the clean baseline comparison.

The CTA button should look identical to how it appeared before you created the snippet — the snippet is preserving the existing look, not changing it. That confirms the snippet is cascading correctly.

5. Apply the new swatch

Open Appearance → Themes. The page opens on the Color Swatches tab. Click the swatch card you are switching to — the selected card shows a red check. Scroll to Save Changes and click it.

SGEN merges the preset's defaults into Styles & Layouts. Fields your snippet re-declares will be overwritten in Styles & Layouts storage, but the CSS snippet continues to win on every public page load. Fields you did not pin will adopt the new swatch's preset values — which is exactly what you want for the parts of the design you are intentionally changing.

Full detail: Pick a theme

6. Verify the public site

Open the public homepage in the incognito window. Hard-reload with Ctrl+Shift+R to bypass any cached CSS. Check three things:

1. The overall palette has changed — backgrounds, links, headings reflect the new swatch.
2. The CTA buttons still show the pinned colour with the pinned radius and padding.
3. No obvious visual regressions elsewhere on the page.

If the button colour changed despite the snippet being Active, open Custom → CSS and check the Priority column. A second Active snippet at a higher priority number targeting .btn-primary will win. Raise the Pinned Overrides priority above the competing snippet, save, and hard-reload.

7. Check the header configuration page

After a swatch switch, open Appearance → Header and review the toggle settings.

Header toggle display note. The sticky-header, CTA-enable, and top-bar toggles can show their previous visual state on the initial page render — even when the underlying values saved correctly. If a toggle looks wrong, re-open the Header page once and look again. Do not re-toggle and re-save based on the first visual — doing so risks flipping a setting you intended to keep. Trust the live public site render over the admin toggle state.

Confirm sticky behaviour and CTA visibility directly on the live site. If it matches your intent, the settings are correct.

8. Clean up

Once the public site confirms everything looks right:

• Leave the backup for at least one week. If a visual regression surfaces, the backup is your rollback. After a week of clean live site, rename it to post-[swatch]-switch-confirmed or delete it.
• Delete any test backups created during the process. Go to Migration → Backups, check the rows to remove, and delete. Clean backup list = clear operational record.
• If the switch was temporary, note the original swatch name and date. When the campaign ends, follow the same pattern in reverse — backup, confirm the CSS snippet is still Active, switch back.

What success looks like

After completing all steps:

• Migration → Backups shows a named pre-switch archive (e.g. pre-storefront-switch-20260505).
• Custom → CSS shows your Pinned Overrides snippet with Status Active and Priority 1.
• Appearance → Themes shows the new swatch with the red check active.
• The public homepage in an incognito window, after a hard-reload with Ctrl+Shift+R, renders the new palette sitewide — new background colours, new link colours, new heading treatment — while any pinned values (colours, button radius, padding) remain visually unchanged.
• The backup archive is sitting in your Backups list, ready to restore if a regression surfaces later in the week.

What to do if it does not work

The CTA button changed colour after the swatch switch, despite having a CSS snippet.

Open Custom → CSS and confirm the snippet Status is Active. If active, check the Priority column. A second Active snippet targeting .btn-primary at a higher priority number overrides yours. Open the Pinned Overrides snippet, raise its Priority above the competing snippet, save, and hard-reload.

If no competing snippet exists, check whether your CSS rule uses var(--color-primary) without a :root re-declaration. If the snippet says background: var(--color-primary) but does not also declare :root { --color-primary: #C83C3C; }, the new swatch's updated token value wins. Add the :root block, save, hard-reload.

The public site looks completely wrong after the switch.

Open Migration → Backups, find the named pre-switch archive, and click Restore. The site reverts to the exact state before the switch. Once restored, reassess: were there additional values the new swatch overwrote? Write a more complete CSS snippet, then retry.

The header toggles look wrong after saving the swatch.

This is the known header-config display issue described in step 7. Re-open Appearance → Header. If the toggles still appear wrong on the second load, confirm the live public header — does sticky behaviour and CTA visibility match your intent? If the live site looks correct, the stored value is correct. If the live site is also wrong, re-apply the setting manually and save again.

The Migration module is not in the sidebar.

Contact your SGEN platform administrator to enable the Migration module before proceeding. Do not switch themes without a backup in place.

Styles & Layouts values you did not pin reverted to swatch defaults.

That is the expected behaviour of a swatch change. The only way to recover the prior values exactly is from the backup. Restore the backup, expand the CSS snippet to cover the additional values you want to protect, and retry.

The save flash did not appear after clicking Save Changes in Themes.

Hard-reload the Themes page and try again. If it still does not appear, open the public site in an incognito window — if the new swatch is rendering, the save succeeded and the missing flash is cosmetic only.

The public site still shows the old swatch after a successful save.

This is almost always a browser cache issue. Hard-reload with Ctrl+Shift+R in the incognito window. If the old swatch persists after a hard-reload, open a second incognito window from scratch — the first window may have cached the previous styles during this session. If a fresh incognito window shows the old swatch, the save may not have completed. Return to Appearance → Themes, confirm the correct swatch card has the red check, and save again.

A CSS snippet you know is Active is not rendering on the public site.

Check the snippet's Priority setting against any other Active snippets in the list. A snippet set to Priority 1 loads first — if a second snippet at Priority 1 also targets the same selector, browser cascade determines the winner (typically the later-loading snippet). Assign your Pinned Overrides snippet a unique priority value that does not collide with any other Active snippet. Save, hard-reload.

Examples

Example 1: Preserving typography during a palette-only switch.

Your team wants to change the colour swatch but keep a hand-tuned Poppins/Inter font stack set in Typography. The incoming swatch ships with a different heading font. Before switching, add two lines to the CSS snippet:

:root { --font-heading: "Poppins", system-ui, sans-serif; --font-body: "Inter", system-ui, sans-serif;}

After the swatch switch, every heading still renders in Poppins and every body paragraph in Inter. The palette is new; the type stack is pinned. The same pattern extends to any Styles & Layouts token: find the CSS variable name in Theme Editor, re-declare it in the snippet, and the swatch cannot touch it.

Example 2: Holiday campaign — switch swatch, preserve brand red button, then switch back.

Your site moves to a seasonal swatch for a holiday campaign while keeping a brand-red CTA button (#C83C3C). Before switching: create a backup (pre-holiday-switch), add the colour pin to your CSS snippet, apply the holiday swatch. After the campaign: backup again (pre-revert-[date]), confirm the snippet is still Active, switch back to the original swatch. The CSS pin holds the button colour in both directions — the snippet does not need to change for the rollback.

Example 3: Full overwrite with a backup rollback.

Your site's creative lead decides every visual value should come from the new swatch — no pins, full replacement. They create a backup, switch the swatch, and review the live site. The homepage hero looks fine. The blog index looks fine. The product pages look off — a sale badge has lost contrast against the new background. Rather than patching individual components, the lead restores the backup from Migration → Backups → Restore (one click), adds a single targeted CSS rule for the badge contrast, and retries the switch. The backup turned a potentially messy rollback into a one-click reset with a clean second attempt.

Quick reference — what a swatch change overwrites

To find a token's CSS variable name for any panel, open Appearance → Theme Editor, hover over the field label, or inspect your site's rendered CSS in a browser — the variable names follow the pattern --color-, --font-, and --layout-*.

Full detail: Customize global styles