Stocky is ending. What workflow are you most concerned about replacing?

With Stocky’s August 31 shutdown approaching, many merchants are evaluating what comes next.

Most conversations focus on purchase orders and reorder points, but Stocky touched a lot of day-to-day operational workflows.

If you had to choose one area that concerns you the most, what would it be?

Feel free to share why in the comments. I’m curious whether the biggest challenge is planning inventory, receiving it, or keeping inventory accurate across locations as businesses grow.

Hi @kthoppae :raising_hands:

For me, the biggest concern wouldn’t actually be purchase orders or reorder points—those can usually be replaced with another tool or even a spreadsheet process.

What worries me more is inventory accuracy as operations become more complex. Once you’re managing multiple locations, multiple stores, bundles, or products that share inventory, a small discrepancy can quickly turn into oversells, stock transfers, and a lot of manual corrections.

In our case, the issues didn’t usually show up during planning. Everything looked fine until a customer placed an order and we realized the inventory count wasn’t truly reflecting what was available across the business.

That’s why the area I’d be most focused on post-Stocky is inventory synchronization and inventory visibility rather than purchasing itself. We’ve found that keeping inventory accurate across locations and sales channels has a bigger day-to-day impact than forecasting.

Tools like Easify Inventory Sync have been helpful for merchants dealing with shared inventory pools or multiple Shopify stores, but regardless of the tool, I think maintaining accurate inventory data is probably the operational challenge that’s hardest to fix once things start scaling.

Curious whether others feel the same, or if purchase orders and replenishment planning are the bigger gap that Stocky is leaving behind.:heart:

Interesting that inventory accuracy is emerging as a common theme.

One thing we’ve been hearing repeatedly is that inventory accuracy isn’t really a standalone workflow. It’s the result of multiple workflows staying aligned over time:

  • Receiving
  • Transfers
  • Adjustments
  • Cycle counts
  • Returns

When any of those break down, inventory accuracy starts drifting and operators end up reconciling manually.

Curious whether others see inventory accuracy as the root problem, or whether there is a specific workflow that tends to create most of the discrepancies.

From the threads I’ve been reading these past months the concern splits
cleanly in two, and most replacements only cover the first half:

  1. Deciding what to buy — forecasting, reorder points, generating the PO.
    Plenty of tools do this now.
  2. What happens when the boxes arrive — receiving against the PO, partial
    deliveries, cost per line, margin, labels for what actually turned up, and
    a count you can approve before it hits stock. Far less covered.

If you have a physical store, the second half is where the hours go. Merchants
putting a few hundred SKUs a week through native POs report it taking several
times longer than Stocky did.

The one I’d worry about most is cost history. Shopify keeps one cost per
variant — the last one you paid. Update it and last quarter’s margins quietly
change with it. If you care what you actually earned, make sure whatever you
move to keeps a dated cost record of its own.

Curious which half people here are most worried about — and if it’s receiving,
how many SKUs a week you’re putting through.

(Disclosure: I’m building in this space, which is why I’ve been mapping it.
Not linking anything here.)

Hi @kthoppae Welcome To Shopify Community So For me it would be multi-location inventory accuracy, hands down. Reorder suggestions and purchase orders are important, but they’re at least somewhat forgiving, if a reorder point is slightly off, you catch it before you actually run out. Multi-location accuracy failing silently is worse, because stock counts being wrong across locations doesn’t announce itself, it just quietly causes overselling, failed local pickups, or transfers based on numbers that were never right to begin with.

Receiving is a close second, since partial receiving with proper audit trails is one of those things that seems minor until a shipment comes in short or damaged and there’s no clean record of what was actually received versus what was ordered.

Purchase orders and reorder points get the most attention because they’re more visible and directly tied to “did I run out of stock,” but the multi-location/receiving accuracy problems are the ones that erode trust in the numbers overall, once you stop trusting your stock counts, everything downstream (reordering, transfers, forecasting) becomes guesswork anyway.

@Mustafa_Ali — that matches what I keep seeing, with one thing I’d add about
which direction it runs in.

Accuracy isn’t really a workflow of its own. It’s the output of the ones you
listed. And of those, receiving is the only moment where a number enters the
system from outside with nothing on the other side checking it. A sale gets
checked by the customer. A transfer has two locations that have to agree. A
receipt has one person, a packing slip, and a driver waiting at the door.

So a lot of what surfaces later as “multi-location accuracy” started as a
receipt booked to the wrong location, or a short shipment entered as a full
one. They aren’t competing priorities — the first one causes the second.

Three things that cost nothing and catch most of it, whatever you land on:

  • Keep ordered, received and damaged as three separate numbers. The moment
    they collapse into one net figure you lose the ability to reconcile the
    supplier invoice.
  • Don’t let a receipt write more than what is still outstanding without
    someone explicitly confirming it. That single rule catches “thirteen”
    typed where “three” was meant.
  • After the tool writes a stock level to Shopify, have it read the value back
    and compare. Shopify accepts the call and changes nothing if inventory
    tracking is switched off for that variant — no error, just a number that
    never moved. Worth testing before you trust any replacement.

How many locations, and roughly how many SKUs a week are you receiving?
Whether that happens at the shop or at a warehouse changes which of the two
hurts more.

(Same disclosure as above: I’m building in this space, nothing to link.)

Nobody has mentioned the part with an actual deadline on it. The workflow you can rebuild next month. The history you do not pull out before the lights go off is simply gone.

Stocky held things Shopify never did: cost per line on past receipts, supplier records, purchase order history, the receiving trail stockroom_eu described above. That data lives in the app’s own database, so when the app stops, it lives wherever you copied it and nowhere else.

It helps to know what Shopify itself keeps, because it is less than most people assume. Per-variant inventory adjustment history covers the last 180 days and can only be viewed one variant at a time. The store activity log is view-only, cannot be exported, and caps at 250 results. So if you need to answer what a line cost you back in March, the answer is going to be in your export or nowhere.

Practical order for anyone still deciding: export everything you can now, evaluate replacements next week. Do it the other way round and you lose the option.

Disclosure, and it argues against me: I make a Shopify backup app, and it would not have saved anyone here. Third-party app data sits inside that app, out of reach of anything installed on the store - which is exactly why this deadline is the merchant’s to catch and not a tool’s.

Ian is right, and there is a sharper version of it that catches people who think they are safe.

Shopify stores one cost per variant — the last one you paid. So even inside the 180 days it does keep, you cannot answer what a line cost you in March. The next time you update that cost, every historic margin quietly rewrites itself. It is not that the history is hidden; there is no field for it.

That changes what is worth exporting in the next few hours. In order:

  1. Supplier records — contacts, lead times, minimums. None of this exists anywhere in Shopify. Retyping it is the single biggest job people are about to discover.
  2. Purchase order history with cost per line. This is the one that is actually gone.
  3. Your receiving and stocktake trail.

Product lists and current stock you can leave — those are still in Shopify.

One honest warning about the export itself: a folder of CSVs is not a system. In November you still will not be able to answer the March question, because nothing is reading those files. Get them out today anyway, because you cannot get them out later. Just know that step two is finding something that keeps costs dated going forward, or you are back here next year with the same gap.

Disclosure: I am building a replacement, so weigh that. It does not change what you should export before tonight.

On preserving data specifically, the one that catches people out is suppliers.

POs, stocktakes and cost reports all export from Stocky as CSV, one report at a
time. Supplier records do not export at all. No button, no bulk export, no API.
Supplier names, emails, lead times and minimum order values have to be copied out
by hand while Stocky still opens.

Lead time is the field worth being careful about. It is not written down anywhere
else in most businesses, and every reorder calculation in every app you might
move to depends on it.

Worth knowing there is more time than the headlines suggested. 31 August was when
Stocky stopped working, not the export deadline. Shopify keeps it readable for at
least 90 days after, so realistically it is nearer the end of November.

Disclosure: I build Provido, one of the forecasting apps in this space. The
export advice applies whatever you move to, and I would give it the same either
way.

One workflow I’m most concerned about is the reconciliation step between purchasing and inventory.

A PO tells you what you expected to buy, but the supplier invoice and actual delivery can be different: changed cost, short shipment, discount, substitution, partial delivery, etc.

So for me the missing workflow isn’t only “create PO” or “receive stock.” It’s:

ordered → invoiced → actually received → final Shopify quantity/cost

If those differences aren’t caught during receiving, they usually turn into manual spreadsheet work later.

I’d be interested to hear whether other merchants treat the supplier invoice as part of receiving, or mostly reconcile it separately through accounting.

Receiving, without much hesitation. And specifically the ugly half of it that salor_works described: ordered, invoiced, received, final cost. Most replacement tools treat receiving as “tap the quantity, done”. The real version is a delivery that comes up two units short, an invoice that lands three weeks later with different numbers, and a substitution nobody wrote down. If a tool can’t hold “what I ordered, what actually arrived, what I was finally charged” as three separate facts, the books drift within a month. Quietly.

That’s the part we went deepest on with Binly (I build it: Binly ‑ Stocktake & Reorder - Stocky replacement: phone stocktakes, POs & smart reorder | Shopify App Store). Every delivery is recorded separately against its PO line. A late invoice that costs more than the order gets flagged. And you can split that late cost between what already sold and what’s still on the shelf instead of rewriting history.

On the data-preservation point from Ian_Chechin and Arkadas_Kilic: that window is closing fast. The API answered right up to the deadline, and we pulled a 12,000-variant store’s full history a couple of days before the cutoff, 954 purchase orders with receive dates and per-delivery costs intact, the kind of detail no spreadsheet export was ever going to carry. Exported CSVs? Keep them safe. They import fine. Exported nothing? Try the API today rather than tomorrow. Some endpoints may still answer.

Arkadas_Kilic is also right that supplier records are the sleeper loss. Lead times most of all. They live nowhere except the receipt history. That is exactly why receipt dates were worth rescuing in the first place.