Back Up Your Theme Customizations Before Updating

A step-by-step routine to back up a Shopify theme before updating: duplicate, export, list your custom files, and re-apply them so nothing gets lost.

4 min readUpdated

Part of our guide to Update Your Shopify Theme Without Losing Customizations.

A theme update installs a fresh copy of the theme's code, so any customization you made by editing files can disappear. The fix is not complicated: take a full, restorable backup before you click Update, and keep a record of exactly which files you customized so you can put them back. This guide is that routine, start to finish.

It sits under Update your Shopify theme without losing customizations, which explains why file edits get replaced. Here we focus on the practical steps.

Step 1 — Duplicate the theme

Your first backup is a full copy of the current, working theme. In your Shopify admin, go to Online Store → Themes, find the theme you are about to update, open its ⋯ menu, and choose Duplicate.

Rename the copy so you know what it is and when you made it — for example Dawn — backup 2026-07-05. This duplicate is unpublished and sits in your theme library. If an update goes wrong, you can publish this copy to restore the exact state you had before, code and settings included. Do this every single time, before any update.

Step 2 — Export the theme file

A duplicate lives inside your store. Also keep a copy outside it, in case you lose admin access or want the files on your own machine. From the theme's ⋯ menu, choose Export. Shopify emails a download link for a .zip of the theme's files. Save it somewhere durable and dated.

If you work with the Shopify CLI, you can pull the theme to a local folder instead, which is easier to diff later:

# Pull the live theme into a local directory
shopify theme pull --store your-store.myshopify.com --path ./theme-backup

# Or pull a specific theme by id
shopify theme pull --theme 123456789 --path ./theme-backup

A local checkout also lets you put the theme under version control, which turns "what did I customize?" into a git diff you can answer in seconds.

Step 3 — List every custom file

This is the step people skip, and it is the one that saves you. Open Themes → ⋯ → Edit code on the theme you are about to update, and write down every file that is not part of the theme's standard release. Check these folders:

  • sections/ — any section file you or a developer added (not shipped by the theme).
  • snippets/ — custom snippets you created and {% render %} somewhere.
  • assets/ — CSS or JS files you added, plus custom rules pasted into the theme's own stylesheets like base.css or theme.css.
  • templates/ — any template .liquid or .json you edited by hand.
  • layout/theme.liquid — code you inserted (tracking scripts, meta tags, custom markup).

For each one, note the file path and, ideally, save its full contents to your backup alongside the exported .zip. A short list like this is your re-apply checklist:

CUSTOM FILES — Dawn (as of 2026-07-05)
- sections/feature-banner.liquid        (custom section)
- snippets/size-chart.liquid            (custom snippet)
- assets/custom.css                     (added file, linked in theme.liquid)
- layout/theme.liquid                   (added GA4 script in <head>)
- templates/product.liquid              (edited: added size-chart render)

If you are not sure whether a change was a file edit or an editor setting, the breakdown in does a theme update delete your customizations tells you which side of the line each type of change falls on.

Step 4 — Update on a copy, not the live theme

Rather than updating your live theme in place, update the duplicate you made in Step 1 (or a fresh duplicate). Apply the theme update to that copy, re-apply your custom files from the Step 3 list, and preview it thoroughly. Only when it looks right do you publish it. Your original stays live and untouched the whole time, so there is never a moment where a broken update is facing customers.

Step 5 — Re-apply and verify

On the updated copy, add each file from your list back into the code editor, and re-insert any edits you made to shared files like theme.liquid. Then walk the storefront: home, a product page, a collection, cart, and checkout entry. Confirm every custom section renders, styles look right, and any scripts still fire. Compare against the backup copy side by side if anything looks off.

Make the re-apply step unnecessary

Steps 3 and 5 exist because custom files do not travel with an update. If a section is something you rely on release after release, you can take it out of theme files altogether. A section rendered by an app through a Theme App Extension is not a theme file, so an update never replaces it and there is nothing to re-apply.

That is how SectionGuard works: your sections and their settings live with the app, so they come through every theme update automatically. It does not replace the backup discipline above for the theme's own files — it removes your custom sections from the list you have to re-apply each time. The trade-offs of keeping sections in files versus in an app are laid out plainly in the honest comparison.

Back up every time regardless. A dated duplicate plus an exported .zip is the cheapest insurance you will ever buy against a bad update.