With Stocky shutting down on August 31, a lot of us are stuck with the same problem: your history doesn’t move into Shopify automatically, and Shopify’s own import can’t bring old purchase orders back. Its PO CSV upload only creates a new draft with line items and drops the status, received quantities, supplier, and costs. Suppliers can’t even be exported cleanly.
I build Shopify apps, and I kept hitting this myself, so I made a free browser tool to fix the conversion step: Free Stocky Export Converter — Move Your POs & Suppliers Before Aug 31
You drop your Stocky export in (CSV, or the API JSON if you can pull it), and it gives you clean, import-ready files:
- Purchase orders — consolidates Stocky’s one-PO-at-a-time exports into a single file and keeps the status, received quantities, costs, dates, and supplier.
- Suppliers — cleans and de-duplicates the list so you’re not re-typing it.
- Stocktakes/inventory — outputs the Shopify Inventory import shape (SKU + Available).
- SKU / cost lists — so you don’t lose your cost basis.
A few things on purpose:
- It runs entirely in your browser — nothing is uploaded, and nothing is stored. You can even use it offline once the page loads.
- It’s free, no signup, no limit.
- Rows that Excel mangled (long SKUs turned into 7.5E+11) or that have a blank SKU get listed for you, not silently dropped, so you can see exactly what didn’t convert.
Full disclosure: I also make an inventory app (EZStock) that the cleaned file imports straight into, but the converter works on its own, and the output is standard CSV you can use however you want.
Still early, so I’d genuinely appreciate feedback from anyone mid-migration:
- Does the output match what you’d need to import?
- Any Stocky export quirk it should handle that it doesn’t?
- Anything unclear in the results?
Happy to fix things quickly given the deadline. Thanks!
This is a useful tool and the browser-only approach is the right call — nobody wants to upload PO history to a server they’ve never heard of.
One thing worth naming alongside it, because I’ve seen people conflate the two problems: converting what came out versus getting at what never came out at all.
Your converter handles the first half really well. The second half is a different problem. A few things Stocky’s export simply doesn’t write to any CSV, regardless of how clean the conversion step is:
purchase_item.supplier_cost_price — the actual cost paid per PO line at the time of each order. The CSV only gives you the product’s current cost. If your supplier pricing has shifted across multiple deliveries, that history lives only in the API, not in any export file.purchase_item.received_at — the real date stock arrived per line item. The export gives you PO creation date. If you want to calculate actual lead times per supplier, you need this field from the API.- Supplier notes (free-text reminders per vendor). Not in the CSV. Not in the API either — I checked the
/suppliers endpoint directly, 18 structured fields, no notes field. Shopify’s own migration page confirms it: “Suppliers can’t be exported from Stocky.”
- Par levels / reorder point settings. Not documented in any API resource. Manual capture only.
So the sequence I’d suggest: run a CSV conversion first to get clean import-ready files, then pull the API layer for cost trail and received dates before the API goes dark on Aug 31. Notes and par levels need manual capture no matter what.
I built a Chrome extension (InvoRescue) specifically for the API extraction + structured manual capture piece. Browser-only, one-time fee, designed to run before you even pick a replacement app. Happy to answer questions on what it covers here. Link’s on my profile.
Pre-validating catalog updates before running bulk CSV imports is crucial, but most spreadsheet checkers only test column header syntax rather than background ingestion behavior.
Three specific image-pipeline failure modes to watch for in bulk catalog updates:
-
Silent WebP Dropping: Standard syntax validators verify that ‘Image Src’ contains a valid HTTP/HTTPS URL string, but fail to check extension payloads. If URLs point to raw .webp files from supplier feeds, Shopify’s background CSV worker silently skips fetching the image binary. The text attributes update, but image slots end up blank on the storefront.
-
Variant-Image Column Coverage: For multi-variant collections (e.g. 1 Color across 4 Sizes), Shopify strictly requires the color image URL to be duplicated across ALL 4 size rows under ‘Variant Image’. Blank cells assuming inheritance break variant image mapping on import.
-
Blank vs Absent Column Semantics: In bulk CSV updates, a blank cell in a variant row can either mean “clear existing value” or “no change” depending on whether native Shopify CSV import or Matrixify is used.
If your workflow identifies WebP or variant-image mapping gaps before publishing, consider normalizing them locally using EasyCatch (a client-side Chrome extension). Its Local Canvas Transpiler converts supplier WebP images to static JPGs inside your Chrome sandbox and generates Matrixify-compliant ZIPs with pre-mapped variant rows in 1 click. 100% Local-First so client store data stays private.
This is a genuinely good breakdown, and you’re right about the split — cleaning what came out is a different job from getting at what Stocky never writes to CSV.
One clarification though: the converter already handles the Stocky API JSON, not just the CSV. If you drop in the export from the purchase_orders API (or a single PO’s JSON), it reads supplier_cost_price and received_at per line, plus inventory_item_id as the match key. So the per-line cost trail and real receipt dates do come through — as long as you can pull that JSON before the API goes dark. I lead with CSV in the copy because that’s what most people have on hand, but the JSON path is there and it’s the more complete one.
Where you’re completely right is the stuff that isn’t in the API at all — supplier notes and par/reorder levels. Those are manual capture no matter what, and it’s worth people knowing that up front rather than assuming any tool can recover them. Good call flagging the /suppliers endpoint having no notes field.
So the sequence you laid out is the right one: clean the exports, pull the API layer (JSON works in my converter, or however you extract it) before Aug 31, and hand-capture notes and par levels. Appreciate you adding the detail.
@Vlad_Gerasimchuk Fair correction, and I should have been clearer — I hadn’t verified the JSON path, so I was writing as if CSV was the only practical input. If the converter already reads the full purchase item payload and surfaces supplier_cost_price and received_at per line, that’s the more complete route and worth people knowing.
The remaining gap for most merchants is probably the step before the converter: actually pulling that JSON. For anyone comfortable with the API it’s straightforward, but the majority in these threads are working from whatever Stocky’s export button gives them. Knowing to authenticate, paginate through purchase orders, and hand the result to a converter isn’t obvious if you haven’t done it before.
That’s where I’d say the real friction is — not a gap in your tool, just a prior step that needs its own coverage.
And yes, agreed on notes and par levels. Glad that part was useful.