What a Shopify Maintenance Plan Should Actually Include

Shopify runs your hosting, security patches and checkout, so it is fair to ask what a maintenance plan is even for. The answer is everything Shopify does not own: your theme code, your apps, your integrations and your data. Those change underneath you every quarter whether you touch them or not. This guide covers what a Shopify maintenance plan should include, what belongs in a separate project, and the questions to ask before you sign one.

Platform facts below are from Shopify's documentation, checked on 28 September 2026.

What does a Shopify maintenance plan actually cover?

The parts of the store that are yours. Shopify keeps the platform online. It does not keep your customised theme compatible with a theme update, check that the app you installed two years ago still behaves, or notice that your ERP sync stopped last Tuesday.

A useful way to think about it: a maintenance plan pays someone to notice problems before your customers do, and to keep small changes small. It is not a development budget in disguise, and it is not an emergency number you call once a year. Plans that blur those three things are where most disappointment comes from.

What changes in a Shopify store without anyone touching it?

More than most merchants expect. Three sources of change arrive on their own schedule:

• API versions. Shopify's versioning documentation says it "releases a new API version every three months," on the first day of January, April, July and October, and "each stable version is supported for a minimum of 12 months." When an app targets a version that is no longer available, "Shopify falls forward and responds using the oldest accessible stable version." That fall forward is where custom apps and integrations start behaving differently without an error message. We covered one such cycle in our note on the October 2026 API retirement.
• Platform deprecations. Features get retired with deadlines attached. Script tags are a current example: from 1 October 2026 apps can no longer create or update them, and from 1 March 2027 Shopify stops loading them on storefronts. Shopify has been emailing affected merchants this month. We explain what that means in our script tags guide.
• Theme and app updates. Theme developers release new versions, and apps change how they inject into your store. Each update is harmless on its own. The combination with your customisations is where things break.

What should be in the monthly work?

A good plan has a fixed list of checks that happen whether or not anything seems wrong. At minimum:

1. App review. What is installed, what is still used, what was removed and may have left code behind. Shopify's own uninstall guidance warns that "some apps add code to your online store theme that isn't automatically removed when you uninstall the app." The method is in our app stack audit guide.
2. Theme update check. Is there a new version of your theme, and what would it take to apply it? Shopify's theme update documentation says code edits carry over only when they "don't conflict with the update," and advises you to "always save a copy of any customized code before updating your theme." Someone should know in advance which of your edits will conflict.
3. Integration health. For any custom app, a look at its logs and webhook delivery health. Shopify removes a webhook subscription after repeated failed deliveries, and an integration can stop silently. We cover how to check in our integration monitoring guide.
4. Speed check. The same key pages measured the same way each month, so a slowdown is caught when it starts rather than when conversion drops.
5. Access review. Staff and collaborator accounts that no longer need access are removed. Former agencies and freelancers are the usual leftovers.
6. Data safety. Exports or a backup app confirmed working, and the theme copied before any change.
7. Upcoming changes. A short list of Shopify deprecations and deadlines that affect your store in the next quarter, so nothing arrives as a surprise.

How should response times and priorities work?

By severity, agreed in writing before anything goes wrong. A plan that promises "fast support" without defining what fast means for which problem will disappoint you on the day it matters.

A workable structure has three levels:

• Store down or checkout broken. Customers cannot buy. This needs a response within hours and work that continues until it is fixed.
• Something important is wrong but the store is selling. A broken filter, a missing section, an integration lagging. This needs a response the same or next working day.
• Changes and requests. New banners, copy edits, small layout changes. These go into a queue with an agreed turnaround.

Ask how the first level works outside office hours and during festive sales, because that is when it gets tested. We describe what to do in the first hour of an incident in our emergency support guide.

What should not be inside a maintenance plan?

New features and redesigns. A maintenance plan keeps the store you have working. Building a new product page layout, adding a subscription model or rebuilding the checkout experience are projects, with their own scope, estimate and testing.

When project work is squeezed into maintenance hours, both suffer. The checks get skipped because the hours went into the feature, and the feature gets built in fragments across months. If a plan includes a bank of hours for small changes, agree in advance what counts as small. A useful line is anything a developer can do, test and ship in a single sitting.

Does a small store need a maintenance plan?

Not always, and it is worth being honest about that. A store on an unmodified Theme Store theme, with a handful of well maintained apps and no custom integrations, has very little that can drift. Shopify handles the platform, the theme developer handles the theme, and the app vendors handle their apps. For that store, a quarterly check of its own, run by the owner with a written list, may be enough. Put the date of that check in the calendar, because a check nobody schedules does not happen.

The picture changes quickly once any of these are true:

• The theme has been edited in code, so updates need someone to merge changes by hand.
• A custom app or integration moves orders, stock or invoices to another system.
• The store runs more than a few apps that touch the storefront, so conflicts become likely.
• Revenue depends heavily on a few sale periods, where a broken day costs far more than a month of maintenance.
• Nobody inside the business can read theme code or app logs.

Two or more of these usually means the store has outgrown ad hoc fixes. The cost of a plan is predictable. The cost of finding a broken integration in the middle of a festive sale is not.

How do you know a maintenance plan is worth paying for?

By what you receive each month, not by what is promised at the start. A plan that is working produces a short written report that says what was checked, what was found, what was fixed and what is coming up. If the report never finds anything, either your store is unusually simple or nobody is looking.

The other test is the incidents you did not have. That is harder to see, which is why the report matters. A note that says "your theme has two edits that will conflict with the next update, we have prepared them" is the plan earning its fee before anything breaks.

What should you ask before signing one?

• What exactly is checked every month, and can I see an example report?
• How are severity levels defined, and what are the response times for each?
• What happens outside office hours and during a sale?
• How many hours of changes are included, and what counts as a change versus a project?
• Who has access to my store, through which accounts, and how is it removed if we stop working together?
• What do I get at the end: documentation, a list of customisations, credentials handed back?

The last question matters more than it seems. A plan you cannot leave cleanly is a dependency, not a service. Our developer handover checklist lists what you should be able to walk away with.

Want your store's maintenance needs reviewed?

Free maintenance review. Get in touch or email hello@exactwhy.com with the subject "Maintenance review" and your store URL. Tell us which apps and integrations you run. We reply within 4 hours with the risks we would check first and what a sensible monthly routine looks like for your store.

Monthly maintenance. If you want someone to own it, we run the checks every month, send a written report, handle changes within an agreed turnaround and respond to incidents by severity, including during sales.