# How to Refurbish an Amazon Listing (New ASIN, Same SKU & FBA Inventory) in Google Sheets (https://sellersheetai.com/guides/refurbish-amazon-listing-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.
* **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 [#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:
1. **Before:** you have SKU1 → ASIN1 (the old listing).
2. **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.
3. **Re-home:** delete the old listing, then rebuild SKU1 pointing directly at ASIN2. From now on SKU1 → ASIN2.
4. **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 [#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 [#prerequisites]
* **Store authorization:** your Amazon store connected to SellerSheet with write access — sign in at [sellersheetai.com](https://sellersheetai.com/home) 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](/help/sheets/sellers/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.
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 [#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 [#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) [#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.
\[\[TODO: screenshot Listing Snapshot tab with Fetch by SKU]]
### 1b. Back up what Amazon accepted (by ASIN) [#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.
\[\[TODO: screenshot Listing Snapshot tab with Fetch by ASIN]]
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 [#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 [#1-load-the-product-into-the-publish-queue]
Switch to the **Publish Queue** tab and follow the numbered groups in the sidebar:
1. Fill **Store** and **Listing Locale** (e.g. en_US) in row 3.
2. Enter the **productType** from your Listing Snapshot backup (e.g. `HEADPHONES`) in the data row.
3. Click **Get Template** — it loads every attribute column for that category, like downloading the category's Excel template from Seller Central, but in-sheet.
4. Put SKU1 in the **sku** column and click **Fetch by SKU** — the whole row populates.
\[\[TODO: screenshot Publish Queue tab with Get Template, Fetch by SKU, Validate and Create/Replace/Del buttons (retake — the old one showed real store data)]]
The Publish Queue workflow — Template → Fill rows → Validate → Publish, all from the sidebar.
### 2. Edit the row into a "new product" (SKU2) [#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.
\[\[TODO: screenshot Publish Queue identifier columns: externally_assigned_product_identifier type, value and merchant_suggested_asin (retake — the old one showed real store data)]]
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.
\[\[TODO: screenshot Publish Queue GTIN exemption column and variation columns (retake — the old one showed real store data)]]
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 [#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.
\[\[TODO: screenshot Publish Queue with the SKU2 UPDATE row and the SKU1 DELETE row submitted together (retake — the old one showed real store data)]]
Two rows, one batch — SKU2 (UPDATE) creates the new product; SKU1 (DELETE) removes the old listing.
### 4. Validate, then submit [#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 [#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.
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 [#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 [#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 [#2-rebuild-sku1-pointing-at-asin2]
Back in the Publish Queue:
1. 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`.
2. **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.
3. **Validate (Preview)** → **Create/Replace/Del.**
### 3. Verify the rebuild [#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.
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 [#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 [#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):
```text
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 [#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 [#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 [#faq]
### Do I need to relabel or move my FBA inventory? [#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? [#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? [#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? [#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? [#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? [#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.