How to Refurbish an Amazon Listing (New ASIN, Same SKU & FBA Inventory) in Google Sheets
Migrate an Amazon listing to a brand-new ASIN without moving inventory or relabeling — keep your SKU and FBA stock, reset the listing, all from Google Sheets.
TL;DR
- Back up: capture the listing twice in Listing Snapshot — your own version by SKU and Amazon's catalog version by ASIN.
- Create: in the Publish Queue, create a new ASIN under a temporary SKU with a fresh UPC (or GTIN exemption) and a partially-modified title, highlight, bullets and description — every other attribute carried over — while a DELETE row removes the old listing in the same batch.
- Rebuild: restore the original copy on the new ASIN, then rebuild your original SKU on it using the new ASIN as the externally_assigned_product_identifier.
- Move stock: a one-line support case remaps your FBA inventory. Product, warehouse stock and SKU all stay put; only the ASIN changes.
Introduction
Refurbishing a listing means migrating an existing FBA product onto a brand-new ASIN — while keeping the SKU, the FNSKU labels, and every unit already sitting in Amazon's warehouses. Sellers do it to start a listing fresh and regain new-product momentum, without touching physical inventory.
The whole play is four moves:
- Before: you have SKU1 → ASIN1 (the old listing).
- Create: create a new product under a temporary SKU2 — partially modify the title, highlight, bullets and description, keep every other attribute — and Amazon assigns a fresh ASIN2.
- Re-home: delete the old listing, then rebuild SKU1 pointing directly at ASIN2. From now on SKU1 → ASIN2.
- Move stock: FBA units still reference ASIN1; one support case remaps them to ASIN2. Done.
Doing this in Seller Central means juggling flat files, category templates and inventory loader quirks. With SellerSheet's Catalog spreadsheet, the entire workflow lives in two tabs — Listing Snapshot (backup & verification, both your submitted version and Amazon's catalog version) and the Publish Queue (every create / update / delete submission).
Variables used throughout this guide
- SKU1: your original SKU, the one you keep — e.g.
SKU-001. - ASIN1: the old ASIN you're leaving behind — e.g.
B0XXXXXXX1. - SKU2: a temporary SKU used to create the new ASIN — e.g.
SKU-001-08141030(SKU1 + timestamp). - ASIN2: the brand-new ASIN, your listing's new home — e.g.
B0XXXXXXX2.
Prerequisites
- Store authorization: your Amazon store connected to SellerSheet with write access — sign in at sellersheetai.com and connect it under Settings → Stores & Marketplaces.
- An identifier that won't collide with ASIN1: either a fresh, unused UPC, or a category with GTIN exemption (identifier left empty).
- The Catalog spreadsheet with its Listing Snapshot and Publish Queue tabs (created by the SellerSheet sidebar — see Catalogs).
- Variation children only: note the parent SKU, variation theme and theme attribute values before you start — you'll restore the relationship at the end.
Never reuse the old UPC
Amazon matches products by GTIN before it ever looks at your title. Submit SKU2 with ASIN1's UPC and it attaches straight back to ASIN1 — no new ASIN is ever created. This single mistake is the most common reason the whole workflow fails.
Getting around the sidebar
Four habits make the whole workflow self-explanatory — the sheet documents itself:
- The sidebar menu must match the active sheet tab. Each section (Listing Snapshot, Publish Queue…) is sheet-specific — the sidebar even says "active tab must match". If a button seems to do nothing, check which tab is active at the bottom of your spreadsheet.
- Hover any button to see a tooltip explaining exactly what it does before you click.
- Read the cell notes. Header cells carry notes (the small corner marker) describing how the column is used, accepted values, and examples — hover to read them.
- The Publish Queue header is the built-in manual. For every attribute column, row 4 is a guide with a format hint and example, row 6 shows the column's display name (e.g. Externally Assigned Product Identifier), and the hidden row 5 holds the code key the server reads. Your listings start on row 7.
Phase 1: Back up everything first
The problem: this workflow deletes a live listing on purpose. If anything goes sideways and you didn't capture every attribute first, you're rebuilding a listing from memory — titles, bullets, dimensions, compliance fields, all of it.
1a. Back up what you submitted (by SKU)
Open the Listing Snapshot tab. Enter your store (e.g. myStore-US) in the Store column and SKU1 in the SKU column, then click Listing Snapshot → Fetch by SKU in the sidebar. The row fills in — and the JSON column now holds a complete JSON backup of every attribute on the listing. That's your restore source. Note the ASIN column value: that's ASIN1.
1b. Back up what Amazon accepted (by ASIN)
On a new row of Listing Snapshot, enter the store and ASIN1 with the SKU cell left empty, and click Listing Snapshot → Fetch by ASIN. This captures Amazon's catalog-side, normalized version of your listing (what shoppers see) — useful for spotting what Amazon rewrote, and as evidence for the support case later.
Fetch by SKU and Fetch by ASIN only run on rows whose JSON cell is empty. To fetch a SKU again later in this guide, use a new row or clear that row's JSON cell.
Phase 2: Create the new ASIN
The problem: you can't just "ask Amazon for a new ASIN" — the catalog exists to prevent duplicates. Submit the same product unchanged and Amazon binds your new SKU straight to the ASIN you're trying to escape.
Here's the balance this phase walks: the new listing must carry the old ASIN's attributes — the Phase 4 support case depends on the two ASINs matching. But submit them 100% identical and Amazon decides the product already exists and binds SKU2 to ASIN1; differ too much and changing the copy back after creation sometimes fails. So: keep every attribute from the old listing, and partially modify only four copy fields — Item Name, Item Highlight, Bullet Point, Product Description — just enough for Amazon to treat it as a new product. Once the new ASIN is created, those four fields are changed back to the old ASIN's exact content (Phase 3, step 1).
1. Load the product into the Publish Queue
Switch to the Publish Queue tab and follow the numbered groups in the sidebar:
- Fill Store and Listing Locale (e.g. en_US) in row 3.
- Enter the productType from your Listing Snapshot backup (e.g.
HEADPHONES) in the data row. - Click Get Template — it loads every attribute column for that category, like downloading the category's Excel template from Seller Central, but in-sheet.
- Put SKU1 in the sku column and click Fetch by SKU — the whole row populates.
The Publish Queue workflow — Template → Fill rows → Validate → Publish, all from the sidebar.
2. Edit the row into a "new product" (SKU2)
| Column | Change to |
|---|---|
| sku | SKU2 — e.g. SKU-001-08141030 (SKU1 + timestamp) |
| operationType | UPDATE |
| externally_assigned_product_identifier#1.value | Fresh UPC — or empty if GTIN-exempt |
| externally_assigned_product_identifier#1.type | upc — or empty if GTIN-exempt |
| supplier_declared_has_product_identifier_exemption | true if GTIN-exempt; otherwise leave empty |
| product_site_launch_date | Clear it if it carries the old SKU's past date |
| item_name / title_differentiation / bullet_point / product_description | Partially modify (see below) |
Why does creating use UPDATE? UPDATE submits the full listing: if the SKU doesn't exist it is created; if it exists it is overwritten. There is no separate "create" operation — SKU2 takes UPDATE too.
The three key identifier columns — type, value, and merchant_suggested_asin (used later in Phase 3).
Modify, don't rewrite from scratch. Touch only the four copy fields and change them just enough that duplicate detection sees a new product — restructure the title, reword the highlight and bullets, rephrase the description. Change too little and SKU2 merges back into ASIN1; go far beyond these four fields and restoring the original content later can fail. Everything else stays identical to the old listing.
If SKU1 is a variation child, also clear parentage_level, child_parent_sku_relationship, variation_theme and the theme attributes (e.g. color / size) — create it as a standalone product and restore the variation at the end.
Scroll right for the GTIN exemption flag and the variation columns (clear these for children).
3. Add a DELETE row for SKU1 in the same batch
On the next empty row, enter SKU1 in the sku column and set operationType to DELETE. That's it — a delete row needs only those two cells. Creating SKU2 and deleting the old listing in the same batch frees SKU1 up, so you can rebuild it on the new ASIN2 in Phase 3.
Two rows, one batch — SKU2 (UPDATE) creates the new product; SKU1 (DELETE) removes the old listing.
4. Validate, then submit
Click Validate (Preview) and check the Submission Log tab for ERROR-level issues — validation is a preview, nothing publishes (a DELETE row has no preview and is skipped). Once clean, click Create/Replace/Del. to submit (instant for up to 20 rows, dispatched per row's operationType; use Submit Feed for larger batches).
5. Verify ASIN2 was born
Wait 10–15 minutes. In Listing Snapshot, fetch SKU2 and read the ASIN column — that's ASIN2. The critical check: ASIN2 ≠ ASIN1. You can cross-check in Seller Central too.
Got the old ASIN back?
If SKU2 returns ASIN1, Amazon merged it — the four copy fields weren't different enough (or the identifier matched). Delete SKU2, increase the changes to those four fields, and resubmit.
Phase 3: Rebuild your SKU on the new ASIN
The problem: ASIN2 exists, but it's living on a throwaway SKU with placeholder copy. Your real SKU — the one your FBA inventory, ads and operations are built around — is deleted and homeless. And if the two ASINs don't look like the same product, support will refuse to move your inventory.
1. Restore the original copy on SKU2 first
Before rebuilding SKU1, copy the original copy from your Phase 1 Listing Snapshot backup back onto the SKU2 row and submit with operationType UPDATE. The column mapping:
| Backup (display name) | Publish Queue (code key) |
|---|---|
| Item Name | item_name |
| Item Highlight | title_differentiation |
| Bullet Point | bullet_point |
| Product Description | product_description |
The Publish Queue shows the display name on row 6; the hidden row 5 holds the code key.
Why this matters: it makes ASIN2's attributes identical to ASIN1's. When you open the support case in Phase 4, support can't reject the remap on the grounds that the two ASINs are different products. After submitting, fetch SKU2 in Listing Snapshot once more and confirm it still resolves to ASIN2.
In the same submission, lock the identifier to the new ASIN — so every later update lands on the newly created ASIN (with the identifier left empty, Amazon can sometimes spawn yet another listing):
| Column | Set to |
|---|---|
| externally_assigned_product_identifier#1.value | ASIN2 |
| externally_assigned_product_identifier#1.type | asin |
| merchant_suggested_asin | ASIN2 |
| operationType | UPDATE (required) |
Identifier and GTIN exemption are mutually exclusive: if SKU2 was created via exemption (supplier_declared_has_product_identifier_exemption = TRUE), clear the TRUE first — it cannot coexist with externally_assigned_product_identifier.
2. Rebuild SKU1 pointing at ASIN2
Back in the Publish Queue:
- The row's attributes already match SKU1 exactly and the identifier points at ASIN2 from the previous step — just change the sku cell to SKU1, with operationType
UPDATE. - Confirm SKU1 is fully deleted — Fetch by SKU on SKU1 in Listing Snapshot no longer finds the SKU (the row's Image cell shows the reason). If it still resolves, wait and re-check before submitting.
- Validate (Preview) → Create/Replace/Del.
3. Verify the rebuild
- Listing Snapshot — fetch SKU1: the ASIN column should now read ASIN2.
- Seller Central — Manage All Inventory shows SKU1 / ASIN2; Fix Stranded Inventory shows SKU1 / ASIN1. The stranded entry is expected — your FBA units still reference the old ASIN until Phase 4.
A successful feed is not proof
Amazon "successfully" accepts operations on SKUs that don't exist. Always confirm the result by fetching the SKU in Listing Snapshot or checking Seller Central — never by the feed status alone.
Phase 4: Move the FBA inventory & clean up
The problem: your listing lives on ASIN2, but every unit in Amazon's warehouses still references ASIN1 — stranded and unsellable. Creating removal orders and re-shipping would cost weeks and real money.
1. Open the support case
Go to Seller Central → Help → Get support → Selling on Amazon → Products and inventory → Fix a product page, and use this one-liner (swap in your own SKU1 and ASIN2):
Hello team, please remap SKU: SKU-001 to ASIN: B0XXXXXXX2.
They represent the same product. Thanks!If support asks for evidence, provide a Manage All Inventory screenshot and your Phase 1 Listing Snapshot backup (by ASIN) showing the two ASINs are the same product. Once processed, the stranded entry clears and your stock is sellable under ASIN2 — no relabeling, no new shipment.
2. Clean up
- Delete SKU2 — after the remap it's just a duplicate empty offer on ASIN2 that can interfere with pricing and the Buy Box. Add a DELETE row in the Publish Queue.
- Restore the variation (children only) — re-add parentage_level = child, child_parent_sku_relationship, variation_theme and a theme attribute value that doesn't clash with existing siblings.
- Archive the backup rows, the case ID and the timeline.
Common pitfalls
| Pitfall | Consequence | Avoid it |
|---|---|---|
| Reusing the old UPC on SKU2 | Attaches straight back to ASIN1 — no new ASIN | Fresh UPC, or GTIN exemption with the identifier left empty |
| Modifying the copy too timidly | Duplicate detection merges SKU2 into ASIN1 | Partially modify the four copy fields; always verify ASIN2 ≠ ASIN1 |
| Rebuilding SKU1 before it's released | The SKU can re-link to its old catalog data | Confirm SKU1 is gone first; always set merchant_suggested_asin to ASIN2 |
| Trusting the feed status | The listing may not actually exist | Verify by fetching the SKU in Listing Snapshot or in Seller Central |
| Forgetting to delete SKU2 | Duplicate offer on the same ASIN | Clean up in Phase 4 after the inventory remap |
| Leaving variation attributes on a child | Creation errors, or the child re-attaches to the parent | Clear variation columns in Phase 2; restore them in Phase 4 |
FAQ
Do I need to relabel or move my FBA inventory?
No. FBA inventory is tied to the FNSKU, which never changes in this workflow. After you rebuild your SKU on the new ASIN, a short support case asks Amazon to remap the existing inventory — no removal orders, no relabeling, no new shipment.
Why does the temporary SKU need a new UPC or GTIN exemption?
Amazon matches products by GTIN before it looks at your title. If the temporary SKU carries the old UPC, it attaches straight back to the old ASIN and no new ASIN is created. Use an unused UPC, or leave the identifier empty and set the GTIN exemption flag if your category allows it.
My temporary SKU came back with the OLD ASIN — what went wrong?
Either the identifier matched (same UPC) or the four modified copy fields were still too similar, so Amazon's duplicate detection merged it into the existing ASIN. Delete the temporary SKU, increase the changes to those four fields, and resubmit.
Why does Fix Stranded Inventory show my SKU with the old ASIN?
That is expected mid-workflow. Manage All Inventory shows your SKU on the new ASIN, while the FBA units still reference the old ASIN until the support case remaps them. Once the case is processed, the stranded entry clears and the stock is sellable under the new ASIN.
Can I refurbish a variation child?
Yes. Note the parent SKU, variation theme and theme attribute values first, clear the variation columns when creating the temporary SKU, and re-attach the rebuilt SKU to the parent at the end — using a theme value that does not clash with existing siblings.
Why restore the original copy before rebuilding the SKU?
The support case succeeds when the two ASINs clearly represent the same product. Restoring the original title, bullets and description makes the new ASIN's attributes identical to the old one, so support has no grounds to reject the remap as a different product.