What happened to your Stocky data on 31 August 2026

Shopify retired Stocky on 31 August 2026. Most of the advice written before the date was about picking a Stocky replacement. That was always the second question. The first one is narrower: which of your numbers lived in Stocky, and which live in Shopify?

They were never the same set, and only one of them went away.

No, it was not extended — but the export door is still open

Enough people are repeating that Stocky’s shutdown got pushed back that it is worth saying plainly: it did not. Shopify’s migration documentation still gives 31 August 2026 as the end. The sentence being misread is this one:

You’ll have read-only access to export your data for at least 90 days after that date.

That is not a reprieve for Stocky. Stocky is finished as a working app. What stayed open is the door to your own records, and only to read them. At least 90 days from 31 August lands somewhere around the end of November — and “at least” is carrying a lot of weight in that sentence. Plan against the plain reading of it, not the generous one.

It is also why you may still see Stocky listed in the App Store. A listing that renders is not an app that runs.

If you have not pulled your data yet, that is this week’s job rather than next month’s. Our Stocky export readiness check scores an export against what a replacement actually needs, and names the gaps.

What an export quietly flattens

Worth knowing before you treat a CSV as your history: Stocky’s exports are state, not events. Anything that happened as a sequence arrives as its result.

• A purchase order received in three deliveries can come back as one received quantity at one cost. Open a PO you received in batches and check whether each delivery kept its own cost, while you still can.
• Where freight and duty were spread across an order, the allocated unit cost can survive without the lines that produced it. You can reproduce that number and you cannot recompute it — so the first time a quantity changes, the arithmetic is gone and only its answer is left.
• Stocktake history is not a re-importable object anywhere, in Stocky or in anything replacing it. If you ran physical counts through it, pull them out as a CSV and expect to keep them as records rather than as data.

Pull every report it offers, not the two or three that look important today.

What stayed where it was

Your products, variants, SKUs, barcodes and inventory levels are Shopify records. Stocky read them. They were unaffected by the shutdown, and you did not need to export them to keep them.

If the worry was “did I lose my stock counts”, the answer is no. They are still in Shopify, where they always were.

What left with Stocky

The numbers Stocky added on top are the ones that went with it:

• Bin and location codes — where a thing lives in your stockroom.
• Minimums and maximums — the thresholds you set per product.
• Purchase order history — suppliers, costs, receiving records.
• Stocktake history — past counts and their variances.

None of these exist anywhere in Shopify. If they were not exported before the date, they are gone, and rebuilding bin codes for a few thousand SKUs by walking the stockroom is a job measured in days.

If you took an export

Keep the raw CSV files and do not reformat them. Whatever Stocky alternative you move to will want the original columns, and a file somebody has already tidied up by hand is usually harder to import than the one Stocky produced.

An export that downloaded successfully is not the same as an export that will import successfully. The usual problems are dull and fixable: the same SKU appearing on two rows, two products sharing a barcode, rows carrying neither a minimum nor a maximum, rows with no bin at all, and columns that were renamed at some point and no longer match what an importer looks for.

Our Stocky sunset readiness check reads a CSV in your browser, names those specific problems and scores the file out of 100. Nothing is uploaded and nothing is stored — it is JavaScript on the page reading a local file.

Bin codes are a separate question. A code that reads fine to a person can still be one a scanner will not return cleanly, and that is worth catching before you print a sheet of labels rather than after. The bin label generator checks each code and tells you which ones it rejected and why.

If you did not

Then the bins, minimums and maximums have to be rebuilt from the shop floor. There is no export to recover and no version of this that is quick. The one mercy is that you only have to do it for the products that actually move: a shelf target on a SKU that sells twice a year earns nothing.

Start with the products your staff refill most often, and add the rest as they come up.

The part nobody exported

There is one thing no export contained: the order your staff walk the stockroom in. It lives in the head of whoever does the refill run each morning.

Write it down. It was the cheapest thing on this list to capture and the most annoying to reconstruct, whichever app you end up in — and unlike the bin codes, it is not too late.