From what I’ve seen the standard CSV exports cover core data like purchase orders, suppliers, inventory and current costs. I haven’t found official confirmation that supplier notes or historical cost changes are included, so I wouldn’t assume they’ll be preserved. If those records are important, I’d export and back them up seperately before the migration. Hopefully someone who’s completed a full migration can confirm exactly what carries over.
Vilpert is right that the notes are the part nobody checks until it is too late. Disclosure: I built one of the alternatives (Stockwik), so grain of salt on the rest.
The test-record advice above is the best thing in this thread - one dummy supplier note, one PO note, one cost adjustment, then run the export and see what survives. Do that before trusting any migration path.
Two additions from doing migrations with people: payment terms and per-supplier instructions are the other silent losses, so get them into a spreadsheet column even if it is manual. And whatever app you land on, confirm supplier notes have an actual home there and that its importer brings them in - ours does (notes, terms, and PO instructions all come in via CSV), but the spreadsheet backup is what saves you either way.
If anyone is stuck on the export itself, happy to help - that offer does not require using my app.
I actually dug into this because I ran into the same uncertainty. Pulled up Stocky’s own API docs and checked the supplier fields directly — notes are not in there. The suppliers endpoint only returns structured contact/address fields, no free-text field for vendor notes at all. Par levels/reorder point settings aren’t in any of the documented API resources either, so that lines up with what you’re seeing.
The one piece of good news: historical cost per supplier and actual received dates ARE in the API, just buried — each purchase_item has a supplier_cost_price and a received_at field, so if you pull the full PO history through the API (not just the CSV export) you can reconstruct the cost trail and real lead times per supplier. CSV export alone won’t surface it cleanly though.
So notes and par levels are the two things that genuinely don’t survive any automated export — official or otherwise. Manual copy is the only route Stocky itself gives you for those.
I ended up building a Chrome extension called InvoRescue to deal with this for my own store — it pulls the API data (PO history, cost trail, received dates) and walks you through capturing the notes/par level fields per supplier since those can’t be automated. It’s a paid one-time purchase rather than a subscription, since it’s a one-off migration job, not something you need long-term. Link’s on my profile if useful — happy to answer questions about what it does or doesn’t cover here first.
The post above is right about the export gap, and the field-by-field question is the useful one. Here’s what I found when I mapped it.
Comes out cleanly in the standard CSVs: product-level stock, purchase order headers and line items, stocktake results, and cost per item at the time of export.
Has to be recreated by hand: the supplier objects themselves. Shopify says it outright on the migration page, “Suppliers can’t be exported from Stocky.” What goes with them is lead time per supplier, MOQ, pack size, per-supplier price and currency, and whatever you knew about who actually ships on time. Stocky stored suppliers as app-only objects, deliberately separate from the Shopify vendor field, which is exactly why there’s no native destination for them.
One thing I haven’t seen mentioned in this thread, and it’s the one that can actually hurt: Stocky was delisted on February 2, 2026, and you can’t reinstall it. So if you’re trialling a replacement, run it alongside Stocky, never instead of it. Uninstalling to “start clean” closes your read-only window early, and there’s no way back.
Disclosure, I’m the developer of Restocked, one of the alternatives, so weigh that accordingly. It covers the purchasing half only: velocity-based reorder alerts, reorder date and quantity from supplier lead time and MOQ, POs grouped by supplier. The supplier import is a single paste specifically because of the export gap above. No barcodes, no receiving, no stocktakes, so if that’s the half of Stocky you lived in, 506 EasyScan or Fabrikator will serve you better and I’d rather say so here.
I keep a sourced comparison here, including where my own app loses to the others: Stocky Alternatives in 2026: an Honest Guide by Use Case
You’ve nailed the part that actually hurts. In my experience: the structured records — suppliers, purchase orders, stock adjustments, tax categories — can be pulled out with their relationships intact if you go through Stocky’s API instead of CSV. CSV gives you flat rows; the API keeps the links between them, so the PO ↔ supplier ↔ adjustment chain survives instead of breaking into disconnected sheets.
Where I’d temper expectations, and this matches your worry: tax categories come across as a master list but don’t auto-remap to per-product reduced/standard rates — you’d re-set those on the new side. And I honestly can’t confirm yet that free-text vendor notes and full cost history come back cleanly. That’s the exact gap I’m still verifying myself.
Full disclosure: I’m the developer of UreyukiBox, an inventory app for Shopify — which is why I’ve been elbow-deep in Stocky’s export internals. I’m not here to pitch it; the advice holds no matter which tool you choose: get the API-level export done before Stocky goes read-only on Aug 31. The relational data is recoverable — it’s the notes and cost trail that nobody seems sure about yet.
Has anyone here actually confirmed notes + cost history survived a real migration? That’s the missing piece for all of us.
To answer lumine’s question directly: no, the standard Stocky PO CSV export does not include a received date column. You get the order date, not received_at. That field exists in the API response for each purchase item — it’s just not surfaced in the CSV export.
Same story for per-supplier cost history. The CSV collapses everything to a single current cost per SKU. The supplier_cost_price field on each purchase_item record in the API is what holds the actual cost at the time of each delivery — the trail you need to see that supplier A was cheaper until March, as you put it. The CSV doesn’t carry it.
Vilpert, to your original questions:
What doesn’t make it into the CSV export:
- Supplier notes — Shopify’s own migration docs confirm: “Suppliers can’t be exported from Stocky.” The
/suppliersAPI endpoint has contact fields but no free-text notes field, so there is no automated path out for that information. - Par levels / reorder points — not in the CSV, and not in any documented Stocky API resource. Manual capture is the only option.
What IS in the API but gets flattened or dropped in CSV exports:
received_atper purchase item (actual delivery date vs. order date)supplier_cost_priceper purchase item (cost trail over time)
I built InvoRescue specifically for this pre-migration step — it pulls the fuller API data (cost trail, received dates, complete PO records) while the API is still live, then runs a structured capture flow for supplier notes and par levels per vendor, since those can’t be automated. Runs entirely in the browser, one-time purchase not a subscription, because once August 31 passes there’s nothing left to rescue. Link’s on my profile if useful.
Whatever tool you pick for the long term, separating the data-rescue step from the replacement-app decision is worth doing first. The app choice is reversible, the history isn’t.
That answers it, thanks for actually going and checking the supplier fields instead of guessing.
One thing I want to flag though, because it changes the order people should be doing this work in. The API window and the read-only window are not the same window.
Shopify’s migration page says two separate things. “Any Stocky APIs will stop working on August 31, 2026.” And “You’ll have read-only access to export your data for at least 90 days after that date.”
So the 90 days is export access, and export means the CSVs. The CSVs are exactly what does not carry received_at or supplier_cost_price, which is what you just confirmed. The two fields only the API can hand you die on August 31. That is 33 days from today, not four months.
Which flips the advice this thread has settled on, mine included. Most of us have been saying capture the vendor notes by hand first because that is the part with no automated route. But notes and par levels live on screens, and screens are what read-only access keeps alive. The cost trail and the real received dates are the ones on the short clock.
If I were starting now I would pull the full PO history through the API this month and leave the manual note capture for September, not the other way round. Someone should confirm whether supplier detail pages stay readable through those 90 days, since the wording says export access rather than full UI access, and that distinction is what decides whether the manual half can safely wait. I would not bet the notes on it without checking.
Worth adding that this applies to every API based route people have suggested here, including the paid ones. Nobody gets a second attempt after the 31st.
Does your extension paginate the full PO history in one pass, and does it checkpoint? For a store carrying a few years of POs, resuming after a timeout is the part I would want working before the deadline rather than during it.
The window distinction is the most useful thing in this thread and I think it’s right — APIs off on the 31st, export access for 90 days after. Shopify’s migration page states those separately and they are not the same clock.
One link in the chain I’d flag before people reprioritise on it. I’ve verified the API side directly: purchase_items carry supplier_cost_price and received_at. I have not verified what the PO CSV export actually contains, and at least one migration guide claims that export includes cost prices and received quantities. If that’s accurate, part of the cost trail survives the 31st via the export route and the squeeze is narrower than stated — more like per-line received dates and per-supplier price history in usable shape, rather than the fields wholesale. Anyone with an active install could settle it in five minutes by running the PO export and posting the header row. Worth doing before the thread treats it as established.
Where I’d differ on the conclusion: I wouldn’t defer the notes on the expectation that read-only keeps supplier screens viewable. That can’t be confirmed until September 1, and if it turns out to be export-only, the notes are gone by the time anyone finds out. The failure is asymmetric — deferring and being wrong is permanent, capturing early and not needing to costs an afternoon. So: API first because that deadline is certain, notes still in August if the hours exist, defer only if genuinely out of time.
On your two questions, straight answers:
Pagination — yes, full PO history via since_id, with backoff on failures.
Checkpointing — split. The supplier page capture commits each supplier as it lands, so that half survives a killed worker and resumes. The PO pull does not checkpoint yet; it accumulates in memory, which means an MV3 reclaim mid-run costs you the run. You’ve identified the right failure mode and it’s the wrong half to have it in, since the PO pull is the one with the hard deadline. Fixing it this week, not after the 31st. If you’re carrying multiple years of POs I’d genuinely wait for that build rather than fight it now.
The thing worth doing this week, before any tool decision, is getting your data out while the export still works.
What people miss is not the purchase orders themselves. It is everything around them. Per supplier: contact details, lead time, minimum order quantity, and your cost per SKU per supplier including when it changed. Cost history is the one nobody thinks about until they are pricing a reorder in October and cannot remember what they paid in March.
Get it into a spreadsheet now, whatever you end up moving to. Leaving it until the end of August means relying on whatever still functions on the day, and that is a bad morning to find a gap.
On the rebuild-by-hand problem for 20 to 200 suppliers: a CSV with supplier, SKU, cost and date is enough to reconstruct most of it later, even if the tool you pick cannot import it directly. Structure beats notes.
Disclosure: I built one of the replacements, Proviand, and it takes a Stocky CSV. Do the export anyway. It is worth doing whichever tool you land on, including none of them.
Disclosure: I build one of the replacement apps, and I’m going to answer this one against my own interest, because your read is correct and the pitch-shaped answer would be useless to you.
Your diagnosis is right, and the reason is structural rather than anyone being lazy about it. Vendor notes, cost movement over time and calibrated par levels are all derived or free-text data. Every importer on the market is built around the entities it can model — suppliers, products, purchase orders, quantities, costs — because those map to fields it actually has. A free-text notes blob has nowhere to land, and cost history isn’t a field at all, it’s a sequence you’d have to reconstruct from receipts you no longer have.
So, plainly, about mine: it imports suppliers and purchase orders from CSV. It does not import vendor notes, and it does not import historical cost movement. I’d be misleading you if I said otherwise, and I’d expect the same to be true of most of the others regardless of what the marketing says. Worth asking each vendor that exact question rather than “do you have a Stocky importer” — the second question always gets a yes.
What I’d actually do, in this order, before the 31st:
Treat the notes as a separate export from everything else. Don’t wait for an importer to handle them. Open the supplier list, copy the notes field into its own spreadsheet keyed by supplier name, and keep it as a document. Even if it ends up pasted into a notes field in the new tool by hand, you’ll have it. Two hours now versus unrecoverable in 90 days.
Screenshot or export the par levels as numbers. Any tool that derives reorder points from sales velocity will recalculate its own, and they won’t match yours — yours encode judgement the maths doesn’t know about. Keep the old numbers so you can sanity-check the new ones instead of trusting them blind.
For cost history, decide whether you need the series or just the current truth. If it’s for margin reporting, current landed cost going forward usually covers it. If you genuinely need the trend, that’s a data-warehouse job, not an inventory-app job, and no PO tool is going to give it back to you.
To answer your direct question honestly: no, I have not seen a tool that imports the notes and the cost trail. If someone in this thread has, I’d like to know too.
@HJBCodeforge - the par level point is the one I’d push on slightly, because it’s exactly what Replenishly does and I want to be honest about both sides.
Full disclosure: I built it. It derives reorder suggestions from your Shopify sales velocity.
You’re right that the new numbers won’t match, and right that the mismatch encodes real judgement; seasonal patterns, supplier lead time quirks, your Q4 buffer on products where the factory goes slow. None of that survives in either direction.
But there’s a case for recalculating rather than carrying numbers over: par levels set 18 months ago reflect demand from 18 months ago. If your velocity has shifted since then, which for most merchants it has, inherited numbers might be more wrong than fresh ones derived from recent history. The tool doesn’t know what you know about your suppliers. But it does know what actually sold in the last 12 months, which the old numbers might not.
The honest failure mode is the other direction: velocity-based suggestions are good at capturing demand shifts that already happened, and poor at anticipating things you know are coming that the data hasn’t seen yet. A planned promotion, a supplier going slow in Q4, a new product without enough history. That’s the judgement layer your notes encode, and it doesn’t transfer.
Practical suggestion that matches what you said: export the par levels now as a numbered list keyed by SKU. When any velocity-based tool gives its suggestions, compare them line by line. Where they diverge significantly, that divergence is usually meaningful, either your demand has genuinely shifted, or there’s a judgement factor worth adding back manually. Either way, having the old numbers to compare against is more useful than inheriting them blindly.
@sohailahmedjokhio To close the loop on your question about bulk-pulling the notes field via API — unfortunately the answer is no, and Shopify’s own migration doc now confirms it directly: “Suppliers can’t be exported from Stocky.” The /suppliers endpoint returns structured fields (name, email, phone, address) and nothing else. No free-text field surfaces. Same for PO-level notes.
This isn’t a gap in any particular tool — the field simply isn’t in the API response.
What is recoverable via the Stocky API before the 31st:
supplier_cost_priceperpurchase_item— the historical cost trail, delivery by deliveryreceived_atper line item — actual landed dates, not just order dates
Neither of those is in the standard CSV export, but both are in the API.
So the practical answer to “can notes be automated” is: not from the API side. The only viable route is stepping through supplier and PO detail pages while Stocky is still live and capturing the text. That’s the part that genuinely has to be manual — the question is just whether you do it with a clipboard or with a workflow that structures the output so it’s useful on the other side.
I built InvoRescue specifically because I hit this wall — it handles the API extraction and walks through the manual-capture piece for notes and par levels. One-time purchase, runs in-browser, link’s on my profile. But whether you use a tool or a spreadsheet, do it before Aug 31, not after.
Hey, I built Replenly and we have a one-click Stocky CSV import, so I can answer some of this from what we’ve actually seen come through.
What survives the import cleanly: supplier profiles, product-to-supplier relationships (via the product-settings CSV, SKU-keyed), and purchase order history with line items. Our first paying customer migrated through this exact path and was set up in under 10 minutes.
What does not come through, being honest: vendor notes don’t land in the Stocky export CSVs. The per-supplier context Vilpert mentioned (MOQ reminders, discount tiers, seasonal lead time quirks) lives in a notes field that Stocky doesn’t include in the structured export. You’d need to manually copy those over into whatever tool you move to. Same applies to cost history as a time series. You get the current cost, not the trail of how it moved.
On lumine’s point about received dates: our import pulls what the Stocky PO export provides, which is order date and line items. If received dates aren’t in the CSV columns, they don’t come across, and your new tool starts fresh on lead time learning. Sales velocity is fine since that’s computed from Shopify order data which stays put regardless.
The practical advice: export everything now while Stocky is still writable. Even if your new tool can’t import every field, having the CSVs archived means you can manually reference the vendor notes and cost trail later. Once read-only access expires, it’s gone.
Disclosure: I built Replenly.
This thread has done the clearest job anywhere of naming what actually matters in the next seven days, so I’ll just try to add a bit of precision to a few of the open questions.
On cost history: blueshorespearl is right that per-PO cost is reconstructable from the standard CSV — each PO line carries the price paid on that order. What the CSV doesn’t carry is purchase_item.supplier_cost_price at delivery granularity combined with received date. The field that’s genuinely API-only and time-sensitive is received_at — the actual date stock landed. Without it, what you have is cost-per-order, not cost-per-delivery, and lead time calculation from the CSV is purely the order date, not when things actually showed up.
Denyslg confirmed on August 8 (from a live account, not just the docs) that received_at comes through via the Stocky v2 API at purchase item level. Partial receipts split into two rows — one “delivered,” one “not delivered.” Worth knowing if you’re parsing it yourself or checking whether a migration tool genuinely read the API vs. re-exported the CSV.
On supplier notes and par levels: still no API path. The /suppliers endpoint returns 18 structured fields — name, contacts, address — and no free-text field. Shopify’s own migration doc says it outright: “Suppliers can’t be exported from Stocky.” Manual capture while the supplier detail pages are still live is the only route. Whether read-only access after Aug 31 preserves those detail pages is something I wouldn’t assume without testing it first.
Practical split with 7 days left:
- API layer (
received_at, supplier contacts): time-sensitive, window closes Aug 31 - Supplier notes and par levels: no automated path, manual before Aug 31
- Everything else: survives the standard export
(I built InvoRescue, a Chrome extension, to handle the API extraction and walk through the manual-capture steps for notes and par levels. Link’s on my profile if that’s useful context — happy to answer questions about what it does and doesn’t cover.)
Worth flagging that the timeline in the original post has shifted, and I suspect a lot
of people in this thread think the door already closed.
31 August was when Stocky stopped working, not when the data goes. Shopify’s help centre
says you keep read-only access for at least 90 days after that, so the copy-out window
runs to roughly the end of November. If you assumed you’d missed it — you haven’t, but
you’re now on a clock that nobody is reminding you about.
https://help.shopify.com/en/manual/products/inventory/transitioning-from-stocky
On “what actually comes back”: I can only answer from the documentation, not from having
run a full export myself, so treat it as that. Shopify lists completed purchase order
reports, stocktake history, and historical cost data as exportable. And they say plainly:
“Suppliers can’t be exported from Stocky.”
Which lines up with your worry. The split I’d draw is between what you can rebuild and
what is simply gone:
Rebuildable, with effort — supplier names, your product list, current costs. Names you
can recover from the vendor field on your products in Shopify. It’s not the same as your
Stocky supplier records, but it’s a starting list rather than a blank page.
Gone for good — the notes. MOQ 50, call before ordering hoodies, 12% over $2k, don’t use
the Tallinn warehouse. Also cost movement over time, and the par levels you calibrated
over months.
On the notes specifically, and this is the uncomfortable part: no importer is going to
take that in as structured data, mine included. “Call before ordering hoodies because
they run two weeks behind in Q4” is not a field, it’s a sentence. Any tool claiming to
import it is either guessing or quietly dropping it.
What I’d actually do: open each supplier in Stocky and paste the notes field verbatim
into a spreadsheet, one row per supplier, as plain text. Don’t try to tidy it into
columns. You can structure it later once you know what your new tool supports; you cannot
get it back once the window closes. Same for lead time — it exists nowhere else, and
every reorder point you set afterwards depends on it.
Disclosure: I’m building an inventory app in this space, so I have a stake in the answer.
I’m being blunt about the notes because I’d rather say “copy that out yourself today”
than pretend an import solves it.
For anyone who has already switched — did your new tool take cost history as a series, or
only the current cost? That’s the one I still can’t get a straight answer on, and it
decides whether the export is worth doing properly or just quickly.
Disclosure first: I build an inventory forecasting app, so I have a bias here. I am not linking it and this is not a pitch — codequal’s point about par levels deserves a longer answer than it got.
Recomputing par levels from 60–90 days of sales velocity is the right instinct. Two things will quietly wreck that number, and neither is obvious from a spreadsheet.
Days out of stock poison the average. If a product was empty for 20 of the last 60 days, dividing by 60 says it sells at a third of its real rate. So you order less, it empties again, and the next calculation is worse. It compounds, and it hits your best sellers hardest because they are the ones that run out. Divide by the days it could actually be bought, not by the calendar. Stocky’s exports will not tell you which days those were, so start writing them down from today.
The average is the level, not the answer. Rate × lead time is the point where a product runs out exactly as the replacement lands — if it keeps selling at its average. Nothing does. A line that sells nothing for nine days and forty on the tenth averages four a day, and planning it as four a day empties the shelf every time. You need extra on top, sized by how much that specific product’s daily sales move around. Steady sellers need almost none; lumpy ones need a lot.
On relearning lead times without received dates: you do not need Stocky’s history for this. Start logging order date and arrival date from your next PO. Until you have a few, use the supplier’s quoted lead time as a floor rather than a fact — quoted times are what they aim for, not what they hit.
One thing worth saying plainly: if a product sold nothing in your window, it has no rate and no par level. Set that one by hand. A formula will hand you a confident zero, and a zero looks exactly like “healthy” in a spreadsheet.
Since I disclosed the bias I should close it honestly: the app I build, Restock Forecast, does those three by default — it records the empty days and divides by the days a product could actually be bought, it sizes the extra from each product’s own daily variability, and it marks a product with no sales as unknown rather than healthy. It is free for up to 50 products, and the paid plan has a 30-day trial.
It does not do purchase orders, receiving, suppliers or stocktakes. If those are the Stocky workflows you are replacing, this is not your answer and the apps upthread will serve you better.