How to migrate your back in stock waitlist to a new app without losing subscribers

Switching back in stock apps is not the hard part. The hard part is not losing the list you already built. A waitlist is months of accumulated demand signal: real customers who told you, product by product and variant by variant, exactly what they want you to restock. Move carelessly and you throw that away. Move well and the switch is invisible to your subscribers.

This is the checklist version of that move: what to export, what the file needs to look like, what to check after you import it, and when to actually flip the switch.

Step 1: find out what your current app lets you export

Every app in this category handles export differently, and the difference matters more than any feature comparison. Before you touch a new app, log into your current one and look for an export or data-download option, usually under settings or subscribers.

You are looking for three fields at minimum:

• Email address of the subscriber
• Product (and, ideally, the specific variant: size, color, whatever applies) they asked to be notified about
• Signup date, so you can tell recent interest from something a customer asked about eight months ago and probably forgot

If your current app only exports product-level signups with no variant detail, note that now. You will need to decide whether to import everyone against the parent product (and risk over-notifying people who wanted one specific size) or drop the variant-blind rows and ask affected customers to re-subscribe. Neither is a bug in the new app. It is a gap in what the old export gave you.

If there is no export option in the UI at all, check whether the app has a support channel that will pull the data manually. A reasonable number of merchants end up here. Some apps have gone dark on active support for stretches, based on public reviews describing months without a response to export requests, so build in time for this to take longer than a UI export would.

Step 2: get the CSV into a shape any app can read

Most back in stock apps accept a CSV with a fairly small, predictable set of columns. If you are hand-building or cleaning the file, aim for something like this:

email,product_handle,variant_title,created_at
jane@example.com,mens-trail-runner,10 / Slate,2026-04-11
sam@example.com,mens-trail-runner,9.5 / Slate,2026-04-14

A few things worth checking before you upload anywhere:

• Product handle vs. product title. Handles (the URL slug) are stable identifiers; titles change when you rename a product. If your export only has titles, match them to current handles manually for anything actively being restocked, since a rename will otherwise silently break the match.
• Variant naming consistency. “10 / Slate” and “Slate / 10” are the same variant to a human and two different strings to an importer. Normalize this before you upload, not after.
• Duplicate rows. The same customer signing up for the same variant twice (once from mobile, once from desktop, months apart) is common. Deduplicate on email + variant, keeping the earliest signup date, so the customer’s original wait time is preserved for your own records even if it does not affect their notification.
• Encoding. Save as UTF-8. Accented names and non-US characters in emails or product titles will mangle silently in some spreadsheet tools if you save as anything else, and you will not notice until a send bounces.

If your old app’s export does not match a target format exactly, a spreadsheet formula pass (concatenate, split columns, find-and-replace) is usually enough. You do not need a script for a few thousand rows.

Step 3: do a small import first

Resist the urge to upload the full file on the first try. Split off 20 to 50 rows covering a mix of products, some with variants and some without, and import that first. This surfaces problems while they are cheap to fix:

• Rows that fail silently because a product handle no longer exists in your current catalog
• Variant strings that do not match anything in the new app (a renamed color, a discontinued size)
• Emails that get flagged as invalid (typos that somehow made it through the original signup form)

Check the new app’s subscriber list after this test batch. Count matches the number of valid rows you sent. If it does not, look at what did not import before you run the full file, not after.

Step 4: verify the full import against three things

Once the full list is in, check it against:

1. Total count. Compare the row count in your cleaned CSV against the imported subscriber count in the new app. A gap tells you rows were rejected, usually duplicates or unmatched products, and you want to know why before a restock relies on the number being right.
2. A product you know has active waitlist demand. Pick your highest-demand out-of-stock item from the old app’s dashboard and confirm the same rough subscriber count shows up against it in the new app.
3. Variant-level matching, not just product-level. If the new app supports variant-level alerts (it should: product-level-only notification means everyone waiting on a specific size gets an email when any size restocks, which is exactly the kind of noise that drives unsubscribes), spot-check a multi-variant product and confirm subscribers landed against the right variant, not just the parent product.

Step 5: time the cutover around your restock calendar, not your calendar

The riskiest week to migrate is the week you expect a restock. If a shipment is landing in the next few days, wait. Run the migration in a quiet week where nothing is scheduled to come back in stock, so if something needs a second look, you are not doing it under the pressure of live inventory.

The safe sequence:

1. Export from the old app.
2. Clean and import into the new app during a quiet period (no restocks expected for at least a few days).
3. Verify counts and spot-check variant matching, as above.
4. Leave both apps’ widgets live in parallel for a short window if your theme allows it, so any stragglers who visit the product page during the switch still get captured somewhere.
5. Once the new app’s import is verified, remove the old app’s widget from your theme and uninstall it.
6. Watch your very next restock closely. This is the real test, not the import count. Confirm sends went out, check the new app’s send log if it has one, and follow up with a couple of subscribers directly to confirm delivery if you want extra certainty.

That last step matters more than any of the ones before it. An import can look complete and still be wrong in ways you only see once real inventory comes back and alerts actually need to fire.

What this looks like with Kelso

Kelso’s import path follows this same shape: export your waitlist from your current app as a CSV, upload it, and subscribers, products, and variants carry over in one pass. If your old app’s export is missing variant data or has no export option at all, email support and someone will help you work out a path rather than leaving you to reconstruct the list by hand.

The short version

Export before you touch anything new. Get emails, product identifiers, and variant details into a clean, deduplicated CSV. Test-import a small batch first. Verify counts and variant matching on the full import. Migrate during a quiet week, not a restock week. And treat the next real restock, not the import screen, as the actual proof that the migration worked.