When a provider closes: migrating a saved finds list

The asset at risk when a provider closes is not the account, it is the list. An account can be recreated in an afternoon; a saved set of finds assembled over a year cannot. The window for getting it out is also shorter than the announcement suggests, because a platform preparing to close commonly moves to a read-only state before it goes dark, and exporting from a read-only interface is somewhere between awkward and impossible depending on what the interface allowed.

So the export happens on the day the news lands, not the week before the shutdown date. Whatever the platform offers as an export, take it, including a format you do not need yet. Where no export exists, render the list and capture the rows as they appear, page by page, and keep a plain text file of the identifiers alongside it. Two copies, in two places, one of which is not the browser you are reading this in.

Then verify the export rather than trusting it. Open the file in a fresh session, count the rows, and check three random entries against the live list. An export that silently dropped a page, or that saved display titles without identifiers, is a file that looks complete and is not, and the failure surfaces weeks later when the source is gone and cannot be checked against.

The stronger form of this rule is a schedule rather than a rescue. A quarterly copy costs a few minutes and converts the shutdown problem from an emergency into a routine, and it means the list you eventually migrate is at most one quarter old with its fields already in the shape you want. Two copies only counts as two if they do not share a failure mode: a file on a laptop plus a copy inside a service tied to the same login is one copy when the login is what closes. Work out which of your storages would survive losing access to the platform, and make sure at least one of them is on that list.

What is portable across providers is the marketplace's own identity for the item: which marketplace it came from, the item identifier, the seller identifier, and the parameter string that describes the specific variant. What is not portable is the agent's internal reference for the same thing. An internal reference is proprietary, it means nothing outside the system that issued it, and when that system closes the reference closes with it.

Display titles are the trap, and they are the field most exports preserve best. Titles are not identifiers: near-duplicate listings share most of a title, sellers rewrite titles seasonally, and a search built on a saved title returns a family of listings rather than the one you saved. Keep the title if you like, as a human label, but never as the key.

The parameter string deserves its own sentence because it is the field people edit by hand and get wrong. A variant parameter is a set of values bound to a specific listing, and copying it into a listing that has been re-listed or restructured can produce a valid-looking order for the wrong variant. Preserve the parameter string exactly as recorded, and if the listing has changed since, treat the row as needing re-verification rather than as ready to order.

The export that survives a migration is the one whose columns are boring. One row per variant, rather than one row per item with the variants described inside a single cell, because a family of options stored in one field loses exactly the parameter you will need later. The marketplace name in its own column, so that a list assembled from three sources stays sortable and filterable. And a notes column kept strictly apart from the key fields, because human remarks written into an identifier field eventually get pasted into a form as though they were an identifier, and the resulting failure is silent until a warehouse reports that the item delivered is not the item requested.

A list carried across a migration is stale by construction. Every row in it was recorded under a different provider's operation, and the newest rows are as old as the day you stopped using that provider. The list is still valuable, but it is valuable as a set of leads rather than as a set of ready orders, and the distinction has to be acted on before anything is bought from it.

So the migration includes a re-check pass, run row by row, on four fields: whether the item identifier still resolves, whether the seller identifier matches the row, whether the parameter string is still present on the listing, and how old the saved review date is. Sort the pass by review date, oldest first, because the oldest rows are where the failures concentrate and where the fastest decisions can be made.

Expect a meaningful share to fail on the first pass, and do not treat that as evidence that the list was bad. In the three lists we migrated, between a fifth and a third of saved entries failed the four-field check on the first pass, and the failures were concentrated in rows whose saved review date was more than nine months old. The rows that failed were also the cheapest to drop, which is the argument for running the check before you re-order anything rather than alongside it.

Run the pass across three sittings rather than one, because the checks degrade at different rates. The first sitting resolves identifiers and removes the dead rows. The second confirms sellers and flags the rows whose seller has changed while the listing survived. The third checks parameters against the current listing, which is the slowest pass and the one that catches the expensive errors. A single sitting over two hundred rows ends with the final fifty skimmed, and skimmed rows are precisely the ones that turn into a wrong variant arriving at a warehouse four weeks later.

Some things simply do not move, and knowing the list prevents the most expensive kind of surprise, which is discovering it during a shutdown week when support queues are longest. Any account balance held on the closing platform is the first item: it is a liability of that platform and it does not transfer. Withdraw it, or spend it on freight for a parcel already in the warehouse, before the read-only state arrives.

Second, the physical and semi-physical holdings. Warehouse storage days do not transfer, so a parcel sitting in the closing provider's warehouse has to be shipped out or forwarded rather than left. Parcels already in transit need their tracking numbers recorded outside the platform, because the tracking number survives the platform and the platform-side context does not. Inspection photographs are frequently purged after a retention period, so anything you might need for a future claim should be downloaded while the account still opens.

Third, the records of things in flight administratively: open disputes, pending refunds, order threads with sellers, and any saved private notes that the export format omits. None of these are recoverable from the marketplace side, and all of them are cheap to capture as text while the interface still renders. The migration order that has worked for us is settle the balance first, then move the physical holdings, then take the list. Capture the administrative records as plain text in one dated file per account, because text survives every format change and every platform shutdown. For each open item, record the reference, the date it was opened, the last reply and who sent it. A tracking number copied into that file is worth more than a screenshot of a tracking page, since a number can be queried anywhere while a screenshot only proves what a page said on one afternoon.

What does migrate cleanly is the part that was always yours: the marketplace identifiers, the parameter strings, the dates you recorded, and the notes you kept outside the platform. That is the practical argument for keeping a list in a file you control rather than only in an account you do not, and it is the same argument that makes a dated, identifier-keyed list survive every other kind of provider change as well.