Migrating away from Wix to a custom store

What Wix is, and who tends to outgrow it

Wix is a website builder with a shop bolted on. You sign up, you drag blocks around in the editor, you add Wix Stores, and a few days later you are selling. For a founder with a small catalogue and no developer, that is a fair trade and I will not pretend otherwise. Hosting, security patches and the plumbing are someone else's problem, and the price is modest.

The move I write about here is not for that shop. It is for the business that has grown into the ceiling of the builder. The symptoms are familiar: a checkout step you cannot change, a trade price list you cannot build, a catalogue that has become slow, an integration with your accounting or warehouse that does not exist and cannot be written, and a growing sense that the shop you depend on is not really yours. When that is where you are, the question stops being which theme and becomes how do I get my business out.

This article is the honest answer for Wix specifically. The deep, platform independent detail about how each kind of data moves lives in the spokes of this series, starting with the pillar, what moves and what does not. Here I stay on the ground that is particular to Wix: what its export tools actually produce, what the APIs expose and where they stop, the traps that are special to a closed builder, and the shape of a careful move onto a custom store I build on Solidus, the open source Rails ecommerce framework.

What you own, and what stays behind

Start with the uncomfortable part, because everything else follows from it. On Wix you do not own the code, you do not own the hosting, and there is no database you can reach. Wix is a hosted service, and Wix states plainly that a site has to run on its own servers: in its words, the site "needs to be hosted and operated on Wix's servers", and "since Wix is a SaaS solution, your site must run on Wix's servers".¹ You can point a domain you bought elsewhere at it, but the site itself cannot be lifted off and moved to another host. There is no "download my shop" button, because there is no file to download.

That is the defining trait of Wix among the platforms in this series. WooCommerce hands you a database you already hold. Magento is code on a server you control. Shopify is closed too, but it exports products, customers and orders as tidy files. Wix is the most closed of the common builders, and the data you can get out of it is the least portable. So the whole plan has to be built around that limit rather than against it. You are not migrating a shop. You are reading your own data out through the gaps Wix leaves open, and rebuilding the rest.

Who actually owns the data underneath, as opposed to the software, is a separate question with a clearer answer, and I cover it in who actually owns your business data. The short version: the customer records, the orders and the content are yours. The problem on Wix is purely how you get to them.

What comes out cleanly, and what does not

It is tempting to say you cannot get anything out of Wix. That is not true, and overstating it would make the rest of the advice worthless. Wix has real CSV export for products, contacts and orders, and a set of REST APIs for the bulk work. The honest picture is a spectrum, and this table is the one to pin above the project.

What	How it comes out	The catch
Products	Product list export to CSV, or the Catalog API	5,000 rows per file, physical products only, plain descriptions
Categories	A separate CSV	Images are filenames, not files
Images and video	References inside the product CSV	Only IDs and URLs, never the files, so you download and rehost each one
Contacts	Contacts export to CSV	Up to 50,000 per export, owner only
Orders	Orders export to CSV, or the Orders API	Times are in UTC, acting on old orders stays behind
Member passwords	Never	Wix runs the logins, nobody can read them
Saved cards	Never	Held by the processor, no export exists
Active subscriptions	Records only	The live billing arrangement does not travel
Rich content, digital files, reviews	Mostly not	Rebuild, recollect or use a separate tool

The pattern is clear. Your catalogue and your contact list come out with mapping work. Orders come out as records. Anything tied to identity or money, meaning passwords, saved cards and live subscriptions, does not come out at all, and that is where the plan earns its keep.

The product export, field by field

The product export is the strongest part of the story. From the Products tab you select all, filtered or specific products, open More Actions and choose Export, and Wix writes a CSV.² The import and export format is documented, and it carries the fields a catalogue actually needs: a handle to tie rows together, name, a plain text plainDescription of up to 16,000 characters, sku, barcode, price, strikethroughPrice, cost, inventory, a ribbon, categorySlugs, weights and package dimensions, and product options and modifiers.³ Variants export as their own rows, marked with a field type of VARIANT, sharing the parent product's handle. This maps well onto the product model of a real shop, and it is the clean part of a Wix move.

Three limits matter. First, the export is capped at 5,000 rows per file, and because images take their own rows, a product with several photos consumes several rows, so the real product ceiling per file is well under 5,000.² A larger catalogue means several files and a careful join. Second, the description that comes out is the plain text field only. Any formatted content, info sections or rich layout you built in the Wix editor is not represented as rich content in the CSV, so product pages that lean on formatting have to be rebuilt.³ Third, digital products cannot be exported at all, and Wix states that exporting digital products is not currently supported.² If you sell downloads, that catalogue and its files are collected again by hand.

Categories come out through a separate CSV, with their own columns for name, parentPath, slug, description and an image that is only the file name, not the file. Wix imports up to 1,000 categories at once and nests up to five levels deep.⁴ So the category tree is portable as structure, but the category images, like all images, have to be fetched separately.

For anything past the CSV caps there is the Catalog V3 Products API, which exposes products, variants, options, media and categories for programmatic export. It pages in blocks of up to 100 products per call, and the search method does not return variant data, so a full pull means paging the list and then calling the product endpoint again for each product's variants.⁵ This is how I lift a large catalogue out properly rather than wrestling with 5,000 row files.

Contacts, orders and members

Your contact list exports to CSV from the Contacts area, in a regular, Google or Outlook format. The ceiling is 50,000 contacts per export, and only the site owner can run it. The Google format quietly drops labels and some fields, so the regular CSV is the one to use.⁶ For most shops this is enough to carry names, email addresses, phone numbers and addresses across. What it cannot carry is the one thing no export ever carries: the password. Wix runs the authentication itself, members sign in against Wix, and an owner can reset a login but never read it, so there is no password in any export or any API.⁷ Every customer account therefore arrives on the new shop without a password, and the customers reactivate on their first visit. The deep handling of that, including why passwords are hashed and never move, is the subject of the customer accounts and addresses spoke, and it applies to Wix without exception.

Orders are better than their reputation. There is a native orders export to CSV from the Orders tab: you select orders, choose a layout of one row per line item or one row per order, pick the columns including billing and payment, and save.⁸ A gotcha worth writing down is that the purchase times in the export are always in Coordinated Universal Time, not your local time, which matters when you reconcile against your accounts.⁸ For a bulk and complete pull there is the ecommerce Orders API, whose search method pages through full order records with line items, totals, addresses and payment and fulfilment status.⁹ So order history comes across as records your customer service team and your customers can read. What does not come across, on any platform, is the ability to act on an old order, a refund or a reorder, inside the new system, and that nuance lives in the order and purchase history spoke.

Saved cards and subscriptions, the hardest part

This is where a Wix move is hardest, and where I am most careful not to promise what cannot be done.

Wix offers its own gateway, Wix Payments, alongside more than seventy other providers.¹⁰ Wherever the card is saved, it belongs to the processor, not to the shop, and Wix documents no way to export saved cards or payment tokens. There is no token export, so after a move customers enter their card again, unless the card lived in your own account with a processor you keep using. The one good outcome is the shop that already runs its own Stripe or similar account: the new Solidus shop connects to that same account and the saved cards stay where they are. The mechanics of that, and why a token is not a card number, are the subject of the payment tokens and saved cards spoke, and it is worth reading before you decide anything about payments.

Subscriptions are harder still. If you run recurring plans through Wix Pricing Plans, every plan order corresponds to a Wix subscription, and you can view each customer's subscription and payment history in the dashboard.¹¹ You can read those records in bulk through the Pricing Plans Orders API, which lists up to 50 orders per call.¹² But reading is all you get. Wix documents no way to export an active subscription as a billing arrangement, and no way to transfer a live mandate to another platform, and tellingly the same API can create only offline orders, not the online recurring arrangements where Wix handles the payment.¹² In practice that means a subscription business leaving Wix has to reestablish every customer's payment authorisation on the new processor. The active mandate does not travel. I plan that as its own project, following the subscriptions and recurring payments spoke, and I am honest with the client that some churn at the changeover is unavoidable.

The URL map and Wix's redirect ceiling

Every product, category and content page on the old Wix site has a URL that may carry years of links and search rankings, and losing them quietly loses money. Wix Stores product pages follow a fixed default pattern, /product-page/{slug}, where the slug defaults to the product name and the prefix can only be removed site wide in the SEO settings.¹³ A custom shop uses whatever paths you choose, so the old and the new almost never line up, and the gap between them is a redirect map.

Google's own guidance for a move that changes URLs is the rule I follow: map every old URL to its new one, use server side permanent redirects such as 301, and keep those redirects for as long as possible, generally at least a year.¹⁴ The catch on Wix is a hard ceiling. The URL Redirect Manager lets you create a maximum of 5,000 redirects per site, and a CSV import is capped at 500 redirects per file.¹⁵¹⁶ For a large catalogue that ceiling is a real problem if you ever needed to run redirects from inside Wix, and it is one more reason the redirects belong in the new shop instead, where there is no such cap and they survive every future deploy. On the shops I build, the redirects are a database table with an admin screen, so your own staff can add one when they spot a stray in Search Console. The SEO side of a catalogue move, slugs and canonicals and the map itself, sits in the products and catalogue data spoke.

Media and rich content you have to rebuild

Images are the quiet cost. They are never embedded in the export. Each image, animation or video is its own row in the product CSV, and the media column holds only an identifier or a URL, never the file.³ The files sit on Wix's own media store, and the documented way to get one is to open the image in the Site Files area and copy its URL, one at a time. There is no bulk "download all media" feature. So a real migration downloads every file from its Wix URL and rehosts it on the new shop's own storage, then rewrites the references. For a few hundred products that is a scripted job against the Catalog API, and it is work, but it is boring work, which is the best kind.

The rich content is the part people forget. The formatted descriptions, the info sections, the custom page layouts you built in the Wix editor, the blog if you used Wix Blog, and anything an installed Wix app added: none of that exports as structured content. It is recreated on the new shop. This is the honest reason a Wix move costs what it costs. You are not porting a shop, you are rebuilding the storefront around data you have read out, and the data you read out is the catalogue, the contacts and the orders, not the look and feel.

A worked example, a Brighton pottery leaving Wix

Let me make it concrete with an invented business. Saltdene Clayworks (saltdene.example) is a Brighton pottery that sells handmade tableware and runs a monthly glaze club, a subscription that sends two pieces and a card every month. It has been on Wix for five years, has about 650 products with variants for size and colour, around 9,000 contacts, and roughly 400 glaze club members paying through Wix. It turns over about £520,000 a year online. The shop has outgrown the builder in three ways. The trade customers, a handful of Sussex restaurants, want a price list and invoicing Wix cannot give them. The glaze club needs rules Wix cannot express. And the catalogue has grown slow.

Here is how the move actually went in the plan I would write for them.

What moved cleanly. The 650 products came out through the Catalog API in a morning, variants and all, and mapped onto the new product model with a day of checking the options and the ribbons. The category tree, four levels deep, imported from the category CSV. The 9,000 contacts exported in a single file, well under the 50,000 ceiling, and came across with names, emails and addresses intact.

What had to be rebuilt. Every product image, about 2,100 files, was downloaded from its Wix URL by a script and rehosted on the new shop, then relinked. The formatted descriptions and the two info sections per product did not export as rich content, so the plain descriptions came across and the formatting was rebuilt into a consistent template, which was an improvement rather than a loss. The storefront, the glaze club rules and the trade price list were built fresh, because that is the whole point of the move.

What had to be recollected. No customer password came across, so on cutover every account existed in the new shop with its addresses and order history, flagged as not yet activated, and the first visit led to a short page that set a new password. The 400 glaze club members were the hardest line. Their Wix subscriptions could be read but not transferred, so Saltdene set up the club afresh on its own Stripe account and asked members, in a plain service message, to confirm their subscription once. About 90% did within two weeks, and the rest lapsed, and that loss was budgeted for from the start rather than discovered on the day. The order history of the last three years came across as read only records so customers could see their past orders and the shop could look them up.

The result after cutover is a shop Saltdene owns outright, on hosting it controls, with the trade price list and the glaze club as real features rather than compromises, and no part of it that Wix can switch off. The honest cost was the images, the rebuilt content and the subscriber reconfirmation, and none of that was hidden.

When Wix is the right place to stay

I would be no use to you if I only ever said move. Stay on Wix if your shop is small and simple, your catalogue is modest, you have no developer and do not want one, and the builder does everything you need. The closed nature that makes Wix hard to leave is the same closed nature that means you never patch a server or worry about a plugin, and for a shop that is one channel among several rather than the business itself, that is a good trade.

Stay, too, if the only complaint is the monthly bill and the bill is bearable. A migration off Wix carries more rebuild than a migration off a more open platform, precisely because so much has to be recreated, so the capability wall needs to be real before it is worth the work. And never start a migration in the weeks before your busiest season. If you cannot name the person in your business who understands the data, the trade customers, the product codes, the subscription rules, fix that before you move, because a rebuilt shop full of misunderstood data is worse than the one you have.

The wider comparison of where Wix sits against Shopify, Shopware, Magento, WooCommerce and a custom build is in the platform comparison, and the five year money is worked through in the total cost of ownership article. If you are weighing Wix against the other builder people ask about, the same logic and much of the same method apply to leaving Squarespace.

The honest move plan

Because so little comes out of Wix on its own, the plan has to decide early what you keep, what you snapshot and what you rebuild. Analytics is the clearest case: Wix will not hand you a clean history of your traffic and sales for forecasting, so you snapshot what you need before cutover and start the new measurement clean, which is exactly the framing in the analytics and historical data spoke.

The shape I use is always the same. Discovery settles what migrates, who owns the data and which payment provider stays. The build runs the export and import scripts again and again against a copy of the real data, so the final run holds no surprises, and the storefront, the rules and the integrations are built with tests. Then a parallel run of a few weeks, with the old Wix shop frozen so the catalogue does not drift, the service message sent, and the final import rehearsed twice. Cutover happens on a quiet weekday morning: the final export, a count check, the domain pointed at the new shop, a real test order and refund for each payment method, the top URLs from the redirect map checked by hand, and the service message sent. The old Wix site stays exactly as it is for thirty days as the fallback, and only then, after one clean month end, is the plan cancelled.

Through all of it the law does not change with the software. The shop stays the controller of its customer data, each processor needs a written contract, the lawful basis for order history and the marketing consents carry across with their timestamps rather than as a bare yes or no, and the service message that tells customers to reactivate is information about their account, not marketing, and must be kept separate from any launch voucher. The pillar covers that in full.

What I would tell you in the workshop

Wix is a good builder and a hard thing to leave, and both of those are true at once. The move off it is less about export buttons and more about planning around the data Wix will not give you: the passwords you cannot read, the saved cards you cannot take, the subscriptions you cannot transfer, and the rich content you have to rebuild. Everything else, the catalogue, the contacts, the orders, comes out with work. If you go in knowing which of those four hard lines apply to you, the move is a project, not a gamble.

Wix Help Center, Exporting or embedding your Wix site elsewhere ("needs to be hosted and operated on Wix's servers", "since Wix is a SaaS solution, your site must run on Wix's servers"), accessed 14 November 2026, https://support.wix.com/en/article/exporting-or-embedding-your-wix-site-elsewhere ↩
Wix Help Center, Wix Stores: Exporting your product list (export to CSV, up to 5,000 rows per file, exporting digital products not currently supported), accessed 14 November 2026, https://support.wix.com/en/article/wix-stores-exporting-your-product-list ↩ ↩² ↩³
Wix Help Center, Wix Stores: Exporting and importing your products (CSV field schema including handle, name, plainDescription, sku, price, variants and media rows, import limit 15MB and 10,000 rows), accessed 14 November 2026, https://support.wix.com/en/article/wix-stores-exporting-and-importing-your-products ↩ ↩² ↩³
Wix Help Center, Wix Stores: Updating categories by exporting and importing them (separate category CSV, image as file name, up to 1,000 categories and five levels of nesting), accessed 14 November 2026, https://support.wix.com/en/article/wix-stores-updating-categories-by-exporting-and-importing-them ↩
Wix for Developers, Stores Catalog V3: Search Products (retrieves up to 100 products per call, does not return variant data), accessed 14 November 2026, https://dev.wix.com/docs/rest/business-solutions/stores/catalog-v3/products-v3/search-products ↩
Wix Help Center, Exporting your contacts (regular, Google and Outlook CSV formats, up to 50,000 contacts per export, owner only, labels not exported in the Google format), accessed 14 November 2026, https://support.wix.com/en/article/exporting-your-contacts ↩
Wix for Developers, About member login (Wix hosts the login and runs authentication, members sign in with an email and password that Wix checks; owners can reset but not read a password), accessed 14 November 2026, https://dev.wix.com/docs/go-headless/authentication/members/about-member-login ↩
Wix Help Center, Wix Stores: Exporting store orders (export orders to CSV, one row per item or per order, selectable billing and payment columns, times given in Coordinated Universal Time), accessed 14 November 2026, https://support.wix.com/en/article/wix-stores-exporting-store-orders ↩ ↩²
Wix for Developers, eCommerce Orders: Search Orders (paged order records with items, totals, addresses, payment and fulfilment status), accessed 14 November 2026, https://dev.wix.com/docs/api-reference/business-solutions/e-commerce/orders/orders/search-orders ↩
Wix Help Center, Accepting payments: an overview (Wix Payments plus more than 70 third party providers, no export of saved cards or payment tokens is documented), accessed 14 November 2026, https://support.wix.com/en/article/accepting-payments-an-overview ↩
Wix Help Center, Pricing Plans: Viewing a client's subscription and payment history (subscriptions and payment history are viewable in the dashboard, no export or transfer function is documented), accessed 14 November 2026, https://support.wix.com/en/article/pricing-plans-viewing-a-clients-subscription-and-payment-history ↩
Wix for Developers, Pricing Plans Orders API (every plan order corresponds to a Wix subscription, List Orders returns up to 50 orders per call, online orders where Wix handles payment cannot be created through the API), accessed 14 November 2026, https://dev.wix.com/docs/rest/api-reference/wix-pricing-plans/pricing-plans/orders/introduction ↩ ↩²
Wix Help Center, Customising your page URL structure in SEO Settings (Wix Stores product page pattern https://domain.com/product-page/{slug}, the product-page prefix is removable site wide), accessed 14 November 2026, https://support.wix.com/en/article/customizing-your-pages-url-structure-in-seo-settings ↩
Google Search Central, Site moves with URL changes (server side permanent redirects such as 301 for every old URL per the mapping, keep redirects generally at least 1 year), accessed 14 November 2026, https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↩
Wix Help Center, Setting up a 301 redirect for a page on your site ("You can create a maximum of 5,000 redirects per Wix site"), accessed 14 November 2026, https://support.wix.com/en/article/setting-up-a-301-redirect-for-a-page-on-your-site ↩
Wix Help Center, Importing or exporting URL redirects with a CSV file (each file can include a maximum of 500 redirects), accessed 14 November 2026, https://support.wix.com/en/article/importing-or-exporting-url-redirects-with-a-csv-file ↩