Stocky shuts down in August. What are you actually moving to for reorder/POs?

Shopify Discussion
47

@irish.chen the point about par levels and reorder points living only
inside Stocky’s app logic is right on the facts, but I’d push back on
whether it’s worth a week of screenshotting.

A reorder point in Stocky is a number somebody typed in at some point,
usually a while ago. It doesn’t move when the product’s sales move. So
when you migrate it, you’re carrying over a decision made against last
year’s demand and treating it as data.

The settings actually worth capturing are the ones that aren’t derived
from sales at all:

  • supplier MOQs and case/pack sizes
  • shelf or storage capacity ceilings
  • anything contractual

Those can’t be recomputed from anything, and they’re gone on the 31st.
Reorder points, par levels and safety stock are a different matter — you
can rebuild those in an afternoon from sales history plus lead time, and
you’ll end up with better numbers than the ones you rescued.

Two additions to @HJBCodeforge’s list, which I think is the most useful
summary in this thread:

On reconstructing lead time from received_at — use the median, not the
mean. One container stuck in customs drags a mean out by weeks and
quietly inflates every reorder point you compute from it. Since partial
deliveries give you several received dates per PO, you usually have
enough points for a median to be meaningful.

On velocity — a single window hides the thing that actually causes the
stockouts. A product selling at its 30-day average is predictable. A
product whose last 7 days are running 40% above its 30-day average has
moved its own stockout date forward by about a week, without a single
unit leaving your stock plan, and a static reorder point won’t notice
until it’s already been crossed. Comparing the two windows costs nothing
— both are inside the same 30 days of order data you’re already pulling
— and that comparison is where the surprises live.

Disclosure: I’m building in this space (StockPulse). For the question in
the title, I’m not the answer — no purchase orders, no receiving, no
suggested quantities. @HJBCodeforge’s Replenora and brata’s BR
Inventory Planner both cover the PO half properly and mine doesn’t.

Mine only does the days-of-cover and order-by-date part. I put that
calculation up as a free page — no signup, runs in your browser — if you
want to sanity-check one product against whatever you end up picking:

48

@DEV_WEB1 Good pushback, and the median/velocity points are genuinely useful — hadn’t thought about comparing the 7-day and 30-day windows off the same pull, that’s a smart way to get an early warning for free.

You’re right that I was overselling the reorder points, though. A number someone typed in a year ago isn’t data, it’s a stale decision, and rebuilding it the way you described gets you something better. I’ll stop pitching that as worth rescuing.

Where I’d still draw a line: MOQs, case/pack sizes, capacity ceilings, contract terms — the stuff you listed as not derivable from sales. That’s the actual case for grabbing anything before the 31st, and it doesn’t compete with what you three are building. Whichever of Replenora, BR Inventory Planner, or StockPulse someone ends up on, none of those tools existed when the supplier relationship was set up, so none of them have that context either. InvoRescue just pulls it — plus cost history and received dates via the API, also gone on the 31st — so it’s sitting there ready to hand to whichever tool you pick.

Disclosure: same as you, building in this space. One-time purchase, not a subscription, price is on the page. Not trying to compete with the three tools above — this is more the “before you even decide” step.

49

(post deleted by author)

50

(post deleted by author)

51

Whatever you import into, check the cost column first. European exports write 12,50 and plenty of importers turn that into 1250. Mine did until last week, took me a while to spot.

(Building Stockward, so treat that as disclosure.)

52

we actually trying all apps, but best so far is supplywatch :waving_hand:

53

sort of but its not great, supplywatch seems better?

54

Didn’t tried it before. Seems it’s way more old. But don’t see whether it’s useful or not. I want to know why Stockie is not the great option for you?

55

its just outdated and not relevent to store owners, creators of apps are not store owners and they dont understand the market/store owner needs… These guys apparently have had many stores and come from that stand point? makes sense to have a store owner make an app? user flow seems great

56

Great point. Well said.

57

Actually, we ARE store owners as well and we made FyreTrail to handle everything we needed. It turned out that’s what a lot of other stores need as well so we put FyreTrail on the app store so other stores could access it too.

58

Before choosing a replacement, I would preserve and audit the migration evidence first. The minimum fields I would check are SKU/barcode, supplier, unit cost, ordered quantity, received quantity/date and the PO reference. Duplicate SKUs and missing supplier/cost fields are especially risky because a replacement can appear to import successfully while losing the purchasing history needed for reorder decisions.

Full disclosure: I am building SellerPilot, and I made a free browser-only Stocky CSV audit for this specific pre-migration check:

It requires no Shopify login, does not upload the CSV, and exports a risk report, rollback snapshot and migration checklist. It also states the important limitation clearly: it cannot recover supplier notes, custom fields or history that Stocky never exported.

If anyone here has already exported Stocky data, I would be interested to know which critical field is still missing from this checklist. That is more useful to validate before recommending another inventory system.

59

Adding one dimension that hasn’t come up yet, for the subset of Stocky users who used it for kits and component inventory rather than POs.

The recommendations above are right for reordering and purchase orders. But if part of your Stocky setup was tracking bundles or kits, meaning finished SKUs assembled from components, that slice doesn’t map to a PO tool at all. For that piece you’re choosing between two architectures: apps that keep a virtual kit SKU and edit orders after the fact, and apps built on Shopify’s Cart Transform API, where the kit expands into its component SKUs at checkout. With the second approach, inventory decrements on components natively, refunds can target individual components, and every order you’ve received stays complete even if the app itself ever disappears. After Stocky, and Rebolt three weeks before it, that last property is worth asking every vendor about directly.

Disclosure: I build Solid Bundles, an app in that second category, so weigh my bias accordingly. I wrote up what the shutdown means specifically for the kit slice here, including what to check before you pick anything: Stocky is retiring: A Bundle Replacement Guide | Solid Bundles

Happy to answer kit or component-inventory questions in this thread either way.

60

Two things on the data side I haven’t seen mentioned here, both from
Shopify’s own migration page.

Suppliers can’t be exported from Stocky at all — not contacts, not lead
times, not MOQs. Whatever you move to, that list has to come out by hand
before the 31st.

Second, on history being deleted: you keep read-only access to export for
at least 90 days after the shutdown, so there is more room than it sounds.
The records still don’t migrate into Shopify — anything you want has to
come out through Stocky’s own reports — but the door doesn’t slam on the
31st.

help.shopify.com/en/manual/products/inventory/transitioning-from-stocky

Disclosure, since others here have been upfront: I build Restock Forecast,
and it is only half of what this thread is asking for.

To the question earlier about paying something small for just reorder —
that is the half I went at. It reads your recent orders and stock levels,
gives a stockout date and a reorder quantity per variant adjusted for your
lead time and cover, subtracts anything already on a purchase order so it
does not tell you to buy the same stock twice, and flags lines holding far
more than they need. Free for 10 products, $19 a month above that.

It does not do purchase orders, receiving, suppliers or stocktakes, and it
is not going to. If POs are your blocker, the PO apps named above are the
right shelf — this sits next to one of them, not instead of it.

I wrote the dates and the export gaps up separately, no signup:
restock-forecast.fly.dev/stocky-shutdown

61

On the “has anyone actually made the switch” question, one thing that might lower the stakes of trying. You don’t have to migrate blind and find out afterwards.

The way we built ours: every screen runs on the free plan with your real store data. Dead stock, reorder suggestions, the lot, computed on your actual catalog before you pay anything. The Stocky import shows a full preview first too, including how many of your purchase order lines carry receipt dates, so you know exactly what history you’re getting before a single row is written. Paid actions have a two week trial on top of that.

So the sensible path is boring: connect, look at your own numbers, run the import preview, and only then decide. If a tool won’t show you your own data before asking for a card, that tells you something.

On price, since this thread keeps circling it: ours is public, nineteen to one ninety nine a month depending on size, no sales calls and no annual contracts. Cancel from Shopify like any app.

Disclosure: I build Binly. The free-preview point applies to a few of the other tools here too, worth checking whichever you shortlist.

62

@jmiralles your description of the gap – “just reorder suggestions + an exportable PO, nothing else” – is exactly the shape I am building toward. The empty middle between a spreadsheet that breaks at 100 SKUs and a $200+/mo ERP is where most importers actually live.

What I am working on: per-charge landed cost allocation (freight by weight, duty by value), a late-invoice true-up that creates a new revision instead of re-entering the PO, and an explicit report of how much the sold-unit margins were overstated while the cost was provisional. Plus reorder suggestions and exportable POs as the base layer.

Since you clearly see the same gap – would you be open to a 20-minute workflow review? I am pre-launch and trying to validate the late-invoice case against how people actually handle it. No sales pitch.

64

Most of this thread is app comparisons, which makes sense. The parallel question worth asking before you pick one: what data are you bringing with you?

Standard Stocky CSV gives you PO headers, current costs, and stocktakes. Two things in the API don’t make it into the CSV and close on Aug 31: purchase_item.supplier_cost_price (what you actually paid per delivery, per supplier — the cost trail) and received_at (the real arrival date, not the order date — what your actual lead times are based on). Supplier notes and par levels have no automated path at all; those are manual capture now or never.

The app decision is reversible. Getting this data out before the API goes dark is not. Worth doing that first, then making the tool choice. I built a browser-only tool (InvoRescue) for this specific step — link’s on my profile.