Understanding the mechanism tells you what to avoid.<\/p>\n
A Shopify theme update is effectively a new copy of the theme’s files. It does not merge with your version \u2014 someone has to reconcile the two. Anything you changed inside a file the developer also changed is a conflict that a human must resolve by comparing versions and deciding what to keep.<\/p>\n
So the amount of work an update costs is almost exactly proportional to how many of the theme’s own files you modified. Customisations that live outside those files cost nothing. Customisations scattered through them cost days.<\/p>\n
That is the whole principle. Everything below follows from it.<\/p>\n Use theme settings first.<\/strong> Anything achievable in the customiser survives updates untouched, because settings are stored separately from theme code. Exhaust this before writing anything.<\/p>\n Add new section files rather than modifying existing ones.<\/strong> A new section you created is yours alone and will never conflict. A modified copy of the theme’s own section conflicts with the updated version every time. This single practice prevents most update pain.<\/p>\n Put custom CSS in one deliberate place.<\/strong> A single custom stylesheet, or a clearly delimited block with comment markers. When you update, you reapply one file instead of hunting through a diff of every stylesheet.<\/p>\n Put custom JavaScript in its own file too,<\/strong> loaded separately rather than appended to the theme’s own scripts.<\/p>\n Avoid editing core files wherever possible.<\/strong> The layout file, the main product template, and the cart are the ones most likely to change upstream and the most painful to reconcile. Where you must edit them, keep the change as small as possible \u2014 ideally a single include pointing at your own file, so the logic lives somewhere safe.<\/p>\n Use snippets for anything reused.<\/strong> Logic in a snippet of your own can be included from several places and maintained in one.<\/p>\n Comment every customisation.<\/strong> What it does, why it exists, when it was added, and by whom. Six months later this is the difference between a one-hour update and a day of archaeology. Use a consistent marker so customisations can be found with a search.<\/p>\n Use metafields for content<\/strong> rather than hard-coding text and values into templates. Content in metafields belongs to your products and pages, so it survives both updates and theme changes entirely.<\/p>\n Use version control.<\/strong> So you can see exactly what you changed, which turns an update from an investigation into a diff. This is the single most valuable piece of infrastructure in this article.<\/p>\n Keep a customisation log.<\/strong> A simple document listing each change, the files touched, and the reason. Unglamorous, and the thing every developer inheriting a store wishes existed.<\/p>\n Never work directly on the live theme.<\/strong> Duplicate, change, test, publish. This is basic and routinely ignored under time pressure.<\/p>\n The opposite list, since recognising these in your own store is useful.<\/p>\n Editing the theme’s own section and template files directly,<\/strong> repeatedly, over years, by different people.<\/p>\n Scattering CSS through existing stylesheets<\/strong> wherever seemed convenient at the time.<\/p>\n Appending JavaScript to the theme’s existing script files.<\/strong><\/p>\n Hard-coding content into templates<\/strong> \u2014 promotional text, banner copy, shipping messages \u2014 which then has to be found and migrated on every change.<\/p>\n Pasting app snippets into core files<\/strong> and leaving them after the app is removed.<\/p>\n Working directly on the live theme,<\/strong> so there is no record of what changed or when.<\/p>\n No comments and no log,<\/strong> leaving every customisation to be reverse-engineered.<\/p>\n Multiple developers with no shared convention,<\/strong> each solving things their own way.<\/p>\n Most stores do all eight, not through incompetence but because each individual instance is a small shortcut under deadline pressure. The cost arrives later and all at once.<\/p>\n The process, when you do have customisations.<\/p>\n Duplicate your live theme<\/strong> and keep that copy untouched as a known-good fallback.<\/p>\n Get the new version of the theme<\/a><\/strong> as a separate unpublished theme.<\/p>\n Compare the two,<\/strong> ideally with a proper diff. You need to know what the developer changed and where your customisations sit.<\/p>\n Reapply your customisations to the new version,<\/strong> rather than applying the update to your customised theme. This direction is counterintuitive and considerably easier, because you are adding known changes to a clean base rather than resolving unknown conflicts.<\/p>\n Work from your customisation log,<\/strong> which is why keeping one matters.<\/p>\n Test everything.<\/strong> Every template type, every custom feature, all app blocks and embeds, on mobile and desktop. Place a test order.<\/p>\n Check the things that break silently<\/strong> \u2014 structured data, tracking scripts, app blocks that need repositioning, and any content that lived in sections.<\/p>\n Publish at a quiet hour<\/strong> and verify on production.<\/p>\n Keep the previous theme<\/strong> for a few weeks.<\/p>\n This is a half-day for a lightly customised theme and a multi-day project for a heavily modified one, which is precisely the cost difference the practices above are buying you.<\/p>\n A supplements retailer had been on the same premium theme for four years, with changes made by three different developers and the founder. None of it was documented, there was no version control<\/a>, and most changes had been made directly on the live theme.<\/p>\n When their theme developer released an update containing a fix they needed, updating meant reconciling four years of undocumented modifications against a substantially changed codebase. Two developers quoted for it. Both recommended rebuilding instead, at considerably more than the update should have cost.<\/p>\n What we did instead was stage the recovery.<\/p>\n First, an audit: diff their live theme against a clean copy of the version they had started from, which produced a complete list of every modified file and every change. That took two days and gave us, for the first time, a factual inventory.<\/p>\n Then triage. Roughly a third of the changes were obsolete \u2014 relating to apps removed years earlier or campaigns long finished \u2014 and were simply dropped. Another third could be reimplemented as settings, metafields, or new standalone sections, which meant they would never conflict again. The remaining third actually needed to live in core files, and those were reduced to minimal includes pointing at our own snippets.<\/p>\n We then built the current theme version fresh and applied that reduced, documented set of customisations to it.<\/p>\n The project took three weeks, against a rebuild quote of several months. More usefully, their next update took half a day, because the customisations were now documented, mostly outside core files, and under version control.<\/p>\n The recovery cost about what two years of careless customisation had saved them. Which is the honest accounting of this whole subject.<\/p>\n The recovery path, in order.<\/p>\n Diff against a clean copy<\/strong> of whatever version you started from. This gives you the inventory you do not currently have.<\/p>\n Triage ruthlessly.<\/strong> A meaningful share of accumulated customisations are obsolete \u2014 for removed apps, finished campaigns, or products you no longer sell. Dropping them is free.<\/p>\n Reimplement what you can outside core files.<\/strong> Settings, metafields, and new standalone sections. This is the work that prevents recurrence.<\/p>\n Minimise what must stay in core files,<\/strong> reducing each to a small include.<\/p>\n Document everything as you go,<\/strong> since the absence of documentation is the actual problem being solved.<\/p>\n Set up version control and a staging theme<\/strong> before doing any of it.<\/p>\n Then decide whether to update or rebuild,<\/strong> with real information rather than a guess. Sometimes rebuilding really is right \u2014 and you should only conclude that after the audit, not before.<\/p>\n If you are beginning a new store or a new theme, the infrastructure worth having on day one.<\/p>\n Version control, connected to your theme.<\/strong> Non-negotiable for any store with custom work.<\/p>\n A staging theme<\/strong> that mirrors live, used for all changes.<\/p>\n A naming and commenting convention<\/strong> agreed in writing, so multiple developers are consistent.<\/p>\n A customisation log,<\/strong> kept as work happens rather than retrospectively.<\/p>\n A rule that content goes in metafields,<\/strong> not in templates.<\/p>\n A rule that new functionality is a new section,<\/strong> not a modification.<\/p>\n A scheduled update check,<\/strong> quarterly, so you never fall several versions behind.<\/p>\n An agreed definition of done<\/strong> that includes documentation, because otherwise it will not happen.<\/p>\n None of that is expensive. All of it is cheaper than the recovery described above, and it is exactly what an ongoing maintenance arrangement<\/a> should be delivering as a matter of course.<\/p>\n The decision that matters most in day-to-day work is where a given change should live. This is the mapping worth internalising.<\/p>\n Theme settings.<\/strong> Colours, typefaces, logo, spacing options, section configuration, and anything the customiser exposes. Survives everything, including a theme update and in many cases a theme change. Always the first option.<\/p>\n Metafields and metaobjects.<\/strong> Product specifications, care instructions, ingredient lists, size tables, delivery information, badges, and any structured content that varies by product or page. This data belongs to your store rather than your theme, which means a future theme change keeps it entirely. Content hard-coded into templates has to be found and migrated every time.<\/p>\n Your own section files<\/a>.<\/strong> Any new page component \u2014 a comparison block, a lookbook row, an FAQ accordion, a bundle display. Because the file is yours and the theme developer will never ship a file with that name, it cannot conflict. This is where the majority of custom functionality<\/a> should live.<\/p>\n Your own snippets.<\/strong> Reusable logic included from several places, maintained once.<\/p>\n A dedicated custom stylesheet.<\/strong> All your CSS, in one file, loaded after the theme’s own. Specificity handles the overrides and you have exactly one file to reapply after an update.<\/p>\n A dedicated custom JavaScript file.<\/strong> Same principle.<\/p>\n App blocks.<\/strong> Where an app supports them, placing app content through app blocks in the customiser rather than pasting snippets into templates means removing the app removes its code cleanly. This alone prevents the orphaned-code problem that slows so many stores.<\/p>\n Core theme files \u2014 last resort only.<\/strong> The layout, the main product template, the cart. When unavoidable, insert a single line including your own snippet rather than writing logic inline, so the substance lives somewhere safe and the conflict surface is one line.<\/p>\n Nowhere at all.<\/strong> Worth saying: some requests are better declined than built. A one-off promotional element hard-coded into a template for a two-week campaign will still be there in three years, and somebody will have to work out whether it matters.<\/p>\n Most stores accumulate customisations from several people over years, and that is where conventions break down. A few things that keep it coherent.<\/p>\n Write the conventions down,<\/strong> once, and include them in every brief. Where CSS goes, where JavaScript goes, the comment format, the naming pattern for custom sections and snippets, and the rule about core files. A single page is enough.<\/p>\n Require the comment marker.<\/strong> A consistent marker such as a project prefix means anyone can find every customisation with one search. This is the cheapest thing on this list and the most useful to whoever comes next.<\/p>\n Require the log entry as part of done.<\/strong> A change is not finished until it is recorded. Without this rule it will not happen, because documentation is always the thing deprioritised when a deadline approaches.<\/p>\n Give every developer the same starting point.<\/strong> Version control access, the staging theme, the conventions document, and the existing log. Developers who are not given these will reasonably invent their own approach.<\/p>\n Review before merging.<\/strong> Even a brief look at what changed catches core-file edits that should have been sections.<\/p>\n Ask departing developers to document.<\/strong> Covered properly in the handover article in the previous batch, and the single highest-value thing a leaving developer can do.<\/p>\n Do not let urgency suspend the rules.<\/strong> The exception made under deadline pressure is how every unupdatable theme began, and it is always made with the intention of tidying it up later.<\/p>\n Worth covering, because stores that cannot update often conclude they are not missing much. They usually are.<\/p>\n Platform feature support.<\/strong> Shopify ships new capability continually \u2014 new section and block types, cart and checkout behaviour, metafield handling, markets and localisation features. Theme updates are frequently what makes that capability usable. A store several versions behind is paying for platform features it cannot access.<\/p>\n Performance improvements.<\/strong> Theme developers refine asset loading, image handling, and script execution over time. These arrive silently in updates and are among the cheapest speed gains available to you.<\/p>\n Accessibility fixes.<\/strong> Keyboard navigation, focus states, contrast, and screen reader behaviour all improve across versions. This matters legally in some markets and in all cases affects real customers.<\/p>\n Bug fixes,<\/strong> including ones you have not noticed \u2014 edge cases in variant handling, cart behaviour, or mobile layout that affect a small share of sessions.<\/p>\n Security and dependency updates,<\/strong> where a theme relies on third-party libraries.<\/p>\n App compatibility.<\/strong> As apps evolve against current theme architecture, older themes drift out of step and integrations<\/a> become fiddlier.<\/p>\n The cumulative point.<\/strong> Any single update is easy to skip. Four years of skipped updates is a theme that cannot use current platform features, is slower than it needs to be, has accessibility problems, and fights your apps \u2014 at which point someone proposes a rebuild, and the rebuild is attributed to the theme being old rather than to the decision not to maintain it.<\/p>\n Quarterly, diarised.<\/strong> Check whether an update exists and read what changed. Five minutes.<\/p>\n Decide whether it warrants applying now.<\/strong> A security or accessibility fix does. A minor cosmetic change can wait for the next cycle.<\/p>\n Apply to an unpublished copy.<\/strong> Never to the live theme.<\/p>\n Work from your customisation log,<\/strong> reapplying known changes to the clean new version rather than merging the new version into your modified one.<\/p>\n Test the full set.<\/strong> Every template type, every custom feature, app blocks and embeds, tracking scripts, structured data, and a real test order.<\/p>\n Check what breaks silently.<\/strong> Section content, tracking, app block placement, and structured data are the four that look fine and are not.<\/p>\n Publish at a quiet hour,<\/strong> then verify on production rather than assuming staging behaviour carries over.<\/p>\n Keep the previous theme<\/strong> for a few weeks as a fallback.<\/p>\n Record what you did<\/strong> in the log, including anything the update changed that you had to adapt to.<\/p>\n For a well-maintained theme this is a half-day each quarter. For a neglected one it is a project \u2014 which is the entire argument for the practices above.<\/p>\n Theme updates break because customisations live inside files the theme developer also changes. The cost of an update is proportional to how many of the theme’s own files you modified, which makes the whole discipline simple: keep your changes outside them.<\/p>\n Use settings first, add new sections rather than editing existing ones, keep custom CSS and JavaScript in their own files, put content in metafields, comment everything, log what you changed, and use version control and a staging theme.<\/p>\n If you are already stuck, the recovery is an audit, a ruthless triage, and reimplementing what you can outside core files. It is less work than the rebuild you will otherwise be quoted \u2014 and it is the difference between a store you can develop<\/a> for years and one that has to be replaced every time the platform moves. Good customisation<\/a> is not about avoiding changes. It is about making them somewhere they will survive.<\/p>\n It depends entirely on where those customisations live. A theme update is effectively a fresh copy of the theme’s files rather than a merge, so anything you changed inside a file the developer also changed becomes a conflict a human must resolve. Customisations held in theme settings, metafields, your own standalone section files, and separate CSS and JavaScript files survive updates untouched. Changes scattered through the theme’s own templates and stylesheets are what cost days of reconciliation \u2014 and the amount of pain is almost exactly proportional to how many core files were modified.<\/p>\n Exhaust the theme settings first, since anything achievable there survives updates automatically. For anything more, add your own new section files rather than modifying the theme’s existing ones, keep custom CSS and JavaScript in their own dedicated files, and store content in metafields rather than hard-coding it into templates. Where you must edit a core file, reduce the change to a small include pointing at your own snippet. Comment every customisation with what and why, keep a log, use version control, and never work directly on the live theme.<\/p>\n Audit before deciding anything. Diff your live theme against a clean copy of the version you originally started from, which produces a complete inventory of every modified file. Then triage: a surprising share of accumulated customisations turn out to be obsolete, relating to removed apps or finished campaigns, and can simply be dropped. Reimplement what you can as settings, metafields, or new standalone sections so it never conflicts again, and reduce whatever must stay in core files to minimal includes. That recovery is usually far cheaper than the rebuild you will be quoted.<\/p>\n Yes, for any store with custom work, and it is the single most valuable piece of infrastructure in this whole area. It gives you a precise record of what changed and when, which turns a theme update from an investigation into a diff. It also means multiple developers can work without overwriting each other, you can revert a bad change cleanly, and a new developer inheriting the store can see the history rather than guessing. Stores without it typically cannot answer basic questions about their own theme.<\/p>\n Check quarterly and update deliberately rather than either never or immediately. Read the release notes to see what actually changed, apply the update to an unpublished copy, test your customisations and app blocks thoroughly, then publish at a quiet hour. Stores that never update eventually sit several versions behind on a theme whose improvements they are paying for and not receiving, and accumulate incompatibilities that make the eventual catch-up far harder. Stores that update immediately without testing occasionally break something on a Friday afternoon.<\/p>\n","protected":false},"excerpt":{"rendered":" Most Shopify stores reach a point where they cannot update their theme. Not because updating is hard, but because years of customisation have been made in ways that…<\/p>\n","protected":false},"author":7,"featured_media":4423,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[377],"tags":[],"class_list":["post-4453","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-themes-design"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t![\"Two](\"https:\/\/www.liquidwebdevelopers.com\/blog\/wp-content\/uploads\/2026\/10\/277-updatable-customisation-1.svg\")
<\/span>The practices that keep a theme updatable<\/span><\/h2>\n
<\/span>The practices that destroy updatability<\/span><\/h2>\n
<\/span>How to update a customised theme safely<\/span><\/h2>\n
<\/span>A worked example: the store that could not take a security update<\/span><\/h2>\n
<\/span>If your theme is already unupdatable<\/span><\/h2>\n
<\/span>Setting this up properly from the start<\/span><\/h2>\n
<\/span>What belongs where: a practical map<\/span><\/h2>\n
<\/span>Working with multiple developers<\/span><\/h2>\n
<\/span>What updates actually bring you<\/span><\/h2>\n
<\/span>A reasonable update routine<\/span><\/h2>\n
<\/span>The bottom line<\/span><\/h2>\n
<\/span>Frequently asked questions<\/span><\/h2>\n
<\/span>Will updating my Shopify theme break my customisations?<\/span><\/h4>\n
<\/span>How do I customise a Shopify theme safely?<\/span><\/h4>\n
<\/span>What should I do if my theme cannot be updated anymore?<\/span><\/h4>\n
<\/span>Should I use version control for a Shopify theme?<\/span><\/h4>\n
<\/span>How often should I update my Shopify theme?<\/span><\/h4>\n