A theme update can bring useful features, bug fixes and improvements to accessibility or performance. For a lightly customised store it may be straightforward. For a storefront with bespoke navigation, product features and app integrations, it deserves a controlled migration.
The aim is to preserve the behaviour the business relies on while taking advantage of the new version. Copying every old file into a new theme can defeat the purpose of the upgrade; publishing a clean version without checking customisations can remove important functionality.
The process below gives merchants and developers a shared checklist for deciding what to carry forward, what to rebuild and how to verify the result.
Why upgrade your Shopify theme?
Start with the theme developer’s changelog. Look for fixes relevant to your store, new configurable sections, accessibility changes and support for capabilities you plan to use. A release number on its own is not a business case for migration.
Some updates remove the need for a custom workaround. Others improve code structure or address an issue you have already encountered. Compare those benefits with the migration and testing effort. Not every update is urgent, and an update does not automatically make a heavily modified store faster.
Check how updates are distributed for your particular theme. Shopify documents the supported routes in its theme update guidance; themes obtained outside the Theme Store may need a separate process through their developer.
What happens to custom code during a theme update?
Shopify’s supported update flow copies theme-editor customisations and can include code edits when they do not conflict with the update. That is useful, but it is not a guarantee that every customised feature will transfer or behave correctly. Review the update message and test the resulting draft theme.
Consider a custom mega menu built from a header snippet, JavaScript and theme settings. A newer header may use different markup and interaction logic. Moving only the snippet can leave its script looking for elements that no longer exist. Product information blocks may reference particular template settings; collection filters may depend on both configured filter data and the theme’s rendering.
Even when settings carry over, the connections between those settings and the code need checking. Installing a fresh theme version is also different from applying an update to an existing theme: do not assume a new copy already contains the custom files and templates you need.
Step 1: Audit the existing theme
Keep a duplicate or download of the current theme and record which version is live. Use source control where possible so that the migration has a reviewable history. A duplicate protects theme files and settings; it is not a full backup of the store’s products, orders or external services.
- Identify changed Liquid templates, custom sections and snippets, and the templates that use them.
- Review CSS and JavaScript, including scripts inserted directly into layout files.
- Record JSON templates, section settings, app blocks and app embeds that staff rely on.
- Map metafields and metaobjects to their product, collection or content templates.
- Check navigation, predictive search and collection filtering beyond the default configuration.
- Record app-owned code and ask the provider which installation or migration steps apply.
Compare the customised theme with a clean copy of the same original version if one is available. The differences help separate business-specific changes from theme features. Comparing only against the newest version mixes the developer’s changes with your own and makes it easier to miss a dependency.
Make a short inventory with a purpose, location and acceptance check for each feature. “Delivery message under the product price, driven by a product metafield” is a better migration entry than “custom product code”.
Step 2: Review the new theme version
Add the updated theme as an unpublished draft and inspect it before editing. Read its release notes, compare product and collection templates, and check whether the section and block structure has changed. Preview several representative products rather than a single default template.
Classify each inventory item as migrate, rebuild or retire. If the new theme provides a suitable native block, use it rather than preserving a bespoke substitute without a reason. If an old app has been replaced, confirm that its functionality is no longer needed before carrying its scripts into the new version.
Avoid copying entire old files over newer ones. That can remove bug fixes and introduce outdated assumptions. Move the smallest relevant change, then adapt it to the updated structure. If a change is too intertwined to isolate, make that risk visible in the scope.
Step 3: Migrate functionality deliberately
- Describe the business purpose and the customer or staff action the feature supports.
- Check whether the updated theme can meet that purpose through its existing settings.
- Review dependencies on snippets, scripts, apps, metafields and template settings.
- Adapt or rebuild the feature in the new architecture, keeping unrelated edits separate.
- Test the feature independently before combining it with the rest of the migration.
Use configurable sections and blocks when staff need control over content. A developer should also test what happens when a block is moved, removed or left empty. Hard-coding a campaign message into a shared product template makes the next merchandising change unnecessarily dependent on code.
For the mega-menu example, verify the navigation data, desktop interaction, mobile expansion and keyboard focus together. For product blocks, check both a populated metafield and a product with no value. These small variations often expose assumptions hidden by a perfect preview product.
Step 4: Test the customer journeys before publishing
Create a checklist tied to real templates and features. The homepage cannot prove that variant selection, cart behaviour or an unusual product layout still works. Use products covering the combinations the business actually sells.
Buying and discovery
- Select available, unavailable and sold-out variants; check price, imagery and the item sent to the cart.
- Add products, change quantities and remove items in the cart drawer and cart page.
- Check collection filters, sorting, pagination and the state after clearing filters.
- Test predictive search, full search results and an empty search response.
Presentation, apps and accessibility
- Check desktop and mobile navigation, including keyboard focus, Escape behaviour and expanded menus.
- Verify app embeds and relevant review, subscription, recommendation or delivery widgets.
- Inspect narrow phones, tablets and wide layouts with long titles and real content.
- Check labels, focus visibility, headings, contrast and essential controls without a mouse.
- Review unusual product templates, empty states and any market or currency variations in scope.
Record which integrations cannot be fully exercised in a theme preview and how they will be checked at launch. Preview testing is valuable, but third-party behaviour can depend on the published theme or a provider’s own environment.
Step 5: Publish with a rollback plan
Choose a publication window when someone can verify the store and respond if a problem appears. Keep the previous theme available, record its version and agree who can decide to switch back. Avoid combining an untested app replacement and a major theme upgrade into one unexplained release.
Immediately after publication, check navigation, product selection, cart actions and the hand-off to checkout. Complete an approved test purchase only with the merchant’s permission and a suitable payment/testing arrangement.
Republishing the previous theme can restore its presentation and theme code. It does not automatically undo product-data edits, app configuration, external-system changes or transactions. List any such changes separately so rollback means something concrete.
Should you upgrade the theme yourself?
A lightly customised theme using standard settings may be manageable with a draft copy and a thorough checklist. A store with undocumented code, complex product logic or several operational integrations benefits from a technical assessment before migration.
If upgrades repeatedly become difficult, improve the change history and dependency documentation as part of the work. Our Shopify maintenance guide explains how that preparation becomes part of ongoing support. After a major upgrade, use the performance optimisation workflow to check loading and interactions too.
A successful upgrade preserves important business functionality and leaves the storefront easier to maintain. Explore our theme development services or ask Simply Bold to assess your theme upgrade before committing to the migration.
