Migrating away from Ecwid to a store you own

The email that starts a move off Ecwid

The message usually comes from someone who did not set out to run a serious online shop. They had a website, a blog or a one page brochure, and at some point they added a store to it. The store grew. Now it carries a few hundred products, a subscription, a handful of trade customers who want their own prices, and it is the part of the business that pays the wages. And it is still a box embedded in a page they built for something else.

That is the shop this article is for. Not the hobby seller with ten products, who is usually right where they are, but the business that has outgrown the widget and wants a real, owned store it controls end to end. I build that store on Solidus, an open source shop framework on Ruby on Rails,¹ and I run the move. Before any of that, the honest question is what Ecwid actually lets you take with you, and what it quietly keeps.

What Ecwid is, and who is right to stay

Ecwid is not a shop platform in the way Shopify or a custom build is. It is a store you embed into a site you already have. You can drop an Ecwid storefront into a page built with WordPress, Wix, Squarespace, Joomla and others, or run it as a hosted Instant Site on a free company.site domain.² That is the whole idea, and it is a good one for the right shop. If you have an existing site and you want to start selling a few things without rebuilding anything, Ecwid gets you there in an afternoon.

Ecwid is now sold as Ecwid by Lightspeed, part of the Lightspeed Commerce family, and the control panel points you at Lightspeed Payments and Lightspeed Retail for the point of sale side.³⁴ The pricing is genuinely low: there is a free Starter plan limited to ten products, then Venture at a hundred products, Business at 2,500, and Unlimited above that, with no setup fee and no transaction fee on any plan.⁴ For a small catalogue that is a fair deal, and I will say plainly that a shop with a handful of products and no plans to grow should keep it. The buyer I am writing for is the one who has hit the edges of the widget model, not the price.

What you own, and what the widget keeps hold of

The thing to understand before you plan a move is that your Ecwid store is not an application you own. It is an account on Ecwid's servers, rendered through a storefront that belongs to Ecwid, embedded in your page through a script. Your product data, your orders and your customers are yours in the sense that you can read them out. The storefront, the checkout, the way URLs are formed and the behaviour of the shop are Ecwid's, and they do not come with you.

So a move off Ecwid is really two separate jobs. One is getting your data out cleanly, which is mostly a solved problem through the API. The other is rebuilding everything that was never data in the first place: the storefront, the checkout, the integrations, and the search presence that an embedded store only half gave you. Most of the risk, and most of the value, is in the second job.

The export is an API, not a download button

Ecwid's real export route is its REST API. It returns JSON, it authenticates with OAuth 2.0, and the overview states that it lets you access and manage any store data, including payment and shipping settings and the storefront configuration.⁵ Calls go to a base address of the form https://app.ecwid.com/api/v3/{storeId}, with separate endpoints for products, categories, orders, customers and subscriptions.⁶ That is enough to script a full, repeatable export of the shop, which is exactly what a careful migration needs: not one download, but an export you can run again and again until the import into the new shop is clean.

Two limits shape how you do it. First, the rate limit: Ecwid accepts up to 600 requests per minute per token, and over that it returns a 429 response with a Retry-After header telling you how long to wait.⁵ For a shop of a few thousand products and orders that is comfortable if you page sensibly and back off when asked, and a problem only if you fire requests blindly. Second, authentication has tightened recently. Since March 2025 the access token must be sent as a Bearer token in the Authorization header, and the old habit of putting it in the query string no longer works.⁷ Since September 2025 the store ID is a required part of the app authentication flow.⁸ Neither is hard, but a migration script written against an old tutorial will fail until you fix both.

For the deep detail of how each kind of data actually moves, which fields map to what and where the traps are, I lean on the data type guides rather than repeat them here. This article stays on what is specific to Ecwid.

Customers come out, passwords never do

The customer endpoints return a clean, useful record: the email address, the registration date, billing and shipping addresses, the customer group, tax fields, order statistics, and an acceptMarketing flag that records whether the shopper agreed to email marketing.⁹ That last field matters more than it looks, because carrying a marketing consent across correctly, with its meaning intact, is the difference between a lawful relaunch email and a complaint.

What the API never returns is a password. There is no password field and no hash anywhere in the customer object.⁹ That is normal and correct, and it is the same hard ceiling every migration hits: you cannot move what the platform never lets out. In practice it means every existing customer will set a new password the first time they visit the new shop. Handled as a surprise on launch day, that fills your inbox. Handled as a short, planned first login flow, with their addresses and order history already waiting for them, it is a relaunch rather than a mess. The deep version of this, including how to run the first login so it feels like a welcome and not a wall, is in the guide on migrating customer accounts and addresses.

Products, categories, and the SEO trap of an embedded store

Products export well. The API exposes the SKU, the base price, cost price, wholesale prices, the compare to price, weight, the full description as HTML, categories, gallery images, and the options and combinations that make up variations.¹⁰ A shop with sized or coloured products, where each combination carries its own SKU and price, comes across as a structured catalogue rather than a flattened list, which is what you want when you rebuild it properly on the other side. The mapping work, and the detail of where product data tends to go wrong, is in migrating products and catalogue data.

The part that catches Ecwid shops out is search. Because the store is embedded, your product and category URLs are not really yours. They are formed by Ecwid inside the page it renders, often as fragments or paths the widget controls, and you have limited say over them. When you move to a store you own, the URL of every product and category changes, and some of those old addresses have years of links and rankings behind them. The job is to list every old URL that earned a visit or a link in the last twelve months, decide the new address for each, and put a permanent server side redirect in place so neither Google nor a bookmark lands on a missing page. On a custom Solidus store those redirects live in the shop's own database with an admin screen, so they survive every future deploy and your own staff can add one when they spot a stray. Skip this and the traffic dip after launch will look like the new shop is worse, when it is really a few hundred pages returning a 404.

Orders and the history customers expect to see

The orders endpoint returns the records a growing shop needs to keep: the line items with their SKUs and prices, the subtotal, tax and total, the billing and shipping details, the payment method, and separate paymentStatus and fulfillmentStatus values with a full set of states from awaiting payment through to delivered or refunded.¹¹ That is plenty to bring order history across as read only records, so your customer service can look things up and customers can see what they bought.

My advice is the same as for any platform: bring a few years, not everything. Old orders point at products that may no longer exist, and each one has to map to something in the new catalogue or to a placeholder, so there is a real cost to dragging fifteen years of history along for the sake of it. And never let the new shop reuse an order number the old one issued, because your accounts and your customers both refer to those numbers. The reasoning in full is in migrating order and purchase history.

Saved cards live with the gateway, not with Ecwid

Here is the question to settle before any other, because it is the one that can quietly sink a launch. When a customer saved a card on your Ecwid shop, that card was not stored by Ecwid. It was stored by the payment gateway behind whichever integration you used, and Ecwid holds only a reference to it. You can see the shape of this in the subscriptions data, where the payment method comes back as a creditCardMaskedNumber and a card brand, never the real number.¹² The real card details sit with the processor, under its own compliance, and that is exactly how it should be.

What it means for a move is that whether your customers keep their saved cards depends entirely on the gateway, not on Ecwid. If your shop already charges through its own account with a processor, the new Solidus store can connect to that same account and the saved cards stay where they are. If the cards were held inside a gateway you reached only through an Ecwid integration, moving them means a card data export between certified processors, which some will do and some will not, and which never includes the shopper passwords or the full history. This is a whole subject in itself, covered in migrating payment tokens and saved cards, and if payments worry you, the companion piece on the hidden dangers of switching payment gateways is worth reading before you commit to anything.

Subscriptions are the part to settle first

If your shop sells a subscription, a coffee that arrives every month or a refill on repeat, this is the hardest single part of the move, and it is the one to plan first. Ecwid does expose subscriptions through the API: you can read the subscription ID, its status, the charge interval and count, the next charge date, the masked card and the order template that each renewal is built from.¹² Subscriptions are configured per product, through a subscriptionSettings block on the product itself.¹⁰ So you can read what exists.

Reading the schedule is not the same as moving the live mandate to charge the card. That mandate belongs to the payment gateway, and recreating an active subscription on a new store, charging the same saved card on the same day, usually needs the gateway's cooperation and sometimes cannot be done at all without the customer confirming again. The honest plan names this early, decides whether existing subscribers migrate silently or are asked to confirm once, and schedules the move so nobody is charged twice or missed. The full treatment is in migrating subscriptions and recurring payments. Treat it as a detail for the last week and it will be the thing that goes wrong.

The plans, and the ceiling dressed up as a tier

Ecwid's plan limits are honest and public: ten products on Starter, a hundred on Venture, 2,500 on Business, unlimited above that, with staff accounts appearing only on Business and up, and no transaction fee at any level.⁴ I want to be fair here, because the absence of a platform percentage is a real strength, and plenty of shops would pay more elsewhere.

The ceiling that matters is not the price or the product count. It is the widget itself. However high a plan you buy, the store is still embedded, the storefront is still Ecwid's, the checkout still behaves the way Ecwid decides, and the URLs are still not fully yours. You can add staff seats and products, but you cannot turn a widget into an application you own. That is the wall the growing shop hits, and no tier removes it.

What moves, what is locked, and what has to be rebuilt

What you are moving	How it leaves Ecwid	Where it lands on Solidus
Products, variations, categories, images	REST API as structured JSON, with SKUs, prices and options¹⁰	A catalogue you own, mapped field by field
Customers and addresses	REST API, with the marketing consent flag⁹	Customer accounts, with a first login password reset
Order history	REST API, items, totals and statuses¹¹	Read only history, new order numbers above the old range¹¹
Passwords	Never exported⁹	Set by each customer at first login
Saved cards	Held by the gateway, not Ecwid¹²	Kept if you reuse the same processor account, otherwise re entered
Subscriptions	Schedule readable, mandate held by the gateway¹²	Recreated with the gateway's cooperation, confirmed if needed
Storefront, checkout, URLs	Not data, they belong to Ecwid	Rebuilt and owned, with a full redirect map

If your migration plan does not have a row for each of those, it is not a plan yet.

A worked example: a Brighton roaster leaves Ecwid

Jetty Lane Coffee (jettylanecoffee.example) is an invented roaster in Brighton. It began as a WordPress blog about coffee, and three years ago it added an Ecwid store to the site to sell a few bags. Today it carries about 600 products once grind and bag size variations are counted, runs a monthly subscription that two thousand customers are signed up to, and supplies a dozen cafes who each want their own trade prices and a monthly invoice. It is on the Business plan. The owner is tired of a shop that cannot do trade pricing properly, whose checkout she cannot change, and whose product pages she suspects are holding back her search traffic.

Here is how I would run it. First, before touching the catalogue, I settle the two hard questions. Jetty Lane charges subscriptions through its own account with a payment provider, so the saved cards and the live mandates can stay with that account when the new store connects to it, which turns the worst risk into a manageable one. That single fact decides the shape of the whole project, which is why it comes first.

Then the export. I script the REST API to pull the full catalogue, the customers with their consent flags, three years of orders and the subscription schedule, paging within the 600 requests per minute limit and rerunning the whole thing against a copy until the import into the Solidus store is clean.⁵ The customers come across with their addresses and order counts but no passwords, so the launch plan includes a service message before cutover and a short first login on the new shop.⁹ The subscription schedule is read from the API and rebuilt on the new store against the same gateway account, with a dry run that charges nobody.

In parallel I build the store Jetty Lane could never have on a widget: real trade accounts with their own price lists, a checkout she owns, and product pages with clean, permanent URLs. Every old Ecwid product and category address that earned traffic is mapped to its new URL with a redirect, so the search presence she half had becomes one she fully controls. The old Ecwid store stays live and untouched for thirty days after cutover as a fallback, and only then does she cancel the plan, after one last export. The subscription nobody wanted to think about was settled in week one, not launch week, which is the whole point.

When you should not leave Ecwid

Some shops should stay, and a good adviser says so. If your catalogue is small and conventional, if the widget does everything you need, and if the only complaint is that you would like it to look a bit different, a custom build is more than you need and I would not sell you one. Ecwid with no transaction fee is hard to beat at that size.⁴ The case for moving appears when you need things the widget cannot give at any price: a checkout you control, proper trade or wholesale pricing, subscriptions on your own terms, integrations the app market does not cover, and URLs and a storefront that are genuinely yours. If you cannot name a capability you are actually blocked on, you are probably not ready to move, and that is fine.

How I run the move, and what you have at the end

The shape of the move is the same one I describe in full in the pillar guide, what moves and what does not: a discovery that settles the payment and subscription questions, a build that reruns the import until it is boring, a parallel run with the old shop frozen, a quiet weekday cutover, and the old store kept as a fallback for a month. If you want to compare the destinations properly first, the platform comparison and the five year cost of ownership lay out what a custom store costs and saves over time. If you are moving off Ecwid because a lightweight builder has run out of room, the honest counterpart is leaving Wix, which has the same embedded nature and the same traps.

What you have at the end is a store that is an application you own, not an account you rent inside someone else's page. There is no licence fee, no plan ceiling and no platform between you and your customers. The bespoke code is yours once it is paid for. And the thing that made Ecwid such an easy place to start, that it was never really your shop, is exactly the thing you have left behind. If you want to know whether that trade is worth it for your business in particular, the honest way to find out is to put your own numbers and your own blockers on the table, which is what the workshop is for. For the wider question of who holds your data while it sits on any platform, who actually owns your business data is the place to start.

Solidus, solidusio/solidus repository on GitHub (open source shop framework on Ruby on Rails, BSD 3 clause licence), https://github.com/solidusio/solidus ↩
Ecwid, Instant Site and adding an Ecwid store to an existing website (WordPress, Wix, Squarespace, Joomla and others, or a free company.site domain), https://www.ecwid.com/instant-site ↩
Ecwid by Lightspeed, About Ecwid (company page, branded "Ecwid by Lightspeed", part of Lightspeed Commerce), checked 14 November 2026, https://www.ecwid.com/about ↩
Ecwid, Pricing (Starter, Venture, Business and Unlimited plans, product limits of 10, 100 and 2,500, staff accounts on Business and up, no setup or transaction fees), checked 14 November 2026, https://www.ecwid.com/pricing ↩ ↩² ↩³ ↩⁴
Ecwid, REST API overview (OAuth 2.0 authorisation, JSON data, access to any store data, up to 600 requests per minute per token, a 429 error with a Retry-After header above the limit), checked 14 November 2026, https://docs.ecwid.com/api-reference/rest-api/rest-api-overview ↩ ↩² ↩³
Ecwid, REST API calls (base URL https://app.ecwid.com/api/v3/{storeId} and the order, product, category, customer and subscription endpoints), https://docs.ecwid.com/api-reference/advanced/rest-api-calls ↩
Ecwid, Changelog, Discontinued tokens passing in query params of API calls (tokens must now be sent as a Bearer token in the Authorization header), 20 March 2025, https://docs.ecwid.com/changelog/march-2025/march-20/discontinued-tokens-passing-in-query-params-of-api-calls ↩
Ecwid, Changelog, Store ID is now required for external apps authentication, 19 September 2025, https://docs.ecwid.com/changelog/september-2025/september-19/store-id-is-now-required-for-external-apps-authentication ↩
Ecwid, REST API, Get customer and Search customers (customer fields including email, registration date, addresses, customer group, the acceptMarketing consent flag, and no password field anywhere in the record), https://docs.ecwid.com/api-reference/rest-api/customers/get-customer ↩ ↩² ↩³ ↩⁴ ↩⁵
Ecwid, REST API, Search products and Get product (SKU, base and wholesale prices, description, categories, gallery images, options and combinations, and a per product subscriptionSettings block), https://docs.ecwid.com/api-reference/rest-api/products/search-products ↩ ↩² ↩³
Ecwid, REST API, Search orders (line items, subtotal, tax and total, billing and shipping, payment method, and paymentStatus and fulfillmentStatus values), https://docs.ecwid.com/api-reference/rest-api/orders/search-orders ↩ ↩² ↩³
Ecwid, REST API, Search recurring subscriptions (subscriptionId, status, charge interval and count, next charge date, order template, and a payment method given as a creditCardMaskedNumber and card brand rather than the full number), https://docs.ecwid.com/api-reference/rest-api/orders/recurring-subscriptions/search-recurring-subscriptions ↩ ↩² ↩³ ↩⁴