Migrating 13,000 customers off Wix without locking anyone out

Most platform migrations are a content problem. You move pages, you map URLs, you redirect the old ones, and the work is essentially finished. A store that sells digital products is not that. The thing you are moving is not content — it is an entitlement: a durable claim by a named person on a file they have already paid for. Break the content and someone reads a 404. Break the entitlement and someone who paid you cannot get what they bought.

Miss Angler sells digital products and had roughly thirteen thousand customers with live orders on Wix. The brief was a full design and development rebuild on WordPress, with organic traffic protected. The design was the visible half. The half that decided whether the project succeeded was moving thirteen thousand entitlements without a single person losing access to a purchase.

It is worth being precise about this, because the list is longer than it first appears and the last item is the one that gets forgotten until launch week.

1. Customer accounts — the identity a person signs in with, and the email address that identity is keyed to.
2. Order history — what each person bought, when, at what price, under which tax treatment. This is a financial record, not a nice-to-have.
3. Entitlements — the mapping from an order line to the specific file it grants, plus whatever limits apply to that grant.
4. URLs — every indexed product, collection and article, mapped to its new address.
5. Credentials — which you cannot move, and which therefore shapes the entire plan.

You cannot migrate passwords. Not because of an export limitation but because of how password storage is supposed to work: a competent platform stores a one-way hash under its own algorithm and parameters, and it does not hand that hash to anyone — including you, including the merchant who owns the store. Any migration path that assumes customers will simply sign in on the new site with their old password is built on a false premise.

That single fact reorders the whole project. It means every one of those thirteen thousand people has to establish a new credential on the new platform. It means the migration is not really a data task at all — it is a communications task with a data task inside it. And it means the failure mode is not a broken database. It is thirteen thousand people receiving an email at once, a proportion of them not receiving it because the sending domain has no reputation, and the remainder arriving in an inbox that cannot tell your message apart from a phishing attempt asking them to reset a password.

Wix will give you a contact export and an order export. What it does not give you is the join between them expressed in the form the destination needs. WooCommerce grants file access through a permissions table that links a customer, an order, a product and a downloadable file. Nothing in a Wix export is shaped like that row. It has to be reconstructed.

The reconstruction is mechanical once the product identifiers line up, and the product identifiers never line up on the first pass. Ours needed a deliberate mapping stage — old product reference to new product reference to the specific file attached to it — built and checked before a single customer record was imported. Products that had been renamed, bundled, retired or replaced over the store’s life all surface here, and they surface as ambiguity rather than as errors.

• Retired products still attached to live entitlements — someone paid for a file you no longer sell, and they are still entitled to it.
• Bundles that granted several files from one order line, where the destination expects one row per file.
• The same product sold under two references after a rename, splitting one customer’s history in two.
• Orders against an email address that no longer matches the account that placed them.

None of these are exotic. Every store of any age has all four. They are only expensive if you meet them during cutover instead of during preparation.

The obvious approach is to import everyone as a WordPress user and trigger the standard password reset. It works, and it is the wrong choice at this size. The standard reset email is transactional boilerplate that arrives unrequested, reads like a security incident, and gives the recipient no reason to trust it.

We treated it as an account claim instead. Same underlying mechanism — a single-use token, short expiry, no password in transit — but the message leads with what the person already owns rather than with a security instruction. It names the store they bought from, states plainly that the store has moved platform, and sends them to a page that shows their purchase history before it asks them to set anything. Establishing that this is their account, with their orders in it, is what earns the credential.

Two operational rules go with it. Send in batches small enough that the sending domain builds reputation rather than burning it, oldest and most engaged customers first — they are the least likely to mark it as spam, and early positive engagement is what carries later batches to the inbox. And never make the claim link the only route to a file: the support path where a human verifies the order and restores access manually has to exist from day one, because a percentage of thirteen thousand people will always need it.

The commercial risk running alongside the entitlement risk is search. Wix and WordPress do not agree on URL structure, so every indexed address changes at once. A migration that quietly drops its rankings costs more over the following year than the build did.

The discipline here is unglamorous: enumerate the real URL inventory from the live site, search data and server logs rather than from the sitemap alone, map every one of them to a destination, and serve permanent redirects at cutover with no intermediate hops. Redirect chains are where this work usually degrades — each hop is a place a mapping can be lost during a later change.

The part people underestimate is the delta. Between the moment you take your final export and the moment DNS actually resolves to the new platform for everybody, the old store keeps taking orders. Those orders exist only on the platform you are leaving, and they belong to customers who will look for them on the platform you are moving to.

• Drop DNS TTL well before the switch so propagation is minutes, not a day.
• Take a final delta export after the old store stops accepting orders, not before.
• Keep the old platform readable — not live, readable — until the delta is reconciled and the first support cycle is clear.
• Reconcile order totals between platforms as a financial check, not just a record count. Counts match while values quietly do not.

Build the product mapping table first, before design, before anything. On this project it was ready early and it still surfaced ambiguity that needed the client to make decisions only they could make — which product a retired reference should now grant, whether a discontinued bundle should still resolve. Those are business decisions wearing technical clothes, and they take days of back-and-forth rather than hours. Every day of that which happens before the build starts is a day it does not delay the launch.

The second thing: instrument the claim flow before sending the first batch, not after. Knowing which step people abandon — the email, the landing page, the password field — changes the copy of every subsequent batch. With thirteen thousand recipients you get a genuine sample from the first few hundred, but only if you were measuring.

The design decides whether people buy. The entitlement table decides whether the people who already bought stay.