Migrating away from Lightspeed eCommerce to a custom store

Which Lightspeed this article is about, because the name matters

Lightspeed sells more than one thing, and the names overlap enough to cause real confusion when you plan a move, so I want to be exact before anything else. This article is about Lightspeed Ecommerce, the hosted online store that Lightspeed labels eCom (C Series).¹ It is the online shop you log into through an eCom back office, the former standalone Ecommerce product, and Lightspeed still supports and updates it.² It is not the point of sale, and it is not the newer online store that used to be a separate company.

Three Lightspeed products sit next to each other, and keeping them apart is the first step of a sane migration.

The first is Lightspeed Retail POS, the till, which Lightspeed now calls R Series, with the former Vend product renamed X Series.¹ This is what rings up a sale in a shop. The second is the online store this article covers, eCom (C Series), which can run on its own or bolted on top of Retail POS so the shop and the till share one catalogue. The third is eCom (E Series), which is the former Ecwid, a separate online store product that Lightspeed bought in 2021 and now treats as its flagship ecommerce offering.³⁴⁵ Ecwid and eCom (C Series) are different pieces of software with different back offices, different APIs and different histories, and a plan that confuses the two will export from the wrong place. If your shop is the lightweight widget you embed into an existing website, you are probably on Ecwid, the E Series, and the honest guide for you is leaving Ecwid. If you log into a full eCom back office with its own storefront, you are on the C Series, and this is the right article.

Who should stay on Lightspeed eCom, and who outgrows it

I build custom shops on Solidus, so you know where I stand, which is exactly why I will be fair about Lightspeed. For a retailer that already runs Lightspeed Retail POS in one or two shops and wants an online store that shares the same products and stock, eCom is a sensible, tidy answer. One company, one catalogue, one support line, and a storefront that goes live quickly. If that describes you and it is working, this article is not a nudge to leave. Staying on the platform your till already uses is often the right call.

The shop that outgrows it is the one where the online store has become the centre of the business rather than a window onto the shop floor. You want a checkout step the theme will not give you, a trade price list for account customers, a bundle or a configurator, a deep link into an accounting or warehouse system, or simply a storefront that looks like nothing else and loads the way you want. At that point the hosted store starts to feel like a rented flat you are not allowed to rewire, and the fact that it is tied to your till makes the walls feel closer still. This is the honest, specific guide to leaving eCom (C Series) for a store you own, written from Lightspeed's own documentation, checked in November 2026. For the platform independent picture of what a move involves, start with what moves and what does not, which I lean on here rather than repeat.

What you take with you, and what stays behind

Lightspeed lets you export your core data, and that is to its credit. Products, customers and orders all come out of the eCom back office as CSV files.⁶ What does not come with you is the shell Lightspeed built around that data: the theme, the apps from its ecosystem, the checkout, and the payment arrangement. Those are rebuilt or replaced rather than moved, which is simply what a hosted platform means and what a good migration prices in rather than discovers on the day.

One ceiling is worth stating plainly at the start, because it is the same on every serious platform. Customer passwords never export. They are stored as one way hashes, not as readable text, so no export of any kind hands them over. Your customers will set a new password, or sign in with a one time code, on their first visit to the new store, and that moment has to be planned as a friendly relaunch rather than a surprise. How accounts and addresses carry across, and how to run that first login well, is the subject of migrating customer accounts and addresses.

The CSV export, and where it stops

The export itself is straightforward. In the eCom back office you go to Tools and then Exports, add an export, choose the data type and a date range where one applies, and the file is prepared in the background and delivered as a CSV by email or download.⁶ Products, customers and orders each export this way, along with inventory, invoices, shipments and more.⁶ Two details matter for planning.

The first is housekeeping. Lightspeed deletes export files automatically after thirty days.⁶ That is fine for a migration where you pull the data and load it straight into the new store, but it means an export is a live download to use promptly, not an archive to leave sitting in your account for later.

The second is the point where CSV runs out. A flat file is a snapshot of rows and columns. It is excellent for the bulk of a catalogue and for customer and order lists, and clumsy for anything with a rich structure, nested data, or fields the export simply does not include. For a clean, repeatable migration of a larger shop, and for anything the CSV leaves behind, you move to the API. The deeper mechanics of mapping a catalogue, with its variants, options and images, live in migrating products and catalogue data, and the shape of order history in migrating order and purchase history.

The eCom API, and the rate limit that sets your pace

Lightspeed eCom has a proper REST API, built for single shop connections to tools like accounting, email and inventory software.⁷ It exposes the resources a migration needs, including products, variants, customers, orders, categories, invoices, shipments and webhooks, and it answers in JSON or XML.⁷ There are two regional clusters, with the European one served from api.webshopapp.com and the North American one from api.shoplightspeed.com, a small reminder that the C Series grew out of a European webshop platform rather than being built inside Lightspeed from scratch.⁷

The detail that shapes every migration script is the rate limit, and Lightspeed publishes it clearly. Per shop API key you may make 300 requests every 5 minutes, 3000 per hour and 12000 per day, with a further ceiling of 20 requests per second per API key per shop.⁸ An app key has no limit of its own and instead shares the limit of the shop that installed it, and higher limits are arranged through a sales representative.⁸ None of this is a wall. It is a speed limit, and it is a generous one for a one off migration. A shop with a few thousand products and a few years of orders fits comfortably inside the daily budget if the import is written to pull in pages and pause when it should, rather than hammering the endpoint and spending the afternoon throttled. I write migration scripts that treat the limit as a given from the first line, so the pull is steady and boring, which is what you want.

The honest summary of the export reality is a fair one. Lightspeed gives you your data, the CSV covers the common cases, and the API covers the rest within a published and workable rate limit. The harder parts of leaving are not the data you can read. They are the things Lightspeed holds around it.

The ecosystem lock, which is the real reason it feels sticky

The thing that makes eCom (C Series) harder to leave than a plain online store is that it is often not a plain online store. It is one corner of a Lightspeed ecosystem.

When eCom runs on top of Lightspeed Retail POS, the till and the online shop share one product catalogue, and a catalogue export from eCom will include the products managed from the Retail back office as well.⁶ That shared spine is convenient while you stay and awkward when you leave, because the online store you want to replace is wired into the system that also runs your shop floor. Leaving the online store cleanly means deciding, early, what happens to the till: whether Retail POS stays and feeds the new custom store through its API, or whether the whole stack moves. That is a business decision, not a technical one, and it belongs in the first conversation, not the last.

Payments are the other half of the lock. Lightspeed offers Lightspeed Payments as the integrated gateway for the online store, connected with a click for a merchant already using it, and it is the easiest option precisely because it is built in.⁹ Easy to switch on is the same as hard to carry away. The card details your customers saved, and any stored credentials behind repeat purchases, sit with the payment gateway, not in a field you can export from the shop. Whether those saved cards can move at all depends on the gateway and its certification, and it is the single question that can decide whether a migration is smooth or painful. I cover why in migrating payment tokens and saved cards, and before you commit to any date, read the hidden dangers of switching payment gateways, because this is where a careless move breaks.

There is a theme lock too, the quiet one. The storefront is built from a Lightspeed theme and the platform's own templating, and it does not run anywhere else, so the design is rebuilt rather than lifted. That is not a scandal. It is the price of a hosted storefront, and it is worth remembering that a rebuild is also a chance to fix everything the old theme would never let you change.

The URLs, and the redirect map that protects your rankings

Every product, category and page on the old store has a URL, and some of those URLs have carried your search rankings and inbound links for years. When the store moves, those addresses change unless you plan otherwise, and a URL that returns a 404 after cutover is a page that has quietly lost its place in Google.

The deliverable that prevents this is a redirect map: a spreadsheet listing every old URL that earned a visit or a link in the last year, the new URL it should point to, and a permanent redirect joining the two. Google's own guidance for a move with URL changes is to map every old address to its new one, use permanent server side redirects, point each one straight at its final destination rather than through a chain, and keep the redirects in place for as long as possible, at least a year.¹⁰ On the stores I build these redirects live in a database table with an admin screen, so your own staff can add one the moment they spot a stray in Search Console, and so they survive every future deploy. The SEO and redirect detail sits alongside the catalogue in migrating products and catalogue data.

One current note, since the platform keeps changing under you: Lightspeed added a required withdrawal request page for customers in the EU and EEA from 19 June 2026, part of a steady stream of compliance changes a hosted platform makes on its own schedule.¹¹ On a store you own, changes like that are features you decide to build when the law asks, not updates that appear overnight and may not fit how you work.

What moves, what moves partly, and what is locked

What you are moving	How it moves off Lightspeed eCom	Where the detail lives
Products, variants, prices, images, categories	CSV from Tools and Exports, the eCom API for anything the CSV omits	Products and catalogue
Customers and addresses	CSV, but never passwords, so a planned reset or a one time code	Customer accounts
Order and purchase history	CSV or the API, as read only records to look up	Order history
Saved cards and recurring payments	Only with the gateway's cooperation, decided before anything else	Payment tokens
Theme, apps, checkout, Lightspeed Payments	They do not move, they are rebuilt or replaced	This article
The Retail POS link	A decision: keep the till and integrate, or move the whole stack	This article

The pattern is the one every honest migration follows. Your content and your records come out. The experience Lightspeed wrapped around them does not, and the stickiest part is always payments and, here, the till. A plan that does not have a line for each of those rows is not a plan yet. Who actually holds each piece, and why that ownership matters, is the theme of who actually owns your business data.

The honest shape of a move onto a store you own

With that on the table, the move itself is methodical rather than dramatic, and it follows the companion articles above step by step.

I build the new store on Solidus, an open source ecommerce framework on Ruby on Rails under a permissive licence, which means no licence fee, no revenue share, no plan tier that unlocks your own checkout, and a store that runs on servers you control.¹² You own the result, and the bespoke code becomes yours once it is paid for. The build takes the exports and the API pulls above and maps each into the new store, rebuilds the storefront and the integrations that used to be apps, decides the question of the till, and finally gives you the checkout you could never fully shape on the hosted platform.

Then comes the overlap, which is where migrations are won or lost. For the last few weeks both stores exist. The old Lightspeed store stays live and keeps taking orders, while the new store is complete on a staging address and tested with real products and test payments. During those weeks the catalogue is frozen, so the two do not drift apart. On a quiet weekday morning in your calmest month, a final import brings across everything that changed since the last one, the domain points at the new store, you place and refund a real order for each payment method, you check the top URLs from the redirect map, and you send a friendly service message to account holders. The old store stays untouched for thirty days as your way back, and only then do you close it, after one last export. Two things must be settled before you commit to any of this: the saved cards question above, and what happens to Retail POS.

A worked example, with the hard parts first

Consider an invented business, Brighton Bath and Body (brightonbathandbody.example), a Brighton retailer selling soaps, candles and gift sets. It runs two shops on Lightspeed Retail POS and an online store on eCom (C Series) that shares the same catalogue, turns over about 900,000 pounds a year online, and carries around 1,800 products with variants. Two things it cannot do on the hosted store have finally pushed it to look: a trade area where spas and small hotels order on account against their own price list, and a build your own gift box where the customer picks a fixed number of items. Both are ordinary features on a store you own and neither fits the theme.

The first thing I would settle, before quoting a single day, is not products or design. It is two coupling questions. One, the till: do the two shops keep Lightspeed Retail POS, with the new custom store reading its catalogue and stock through the API, or does the business want to move off Lightspeed entirely over time? For Brighton Bath and Body I would keep the till for now and integrate, because replacing a working point of sale is a separate project with its own risk, and nothing says both must happen at once. Two, the saved cards: the business takes online payments through Lightspeed Payments, so the honest first step is a plain written question to Lightspeed about what can be done with stored payment details, and a parallel plan in case the answer is that customers re enter their cards once, handled with a clear, early, well written message. If that cannot be made to work cleanly, I say so, and the date waits.

Everything after that is the ordinary, careful work the companion articles describe. The 1,800 products come out by CSV, with the API filling anything the flat file leaves behind, and the import is rehearsed against a copy of the real data until it is dull. Customers arrive with their addresses and order history and set a password on their first visit. Three years of orders come across as read only history, with the full archive kept for the accountant. The trade area and the gift box, impossible on the theme, become ordinary features of the Solidus build, each written with a test. Around two thousand old URLs are mapped to permanent redirects and checked by hand. After cutover the online store is owned outright, the till still rings up sales, and the two talk to each other through an interface the business controls. Year one costs more than staying put. From year two it costs much less, and the store can finally do the things the theme was quoted an upgrade for.

When to stay, and when to call me

Stay on Lightspeed eCom if your online store is a tidy window onto a shop the till already runs, if the catalogue and checkout are conventional, and if the convenience of one company for shop and online is worth more to you than control. Stay if the only complaint is a vague sense of being boxed in, because a migration carries real risk and is not worth running for a grievance. And never move in the months before your peak season.

Leave when the checkout you cannot shape, the features the theme will not give you, or the pull of the whole ecosystem have become the thing holding the business back, and you would rather spend that money on a store you own than on a platform you cannot rewire. The honest comparison with another hosted route is set out in Solidus versus Shopify, Shopware, Magento and WooCommerce, and the full five year cost of a move is in the total cost of ownership. If a different hosted platform such as Shopify would fit you better than a custom build, part of my job in a workshop is to say so.

If you are weighing it up, bring your numbers to a free workshop, and the first two weeks of work are on me. We go through your catalogue, your till setup and your payment arrangement together, and I will tell you honestly whether a custom store pays off for you. Sometimes the answer is to stay on Lightspeed, and I will say so.

Footnotes

1. Lightspeed, Product name update FAQ, mapping of the old product names to the new ones (Ecommerce becomes Lightspeed Ecommerce (C-Series), Lightspeed Retail becomes Retail POS (R-Series), Vend becomes Retail POS (X-Series)), accessed 14 November 2026, https://www.lightspeedhq.com/au/lightspeed-product-name-update-faq/ ↩ ↩²

2. Lightspeed eCom Help Center, Getting started with eCom (C-Series), the standalone online store and its use alongside Retail POS (R-Series), accessed 14 November 2026, https://ecom-support.lightspeedhq.com/hc/en-us/articles/360032608634-Getting-started-with-eCom-C-Series ↩

3. Lightspeed Retail Help Center, Introducing Lightspeed eCom (E-Series), the flagship online store product, accessed 14 November 2026, https://retail-support.lightspeedhq.com/hc/en-us/articles/8807400827803-Introducing-Lightspeed-eCom-E-Series ↩

4. Ecwid Help Center, note that Ecwid is being referred to as Lightspeed eCom (E-Series) across the product, app stores, Help Center and login pages, accessed 14 November 2026, https://support.ecwid.com/hc/en-us/articles/5582039267996 ↩

5. TechCrunch, Lightspeed buys Ecwid for 500 million dollars and NuORDER in an ecommerce consolidation play, 7 June 2021, https://techcrunch.com/2021/06/07/lightspeed-buys-ecwid-for-500m-nuorder-for-425m-in-ongoing-e-commerce-consolidation-play/ ↩

6. Lightspeed eCom Help Center, Exporting data, export of products, customers, orders and more as CSV through Tools and Exports in the back office, with export files deleted after 30 days, accessed 14 November 2026, https://ecom-support.lightspeedhq.com/hc/en-us/articles/220320608-Exporting-data ↩ ↩² ↩³ ↩⁴ ↩⁵

7. Lightspeed eCom API documentation, introduction and resources (a REST API for single shop connections, resources including Product, Variant, Customer, Order, Category, Invoice, Shipment and Webhook, JSON or XML, EU cluster api.webshopapp.com and US cluster api.shoplightspeed.com), accessed 14 November 2026, https://developers.lightspeedhq.com/ecom/introduction/resources/ ↩ ↩² ↩³

8. Lightspeed eCom API documentation, Rate limiting, 300 requests every 5 minutes, 3000 per hour and 12000 per day per shop API key, plus 20 requests per second per API key per shop, accessed 14 November 2026, https://developers.lightspeedhq.com/ecom/introduction/rate-limiting/ ↩ ↩²

9. Lightspeed, Lightspeed Payments for the online store, the integrated payment gateway for eCom, accessed 14 November 2026, https://www.lightspeedhq.com/ecom/payments/ ↩

10. Google Search Central, Site moves with URL changes: map every URL, use permanent redirects to the final destination, and keep them for at least a year, accessed 14 November 2026, https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↩

11. Lightspeed eCom Help Center, Monthly product updates roundup, including the withdrawal request page required for EU and EEA customers from 19 June 2026, accessed 14 November 2026, https://ecom-support.lightspeedhq.com/hc/en-us/articles/40447582916251-Monthly-product-updates-roundup ↩

12. Solidus, README and licence (BSD 3 clause), GitHub, accessed 14 November 2026, https://github.com/solidusio/solidus ↩