What we have seen in inventory projects is this: changing software is rarely the hardest part. The risk sits in the assumptions staff have built around supplier records, purchase orders, transfers, counts and exception handling. Stocky closing makes those assumptions visible. A merchant can reproduce the screens and still lose the operating controls that made the old process dependable.
This guide treats a Stocky migration to Shopify as an operational cutover, not a settings exercise. It is for UK retail and ecommerce teams that need purchasing, warehouse and finance colleagues to agree what moves, what is archived and how stock truth will be proven after launch.
Contact StoreBuilt if the workflow crosses Shopify, warehouse, payment or third-party systems.
Keyword decision
| Field | Decision |
|---|---|
| Primary keyword | Stocky migration Shopify |
| Secondary intent | Stocky alternative, Shopify native inventory, Stocky discontinued |
| Search intent | Urgent migration planning with implementation intent |
| Funnel stage | Operations and support evaluation |
| Why StoreBuilt can help | A UK-focused cutover plan that protects records, controls and day-one warehouse work |
Table of contents
- Confirm the migration boundary
- Map old work to the native model
- Clean supplier and product identities
- Rebuild permissions and separation of duties
- Rehearse the physical workflows
- Cut over from a reconciled baseline
- Support the first trading cycle
- StoreBuilt point of view
Confirm the migration boundary
Start by naming the stores, POS locations, warehouses, suppliers and teams affected. Record which Stocky functions are genuinely used, not merely enabled. Interview the people who raise purchase orders, receive goods, transfer stock, count inventory, investigate variances and close supplier invoices. Their shortcuts often reveal requirements absent from a management process map.
Separate data retention from workflow replacement. Shopify advises merchants to export Stocky data they want to keep. Decide which exports are needed for accounting evidence, supplier disputes, historic costing and operational analysis. Store them in a controlled location with an owner, access rule and retention decision; a folder of unexplained CSV files is not a usable archive.
Map old work to the native model
Create a crosswalk before configuring anything. Stocky terms and habits may not map one-to-one to Shopify purchase orders, suppliers, transfers, adjustments and reports. Write the trigger, owner, input, approval, status, exception and completion evidence for each process. The goal is not to preserve every old click. It is to preserve the commercial control.
| Old operating need | Native destination | Acceptance evidence |
|---|---|---|
| Supplier commitment | Purchase order | Confirmed quantities, cost and terms |
| Inbound movement | Linked inventory transfer | Shipment and receipt history |
| Location movement | Transfer | Origin, destination and quantities |
| Stock correction | Inventory adjustment | Reason, user and audit trail |
| Reorder decision | Reports or Sidekick-assisted review | Buyer approval and final PO |
Clean supplier and product identities
A migration exposes weak identifiers quickly. Confirm that variants have durable SKUs, that barcodes are unique where scanning is used, and that supplier identities are not duplicated under slightly different names. Shopify documents supplier-specific SKUs, lead times, minimum quantities and case packs as information that may need metafields or metaobjects. Design those fields before teams improvise them in notes.
Do not merge supplier records merely because the names look similar. Check currencies, payment terms, tax treatment, contacts and fulfilment origin. Likewise, do not change customer-facing product handles as part of an inventory clean-up unless there is a separate SEO and redirect plan.
Rebuild permissions and separation of duties
Decide who can create a draft purchase order, who can commit it, who can receive goods and who can adjust stock. Small teams may combine roles, but the approval event should still be explicit for material purchases or unusual corrections. Use role-based permissions and test them with non-owner accounts.
Include temporary and store staff in the design. A process that works only when the operations director is present is not ready. Document how a colleague escalates a wrong barcode, an unexpected delivery, a rejected item or a destination error without forcing inventory into an inaccurate state.
Rehearse the physical workflows
Run a controlled rehearsal using real devices and representative products. Include a normal delivery, a partial shipment, an over-delivery, damaged goods, a multi-location transfer and a count variance. Confirm how accepted, rejected and cancelled quantities affect availability. Print or view the documents staff will actually use.
An illustrative homeware retailer might discover that buyers think in supplier case packs while the store sells individual units. The migration test should make that conversion explicit before a hundred units become a hundred cases. This is an illustrative risk pattern, not a claimed client result.
Cut over from a reconciled baseline
Choose a quiet trading window and define the last transaction permitted in the old process. Reconcile on-hand, committed, unavailable and incoming quantities by location. Freeze unplanned bulk edits while the baseline is taken. Record the reports, time and owner so differences found later can be traced to before or after cutover.
Keep a short exception queue for mismatches rather than forcing every uncertain quantity into available stock. Customer promises depend on availability being conservative and explainable. A controlled quarantine is safer than an optimistic number nobody can defend.
Support the first trading cycle
Monitor the first supplier order, transfer, stock count, sale, return and finance reconciliation end to end. Hold short daily reviews for the first week, then weekly reviews until exceptions stabilise. Track causes, not only ticket volume. Repeated receiving errors may point to identifiers or training, while stock drift may point to integrations writing the same field.
| Review | Owner | Question |
|---|---|---|
| Daily exceptions | Operations | What blocked normal work today? |
| Stock variance | Inventory lead | Which movement lacks evidence? |
| Supplier reconciliation | Buying and finance | Do quantities and costs agree? |
| Channel availability | Ecommerce | Can customers buy only genuine stock? |
A four-week migration plan
In week one, inventory the current process and archive requirements. In week two, configure a safe test model with representative suppliers, locations, products and staff roles. In week three, rehearse purchasing, transfers, counts and exceptions using physical devices. In week four, reconcile the baseline, train every shift and execute the cutover with a rollback decision point.
Give every task a named owner and completion evidence. “Training complete” should mean each role has performed awkward scenarios, not that a slide deck was emailed. “Data migrated” should mean totals and samples reconcile, not that an import reported success. Include finance and customer-facing availability because both feel inventory mistakes after the warehouse does.
Document the controls that remain
After cutover, publish a short operating guide: where to create a PO, how to receive a partial shipment, who approves a correction, where historic Stocky exports live and how to raise an integration incident. Add screenshots only where they help; the rule and owner matter more than a picture of a button.
Schedule a thirty-day review. Remove temporary workarounds, update permissions and compare the exception log with the original risk register. If staff rebuilt an unofficial spreadsheet, investigate the need it serves before banning it. That sheet may reveal a missing forecast, supplier attribute or approval step that deserves a governed solution.
StoreBuilt point of view
Stocky closing is not a reason to reproduce an old system blindly. It is a deadline for making inventory ownership clearer. StoreBuilt would judge the migration by whether a colleague can explain the stock position, process an awkward delivery and trace a correction without a private spreadsheet. Native features can reduce app sprawl, but only a tested operating model creates confidence.
Read our inventory accuracy guide and Shopify support services, or Contact StoreBuilt for a scoped Stocky migration review.
Sources reviewed
Shopify states that Stocky is no longer available after 31 August 2026 and directs merchants to native inventory management in Shopify admin and POS. Sources were checked on 17 September 2026; no paid search-volume or client performance claim is used.