Shopify Project Rescue

The read starts the day the collaborator request is approved and takes two business days. If the store is losing orders right now, the stabilisation week starts the same day as the read and runs alongside it: access and ownership first, then the cart and checkout fixes, then everything else. You have the written verdict before you commit to anything beyond that week.

No. We assess from the theme, the apps and the store, without involving the previous agency, and the report is written for you. If you still have a contract with them, the report gives you the facts to close it on; if they are gone, nothing in the rescue depends on reaching them. Where they hold accounts in their own name, the first week gets those back into yours.

Never the owner login. We request a collaborator account, which is how Shopify Partners work on a store: you approve the request, you can require a request code so only the people you share it with can ask, and you set the permissions to what the work needs. Collaborator accounts do not count towards your store's user limit, and you can remove ours the day the rescue ends.

Usually, yes. Shopify keeps the published theme and its duplicates, and the theme editor's settings live in files inside the theme, so we start by duplicating what is live and pulling it into a repository. From there every change is a commit. What cannot be recovered is a version that was never saved anywhere, which is why the repository comes first and the fixes second.

Shopify retired the old ways of customising checkout. Shopify Scripts were deprecated on June 30, 2026 and any still published were deactivated; Shopify Functions replace them. On Plus, checkout.liquid is no longer supported on the information, shipping and payment steps and was sunset on the thank-you and order status pages on August 28, 2025. Discounts, shipping rules and payment ordering that lived there have to be rebuilt as Functions and checkout UI extensions, which we have built before.

Often it is part of it. Each app that touches the storefront loads its own script, and apps removed months ago may still have code left in the theme. The read lists every app with what it does, what it costs and what it loads, measures the store on real devices, and separates the apps doing work from the ones doing nothing. The removal and the theme cleanup belong to the stabilisation week when speed is what is losing orders.

It widens what can be fixed. Plus stores can run apps on the information, shipping and payment steps of checkout and use the checkout branding settings, so customisations that broke can be rebuilt properly rather than worked around. Plus also brings B2B features and expansion stores into scope, read in the same two days. The steps and the week-one deliverables are the same.

The data can be reconciled and the rankings can usually be recovered. We count products, variants, customers and orders against the source platform, import what is missing and merge what was duplicated. For rankings we rebuild the URL map, add the redirects that were never set, repair structured data and watch Search Console until the pages are back. How much returns depends on how long the gaps have been open, so the read puts a timeline on it.

The two-day read is free. The stabilisation week is a fixed scope at a fixed price, agreed before it starts, and it stands on its own. Anything beyond that, the takeover to launch or a rebuild, is scoped from the read with estimates per piece of work, so you decide against numbers rather than a retainer. No two stalled stores are in the same state, so there is no price list.

When it would cost clearly more than a rebuild. A theme hacked in a hundred places, a headless build with no path to parity, or a data model every app reads differently can be past the point where fixing is cheaper than starting clean. The read shows the numbers for both, and when rebuild is the honest answer we say so and plan it, keeping your data, your rankings and your launch date.

Yes. The read compares the headless storefront against the theme it was meant to replace, feature by feature, and against the business case that justified it. The options are to finish it to parity, to ship it for the parts of the store it already serves, or to return to a theme and keep the work worth keeping. Which one we recommend depends on the gap and on what the store earns while it waits.

The store is yours, documented and in version control, and your team has been shown how it fits together. If you want someone to keep it that way, ongoing support is available with the same people who did the rescue. If you have your own developer, we hand over to them and stay available for questions. Support is an option after a rescue, never a condition.