Changing a SKU in Shopify without breaking your history

On a Tuesday in February, a hiking-sock brand retires its old code family and renames twelve SKUs in the bulk editor. Eight minutes later their barcode app can't find half the catalog, the stockroom labels point at codes that no longer exist, and the 3PL dashboard shows zeros on the new strings. The edit took eight minutes; the cleanup took three days.

Changing a SKU in Shopify is a one-field edit per variant — the risk lives in everything downstream that assumed the old string was permanent. Everything below serves the landing: what the edit actually touches, how to run it in bulk, and how to keep scanners, labels, and integrations matched to reality afterward. Behavior is verified against the Shopify Help Center in November 2026.

What changing a SKU does and doesn't touch

The SKU is a text field on the variant, editable at any time: open the product, click the variant, edit the SKU in the inventory section, save. For dozens or hundreds of variants, the bulk editor or a CSV import does the same job at scale (Shopify Help Center, "Using SKUs to manage your inventory", accessed November 2026).

Editing the string doesn't change the variant's inventory quantities — stock levels, locations, and counts stay attached to the variant itself. What changes is which systems can still match it:

• Apps and integrations. Many apps require SKUs to sync inventory, and they match exactly: ABC123 and abc123 are different SKUs as far as a third-party system is concerned. Exact-match breakage is the most common casualty of a rename.
• Search. The admin search bar and Shopify POS both find products by SKU. If your staff picks by scanned or keyed SKU, the old code stops working the moment you save.
• Duplicate protection. If a new code collides with an existing one, Shopify shows a warning in the Inventory section — duplicate SKUs cause issues with third-party integrations and inventory tracking. If you use Shopify Fulfillment Network, unique SKUs per variant are required outright.

If the rename is happening because the old codes themselves were messy, design the replacement scheme first — the SKU naming conventions guide owns that job — and come back here for the migration. Changing SKUs is easy; changing them twice because the new scheme also ran out of room is the mistake to avoid.

Before you edit: build the mapping table

The mapping table is the migration. It's the artifact you'll reuse for label reprints, app re-imports, and every "what was this called before" question for the next year:

Note the barcode column: barcodes and SKUs are separate fields with separate jobs, and unless the physical barcode itself changed, leave the barcode field alone. Your barcode workflow should survive an internal re-code untouched.

The pre-change checklist:

1. Pick a closed hour — after close or a dead mid-week window, never mid-promo.
2. Export a dated products CSV as your snapshot before touching anything. The inventory CSV guide covers the export.
3. List every system keyed to SKU: barcode or scanner app, POS labels, 3PL or fulfillment integration, accounting exports, supplier portals.
4. Fill the mapping table, one row per variant.
5. Check the new codes for uniqueness — resolve any duplicate warning before go-live, not after.

Making the change

Three paths, smallest to largest:

Single variant. Products → open the product → click the variant → edit the SKU in the inventory section → Save.

A category or a few dozen. Select the products in the admin, open the bulk editor, and paste the new codes column by column from your mapping.

A full re-code. CSV import with the new SKU column. One caution: run it on a single test row first and confirm the import updated the existing variant rather than creating a duplicate product — catching that on row one is free, and catching it after 2,000 rows is an afternoon of cleanup. What an accidental duplicate does to a catalog (and how to merge it back) is its own problem, covered in the duplicate products guide.

What breaks, and the order to fix it

The PO trap deserves spelling out. When you create a purchase order for a product you've ordered before, Shopify pre-fills the supplier SKU, cost, and tax values from your previous purchase orders with that supplier (Help Center, "Creating and managing purchase orders", November 2026). If the supplier SKU field was previously just a copy of the old variant SKU, the next PO quietly resurrects the dead code. On the first PO after a rename, fill the supplier SKU deliberately — it's the field designed to survive your internal re-codes.

History is the other half. The Help Center notes that SKUs added after an order was placed won't appear in historical reports, and some reports filter out products without SKUs. A mid-year re-code can therefore split one product's sales story across two strings in any SKU-keyed export. And don't assume order history rewrites itself: open one pre-change order and read the line item before you promise accounting a clean series.

When not to change a SKU

The edit is cheap; the blast radius isn't always worth it. Two situations argue for waiting:

• External catalogs reference the old code. If retail partners, marketplaces, or a supplier portal key their records to your SKU, a Shopify-side rename desyncs every one of them until each is updated — and none of them will warn you either. Renaming because you want tidier codes is optional; renaming when five outside systems hold the old string is a project with a deadline.
• Mid-season, mid-PO. A purchase order in flight was written against the old code. Changing the variant SKU while that PO is open means the receipt, the mapping table, and the paperwork disagree for one cycle. If the change can wait a week, let the goods land first.

If the driver is a supplier packaging change — they renumbered their cases and you want your codes to match — that's usually a supplier SKU field update, not a variant SKU change. The two fields exist precisely so their renumbering doesn't have to become yours.

A worked landing sequence

The sock brand, in full: 12 variants, 214 printed labels, one scanner app, one 3PL.

• 15:00, after the close-of-day export: 12 rows pasted into the bulk editor — 9 minutes, including a duplicate check that came back clean.
• 15:15: scanner app re-imports the 12-row mapping — 6 minutes.
• 15:30: 214 labels reprint in about 4 minutes; sticking them on bins is the only real time cost, roughly 45 minutes of walking.
• 16:30: updated catalog pushed to the 3PL, ahead of Thursday's 312-unit inbound, so the receipt posts against the new strings.

Total hands-on time: about 70 minutes. Skip the sequence and the discovery cost is the three-day kind — apps don't warn you, they just stop matching.

One more system keyed to SKU, since we build it: InventoryX reads your catalog read-only and keys its per-SKU leak ledger to the SKU field, so a re-code shows up as fresh items with no history. If you use it — or any SKU-keyed tracker — time the change for the week you export your buying list, and keep the mapping table next to you when you reconcile the month.

Common questions

Does changing a SKU in Shopify affect inventory? No. The SKU is a text field on the variant; quantities, locations, and stock history stay attached. What breaks is matching — apps sync on exact, case-sensitive SKU strings — so update every downstream mapping the same day you edit, or scans and syncs fail quietly overnight.

Will past orders keep the old SKU? Check rather than assume: open one order placed before the change and read the line item — that's the string your exports carry for that sale. Documented behavior already cuts against clean history: SKUs added after an order was placed don't appear in historical reports at all.

Can I change SKUs in bulk? Yes — the bulk editor for a category, or a CSV import for a full re-code; both are the routes Shopify documents for SKU changes at scale. Run a one-row test first, confirm the import updates rather than duplicates, and resolve any duplicate-SKU warning before you go live.

Should barcodes change when SKUs change? No. SKUs are internal codes you control; barcodes are separate fields, usually assigned upstream, and they should survive internal re-codes untouched. Change a barcode only when the physical barcode itself changed — otherwise your labels and your scans disagree about what's in the bin.

Why did an app stop finding my products after the rename? Third-party apps match SKUs exactly and case-sensitively, and many require the SKU field to sync at all. Re-push the catalog or import your old-to-new mapping into the app, and confirm the app is configured to sync the SKU field rather than another identifier.

Next step

The standing rule: one category per session, inside a closed hour, mapping table saved, apps re-mapped before you sleep. If the rename exists because the old scheme ran out of room, fix the design before you migrate again — the SKU naming conventions guide has the fill-in template, and the bulk editor guide then runs the change itself.