What a Shopify Maintenance Plan Should Include
A Shopify maintenance plan should be a schedule, not a bucket of hours. The useful version names the work, the cadence and the owner: who bumps the API version your integrations are pinned to, who applies the theme update, who deletes the code an uninstalled app left behind, and what you receive in a month when nothing breaks. A plan that answers only “how many hours” is a retainer wearing a maintenance label.
That distinction matters because on Shopify the thing that breaks your store is rarely a bug you introduced. It is usually a deadline somebody else set. Below: the three clocks that force the work, a cadence you can hold a provider to, and five questions that separate a real plan from a padded one.
Shopify already does the maintenance you are picturing
Servers, security patching, uptime, PCI scope on checkout, scaling for a flash sale — all Shopify’s. On a self-hosted platform that list is maintenance, and it is the single most common thing merchants pay twice for.
What is left is the surface you own, and it is bigger than it looks:
- Your theme, and every code edit anyone has ever made to it.
- The apps you installed, plus the ones you forgot you installed.
- Any custom app or integration built for you — an ERP sync, a warehouse feed, a headless storefront.
- Third-party scripts sitting in your header from campaigns that ended two years ago.
- Content and data debt: dead collections, missing redirects, product data that drifted away from your catalogue.
None of that is Shopify’s problem, and none of it fails loudly on the day it stops being correct.
The three clocks that make a maintenance plan non-optional
The API clock
Shopify releases a new stable API version every three months, at the start of January, April, July and October. Each stable version is supported for a minimum of 12 months, with at least nine months of overlap between consecutive versions.
Read that as an expiry date stamped on everything you own that talks to Shopify. A custom app, an inventory sync, a bespoke integration your integration partner built — each was written against a version, and that version dies inside roughly a year. Nobody invoices you for this. It simply stops working, on the quiet path nobody watches: the order export, the stock push, the tax lookup.
What happens when the clock is ignored is not hypothetical. The retirement of checkout.liquid ran on published dates. Shopify Plus stores had to move the information, shipping and payment pages to Checkout Extensibility by 13 August 2024. The Thank you and Order status pages — including apps using script tags, and anything in additional scripts — followed on 28 August 2025. From January 2026, Shopify began automatically upgrading stores that had not moved, giving 30 days’ notice, and customisations still living in additional scripts, script-tag apps or checkout.liquid were permanently lost in the process. Not degraded. Lost.
Every one of those dates was published years ahead. The stores that lost work were not unlucky. They had nobody whose job it was to read the calendar. That job is the plan.
The theme clock
Where your theme came from decides how much of this is automatic:
| Theme source | Automatic bug & security fixes | Feature updates | Who is responsible |
|---|---|---|---|
| Shopify Theme Store (free or paid) | Yes — applied by Shopify, appearance and settings preserved | Published periodically, available for you to apply | You, to apply and re-test |
| Uploaded or bought outside the Theme Store | No | Only if the original designer ships them to you directly | You, entirely |
| Custom-built theme | No | None exist — you are the designer | You, entirely |
Then the caveat that catches almost everyone. Customisations made in the theme editor survive an update. Code edits are merged, and Shopify tells you afterwards whether each one was successfully included or could not be included. Its own guidance is blunt: save a copy of customised code before you update.
On a store carrying two years of undocumented code changes, a theme update stops being a button and becomes a project, because the first task is working out what was changed and why. Keeping that record current is maintenance work that costs almost nothing while you do it and a great deal when you have not.
The app clock
Apps are the least stable part of a Shopify store, because each one is somebody else’s business decision. They get sold, repriced, rescoped and quietly abandoned. An app that stops being developed does not announce itself; it just stops keeping pace with the platform underneath it.
And uninstalling is not cleanup. Code an app injected into your theme — snippets, wrapper markup, script includes, stylesheet links — routinely survives the uninstall and keeps loading on every page view, sometimes for years, requesting a domain that no longer answers. Nothing visibly breaks. The store just gets slower, and your Core Web Vitals get worse for a feature you stopped paying for.
What should actually be in the plan
Write it as a calendar with owners, and the argument about hours disappears:
| Cadence | Work |
|---|---|
| Every month | Place a real order on a real phone, including a discount code and a payment method you rarely test. Review installed apps against apps actually used. Check Search Console coverage and the 404 log, and add a 301 redirect wherever a real URL died. Read Core Web Vitals field data, not a lab score. Take and keep a dated theme snapshot. |
| Every quarter | Check which API version each owned integration targets and schedule the bump before the expiry. Apply the pending theme update in a duplicate theme, diff the code edits, test, publish. Strip leftover code from apps uninstalled since last quarter. Audit third-party scripts in the header — what is still there, and does it still have an owner. Review staff and collaborator access. |
| Every year | A full accessibility pass against the live store rather than the theme demo. A structured data pass. Content and catalogue hygiene. A review of the plan itself, including whether you still need one. |
Notice how little of that is “fix bugs”. Bugs are the visible part of maintenance and the smallest part. The schedule above is what stops most of them from existing.
What a maintenance plan is not
It is not new features. It is not a redesign. It is not a growth retainer with a different invoice line. Bundling those together is how a plan quietly becomes the largest recurring cost in a store that has not changed in a year.
We publish the honest ranges on our Shopify maintenance cost page, along with the part most pricing pages leave out: a stable store with a small app footprint and nothing custom is usually better served by ad-hoc support than by a monthly retainer. A retainer earns its place when there is a continuous roadmap — not when there is a continuous invoice.
Five questions that expose a padded plan
- What is the response target, and for which severity? A flat “24-hour response” puts a dead checkout and a typo in the same queue. Ask for a severity ladder, and ask what happens outside working hours.
- What is explicitly out of scope? A plan with no exclusions list has not been thought about. The exclusions are where the honesty lives.
- Who owns API version bumps for our integrations? This is the question most maintenance proposals cannot answer, and the one with the largest bill attached when nobody does.
- What do we receive in a month when nothing breaks? The answer should be a document — the checks run, what they found, what was changed. If the answer is “we are on standby”, you are buying insurance, and it should be priced and compared as insurance.
- What happens to the code and the access if we part ways? Theme files, custom app source, repository access, app ownership, and who holds the Shopify Partner collaborator account. Settle it at the start, in writing.
Running it yourself
Plenty of stores should. If your store is stable, your app list is short, and you own nothing custom that calls the Admin API, you do not need a monthly plan — you need the calendar above and someone whose diary it lives in. Our Shopify store launch checklist covers the pre-launch half of the same discipline, and a free Shopify store audit is a reasonable way to find out which of the three clocks is already overdue on your store.
If you would rather it were somebody’s job, that is what our Shopify maintenance and support work is — and the first thing we will tell you is whether you actually need it.
Frequently asked questions
How much should a Shopify maintenance plan cost?
Less than most stores are quoted, and it should be tied to what is on the calendar rather than to a block of hours. Our published ranges, the five factors that move them, and the case for not buying a retainer are on the Shopify maintenance cost page.
Does Shopify maintain my store for me?
Shopify maintains the platform — servers, security patching, uptime, checkout, PCI scope. It does not maintain your theme code, your app choices, the integrations built for you, or the scripts in your header. The split is clean, and it is the whole reason a plan exists.
Will a theme update break my customisations?
Settings you changed in the theme editor carry over. Code edits are merged, and Shopify reports which ones could not be included — which is exactly why the update should happen in a duplicate theme with a dated snapshot behind it, not on the live store on a Friday.
My store is small and stable. Do I still need one?
You still need the quarterly API check if you own any integration, and the annual passes. You probably do not need a monthly retainer. Those are different answers, and a good provider will give you both.
The point
Maintenance on Shopify is not insurance against your store breaking. It is keeping pace with a platform that moves on a published schedule, apps that move on somebody else’s, and a theme that accumulates history whether or not anyone writes it down. Ask any provider to show you the calendar. If they can, it is a maintenance plan. If they can only show you a number of hours, it is a retainer.
Current store performance