Stocky is no longer the place to run inventory operations. Shopify’s help sets the transition after 31 August 2026. It directs merchants to inventory management in the admin and POS.
I would not start a replacement project from an angry forum thread. Merchant reports can identify workflows to test. They cannot establish what Shopify supports today.
First, preserve the records you can still access
The migration help describes a period of read-only access after the shutdown. It does not give a final access date. Check what your store can still read, and preserve the records you need.
Historical purchase orders and stocktakes do not move automatically. Use available reports and any exports you already kept. Supplier records need a separate plan: Shopify says suppliers cannot be exported from Stocky.
Stocky APIs stopped working on 31 August. An old label or purchasing integration that depends on those APIs cannot be treated as a reliable source for the new app.
Check the native workflow first
Shopify’s current purchase-order help describes:
- Draft purchase orders.
- Products, quantities, costs, payment terms and supplier details.
- An Ordered status after supplier confirmation.
- Inventory transfers for shipments, receiving and cost adjustments.
That does not establish full Stocky parity. It does contradict describing the native path as having no receiving or costing workflow.
I test the details that matter to your team: which costs change, what a scanner reads, what gets printed, and how a supplier order is approved. I do not repeat historical claims about missing SKU defaults or min/max rules without testing the current version.
Scope the gap
An existing app can be the right answer. I compare its actual workflow, integration access and total cost with your requirements. I do not infer a market-wide gap from a list of products mentioned in a forum.
If a specific gap remains, the Stocky-replacement situation describes a bounded custom-app approach:
- Read the stock and sales data the integration is permitted to access.
- Apply your reorder points, pack sizes and supplier lead times.
- Produce a draft with the source data and calculations visible.
- Ask a person to approve it before sending an order.
- Record the supplier response and receiving status.
The app can own its draft and approval records. Creating or changing native purchase orders is a separate capability to verify before quoting it. An admin screen is not proof that a corresponding public API exists.
What I would quote
I would quote the two or three workflows that carry your purchasing week. Barcode receiving, blind counts and labels need their own acceptance checks, including the hardware your staff use.
This article is a design pattern. I illustrate it offline with synthetic data in the demo repository on GitHub. It produces reorder signals and purchase-order drafts for local approval; it sends no orders and changes no stock.
How I can help
I can assess the native workflow and build a defined gap under API integrations and automation. If your requirements are clear, I can quote implementation. If they need mapping first, we agree a separate diagnostic engagement.
