Update an existing Shopify store
Most migrations move a store from one platform to another. This one doesn’t move anything — it reads your Shopify store and writes back to the same store, updating the records that are already there.
It’s for bulk edits that are too large or too structured to do by hand:
- Rewrite every product description to a new house style.
- Re-price a whole catalogue from a supplier sheet.
- Regenerate SEO titles and meta descriptions.
- Retag products, or normalise vendor names.
- Backfill metafields across thousands of records.
You write the change as a mapping, preview it on a handful of records, and run it. Because it’s a mapping, the same edit is repeatable and reviewable instead of a one-off script.
This edits records in a store you are selling from. Nothing is ever created and nothing is ever deleted — every record is an update — but an update is still a change. Always start with a dry run.
What it never does
These are guarantees, not settings you can get wrong:
- Never creates a record. If a row has no matching record in the store, it’s reported as an error rather than pushed as a new product. You cannot end up with duplicates of your own catalogue.
- Never deletes anything. Purge and duplicate-cleanup are switched off entirely for this kind of migration. If you need to remove records, do it in your Shopify admin.
- Never touches stock. Inventory quantities and locations are left exactly as they are.
- Never touches cost per item or whether a variant is inventory-tracked.
Setting one up
- Click Bulk edit in the header of the Dashboard or the Migrations page. That button is the choice — the wizard it opens is titled New bulk edit and doesn’t ask again.
- Name it after the change you’re making, not the store — you may run
several against the same shop (
autumn-reprice,seo-refresh). - Enter your shop domain and an Admin API access token. There is only one set of credentials: the store you read from is the store you write to.
- Pick the resources you want to edit.
Credentials
| Field | Example | Notes |
|---|---|---|
| Shop domain | yourstore.myshopify.com | Hostname only — no protocol, no trailing slash. Use the .myshopify.com form, not your custom domain. |
| Admin API access token | shpat_… | From a custom app on this store. Needs read and write scopes. |
The token needs both directions, because the same store is being read and written:
| Resource | Scopes |
|---|---|
| Products, collections | read_products, write_products |
| Customers | read_customers, write_customers |
| Orders | read_orders, read_all_orders, write_orders |
read_all_orders matters even here: without it Shopify only shows an app
the last 60 days of orders, so an update run would quietly skip everything
older. Graftport checks for it before reading orders and refuses the run if
it’s missing.
What you can change, per resource
| Resource | You can update | You can’t |
|---|---|---|
| Products | Title, description, handle, status, vendor, tags, SEO, template, images, variant prices, compare-at prices, SKUs, barcodes, weight, tax settings, inventory policy | Stock levels, cost per item |
| Collections | Title, description, handle, sort order, SEO, membership, image | — |
| Customers | Name, email, phone, note, tags, marketing consent, default address | — |
| Orders | Contact details, shipping address, note, tags, custom attributes, metafields — in place. Line items, prices, totals, taxes, discounts, payment status — by rebuilding the order (it’s deleted and created again under the same order number; see Orders → re-running) | Anything added inside Shopify after the order existed doesn’t survive a rebuild — refunds, fulfillments, staff notes |
Discount codes and gift cards can’t be updated in place yet. If you enable discount codes on this kind of migration, the run is refused with an explanation rather than quietly doing nothing.
Running it
The first run should always be a dry run — it’s on by default. A dry run reads your store, applies your mapping, and reports what would change without sending anything to Shopify.
When you’re ready for the real thing, the run dialog asks you to type your shop domain to confirm. That’s deliberate friction: it’s the one action here that changes live data.
Two options worth using while you build confidence:
- Load limit — push only the first N records. Prove the mapping against ten real products before touching ten thousand.
- Row filter — narrow the run to records matching a condition, so you can start with a single collection or vendor.
Changing handles
If your edit changes a product or collection handle, its old URL stops working. After the run, use Emit redirects to create 301s from the old paths to the new ones. Handles you didn’t change produce no redirects.
Re-running
Runs are repeatable. A record is only pushed again when its mapped output has actually changed, so a second run over an unchanged catalogue does almost nothing. Edit your mapping, dry-run it, and run again as often as you need.