Stocky migration is not just an app selection problem. Before choosing a replacement, it is worth getting the purchase-order data into a flat file that humans can audit.

The risky part is that Stocky and Shopify native purchase orders do not model every detail the same way. A purchase order is not only a list of SKUs. It often carries supplier defaults, received quantities, pack sizes, tax assumptions, foreign-currency costs, destination locations, and notes that explain why a buyer ordered a certain amount.

A practical pre-migration checkpoint looks like this:

1. Export purchase orders while Stocky access is still available.
2. Keep PO-level fields beside every line item: PO number, supplier, status, location, and receipt state.
3. Check each item row for SKU, title, ordered quantity, received quantity, cost, and any missing supplier reference.
4. Mark rows where receipt status is inferred rather than explicit. Those rows need manual review before you trust a new workflow.
5. Rebuild supplier defaults outside the import step: default tax rate, pack size, currency, vendor grouping, and reorder rules.
6. Only after the worksheet looks clean should you test one small PO or transfer in the new process.

The main goal is to separate rescue from migration. First rescue and flatten the old PO data. Then decide what belongs in Shopify native POs, what belongs in a supplier planning worksheet, and what needs a paid inventory or forecasting system.

For a narrow first pass, I use a browser-side Stocky purchase-order JSON to CSV rescue checker: https://shopify-csv.aivismonitor.com/stocky-purchase-order-api-csv-exporter

It does not call the Stocky API, does not create Shopify POs, and does not replace purchasing software. It only turns a Stocky purchase-order JSON export into a reviewable CSV so missing SKUs, costs, quantities, receipt states, and possible pagination problems are visible before the migration work starts.