How do we handle inventory data for products that are discontinued on the old platform but still have open backorders that need fulfilling post-migration?
Discontinued SKUs with open backorders must migrate as real, fulfillable variants, which breaks the usual rule about leaving dead products behind. Set them to Active with Continue selling when out of stock enabled, fulfill the backlog, then archive. Shopify allows negative inventory only when tracking is on and that setting is enabled (per Shopify Help Center, September 2026).
Why the usual rule fails here
The standard migration advice is sound and incomplete: do not migrate products you no longer sell. It is incomplete because a product with an open backorder is not a dead product. It is an outstanding obligation that happens to be shaped like a product, and Shopify cannot fulfil an obligation it does not have a variant for.
The precise dependency: fulfillmentCreate requires lineItemsByFulfillmentOrder, and fulfillment orders are generated by Shopify's routing when the order is created (per shopify.dev, September 2026). No variant means no routable line item, which means no fulfillment, which means the backorder cannot be shipped from Shopify at all.
The four-state plan
| State | Product status | Inventory setting | When |
|---|---|---|---|
| Migration window | Active | Tracked, "Continue selling when out of stock" on | Import through backlog clearance |
| Hidden from customers | Active, but removed from all sales channels and collections | Unchanged | Same window, so it is fulfillable but not buyable |
| Backlog cleared | Draft | Unchanged | Immediately after the last backorder ships |
| Long term | Archived | Unchanged | Once no open obligation remains |
The second row is the one that gets skipped and causes the incident: a discontinued SKU migrated as Active with continue-selling enabled is purchasable by any customer who finds the URL. Unpublish it from the channels rather than deactivating it, because deactivating it removes the fulfillability you migrated it for.
How Shopify's overselling actually behaves
"Continue selling when out of stock" requires inventory tracking to be enabled first, and it permits inventory to sit at zero or below (per Shopify Help Center, September 2026). Two constraints matter in a multi-location setup:
- A product only shows as purchasable if at least one location that fulfils online orders has available stock; if every fulfilling location is at zero or negative, the item stays unavailable to customers (per Shopify Help Center, September 2026). That is useful here, because it means an unpublished, out-of-stock discontinued SKU is doubly protected from accidental sale.
- The setting does not apply to orders placed from Shopify POS (same source). A retail location can still sell something you meant to reserve for a backorder, so tell the store teams.
Reconciling the number, not just the product
Open backorders mean your legacy inventory count and your true obligation differ. Import the physical count, not the available-to-sell count, and record the backorder quantity separately as the obligation. Migrating an available-to-sell number that already had backorders netted out of it produces a Shopify balance that looks right on day one and is wrong the moment the first replacement stock lands.
When NOT to migrate the product
- When the backorder will be cancelled and refunded. Cancel and refund on the old platform before cutover. That is one operation on a live system instead of two on a system that cannot issue the refund.
- When the item will be substituted. Migrate the substitute, contact the customer, and let the original stay behind.
- When the supplier is gone and the promise cannot be kept. Migrating the SKU postpones a customer conversation that gets harder every week.
The Deploi point of view
Our own position, from building on Shopify. Separate from the facts above.
- Our take: Run the backorder list as a pre-cutover cleanup, not a migration input. Every open backorder is triaged into ship, substitute or cancel before the cutover date, and only the ship cohort earns a migrated SKU. That usually shrinks the list by most of its length, and the remainder gets the four-state plan above with a named owner and a review date.
- Where we disagree: Catalogue scope in a migration is usually decided by a rule about sales recency, because that rule is easy to write into a script. Recency is the wrong test for this cohort. The test is whether an unfulfilled promise exists, and a SKU that has not sold in two years can still carry one.
- What this page adds: that fulfillment depends on a live, routable variant, which makes a small set of discontinued products a mandatory migration item, and that the safe configuration is Active plus unpublished rather than Draft or Archived.
Reviewed by Martin Dejnicki, Director of SEO & AI Search. Facts verified 2026-09-14.
Where we worked this out
Our decision records