The quiet week: the maintenance worth doing now

What maintenance is worth doing in a quiet week?

The work with a deadline you do not control, then the work that removes risk, then everything else. A quiet week is short and attention is finite, so a checklist of forty items gets half done and the half that gets done is the easy half.

The order we use: platform changes with dates on them, integrations that fail silently, apps and code you can delete, the revenue paths you can test in an hour, and a one-page record of who owns what. The rest of this post takes them in that order. If you have a code freeze planned before a sales peak, do this first, because a freeze exists to stop new changes, not to find old problems.

Which apps still depend on script tags?

Any app that injects JavaScript into your storefront through the old script tag mechanism. Shopify’s script tag deprecation notice sets two dates: from October 1, 2026, creating or updating script tags returns an error while existing ones keep running, and on March 1, 2027, Shopify stops injecting them into storefronts. The notice says the deprecation applies to all API versions, so an app pinned to an older version gets no extra time.

This is a quiet-week task because the failure is silent. A reviews widget, a popup or a size guide simply stops appearing on March 1, with no error in your admin. The fix is the app vendor’s, not yours: per the same notice, most apps should move to an app embed block shipped in a theme app extension, and analytics or conversion scripts should move to a web pixel. What you can do now is list your apps, ask each vendor in writing whether it uses script tags and when it will ship the replacement, and decide which apps you will drop if the answer is a shrug.

App embed blocks have a side benefit the notice points out: they show up in the theme editor, where you can see and switch them off, which a script tag never did.

Do you know which API version your integrations run on?

Check it, because the default answer is “whatever it was when someone built it.” Shopify’s API versioning documentation says a new version ships every three months, each stable version is supported for at least 12 months, and when a version is retired, requests are served by the oldest accessible stable version rather than rejected.

That fall-forward behavior is the risk. Your integration keeps responding, but with a newer version’s behavior, and any field the newer version removed stops coming back. The same page says responses carry an X-Shopify-API-Version header showing which version actually answered, and webhooks carry a matching header. If the header differs from the version your code requests, you have already fallen forward. Log it for a week and you will know which of your connectors, middleware or custom apps are on borrowed time.

Shopify also posts its breaking changes in the developer changelog, tagged by type. Read the entries tagged breaking or action required for the APIs you actually call, and ignore the rest. If you have no developer on staff, this is the one item worth handing to whoever supports your store.

What should you delete?

Apps first. An installed app is a cost whether or not anyone opens it: a script on every page, a permission on your data, a monthly charge and a vendor you now depend on. Our app audit walks through measuring each one. In the quiet week, the quick version is enough: list every app, write who uses it and what it does, and uninstall the ones with no answer.

Uninstalling is not always clean. Some apps leave code in the theme or data in metafields after removal. Do it in a duplicate theme or on a quiet morning, check the storefront afterwards, and keep the old theme published-ready so you can roll back.

Then the small stuff: expired discount codes still active, draft products that are not drafts, redirects that point to redirects, and theme sections nobody uses. None of it is dramatic. All of it is the kind of clutter that makes the next incident harder to diagnose.

• Apps with no named owner or no active use
• Discount codes past their intended end date
• Theme sections and snippets no template references
• Old redirect chains and test products visible to customers

Which paths should you test by hand?

The ones that take money or lose customers, tested as a customer, on a phone, logged out. Add a product to the cart, apply a discount code, check out with each payment method you offer, receive the confirmation email, then start a return. Do it in each market you sell to: a UK or Australian buyer sees tax-inclusive prices and a different set of payment methods, and a bug that only appears there will not show up in a US-only test.

Then test the paths that quietly rot: customer login and password reset, back-in-stock and abandoned cart emails, and any form that sends an email to your team. A form that has been dropping messages for three weeks is invisible until you submit one yourself.

Keep the results. A one-page record of what you tested, on which date and what you saw, is the thing you will want when someone says “it worked last month.”

What should be written down before anything breaks?

Who to call, what they own, and what “broken” means. When checkout fails at eleven at night the cost is not the bug, it is the forty minutes spent working out who has the access to fix it. A page listing each integration, its owner, its vendor contact, where its credentials live and how to switch it off takes an hour and pays back the first time it is needed.

Add the boring access checks: can the person on call actually log in to the Shopify admin, the DNS provider and the email service? Staff who left, expired two-factor devices and shared inboxes nobody reads are all quiet-week discoveries rather than incident-night ones.

If you would rather not carry this yourself, this is exactly what a support retainer covers, and our Shopify support service works from the same list.

What should you leave alone?

Anything that changes how the store looks or behaves for customers. A quiet week is a good time to remove risk and a bad time to add it. A theme redesign, a new checkout customization or a new app with broad permissions all belong in a planned release with its own testing, not in a spare week.

The same goes for platform changes that are rolling out on Shopify’s schedule. Shopify has said its redesigned admin is rolling out to merchants in stages from September 15, 2026, and that an app may appear in the old or new admin depending on the shop. That affects the merchant interface, not your storefront. Tell your team to expect two looks for a while, and do not schedule training around it.

Questions this raises

Read next

• Shopify support and maintenance
• The app audit: what every installed app costs you
• The pre-peak code freeze and what it should cover