How do I migrate from Lightspeed Retail (POS) to Shopify without disrupting in-store sales during the transition?

Start by naming the series, because everything downstream depends on it

Shopify's own migration documentation splits the export instructions three ways, and it says so plainly: "The product data export procedure depends on which Lightspeed series you use" (per Shopify Help Center, September 2026). X-Series exports from Catalog > Products. R-Series exports from Inventory > Item Search. E-Series, which is the online store and not a register, exports from a different screen again.

This is not pedantry. The two retail products have materially different data surfaces:

The 1,000-row ceilings are the part most plans miss. A five-store retailer with 40,000 customers and three years of sales is not running two exports. It is running forty customer exports and several hundred sales exports, each one filtered by date or outlet, each one a chance to double-count or skip a window. Budget that as a task with a named owner, not as a morning.

What Shopify's own tool actually moves

The Store Migration app is "a free, Shopify-built app to help you quickly import product and customer data from other platforms into a new Shopify store," and it lists "Lightspeed R/X (Vend)" among its supported sources (per Shopify, July 2026). It transfers product titles, descriptions, variants, pricing, inventory levels, images, SKUs, barcodes and customer names, emails, phone numbers and addresses.

It does not import orders, order history, collections, navigation, SEO metadata, blog posts, pages or reviews (per Shopify, July 2026). Two documented limits bite in retail specifically:

• "Products with more than 3 options won't have their options imported" (per Shopify Help Center, September 2026). Apparel with size, colour, width and fit is a four-option product.
• "Prices by location aren't supported. Prices are automatically set to the product's highest price" (per Shopify Help Center, September 2026). A retailer running outlet pricing at one door and full price at another will silently land on full price everywhere.

Neither of those is a bug. Both are a reason the catalog has to move first and be checked by a merchandiser before a register ever points at it.

The sequence we insist on

1. Locations and inventory model before anything else. Shopify's location limit is 10 on Basic, Grow and Advanced, and 200 on Plus, and "locations that you deactivate don't count toward your location limit" (per Shopify Help Center, September 2026). A 14-door retailer on Advanced has a plan problem, not a migration problem, and finding that in week six is expensive.
2. Catalog, with options and location pricing resolved by hand. Run the import into a store nobody is selling from. Fix the four-option products and the per-location prices before they become register behaviour.
3. Inventory counts, per location. Shopify's inventory CSV is a separate file from the product CSV and cannot create products. For multiple locations, "for each variant, include a row for each location where you want to update inventory," and the file cap is 15 MB (per Shopify Help Center, September 2026).
4. Customers, accepting the losses. See the follow-up on purchase history below.
5. Balances: gift cards, then store credit, then loyalty. These are liabilities on someone's balance sheet and they are the objects Shopify imports least well. They get their own pages below because they each fail differently.
6. Tax registrations and location-linked tax settings. Rebuilt, not migrated.
7. Hardware staged and tested in one store, out of hours.
8. Registers last, one store at a time. Not all stores on one night.

Why registers go last, and what "without disrupting sales" actually means

Nobody is asking how to avoid a two-minute pause at the till. They are asking how to avoid the week where the count in the back room, the count on the website and the count on the register disagree and nobody can say which is right.

That risk is created by the overlap period, not by the cutover moment. The cutover moment is the safest part of the project, because everyone is watching. The dangerous window is the four weeks before it, when catalog is being loaded into Shopify while Lightspeed is still selling. This is why our POS-ecom coherence decision record scores WAIT and why the Lightspeed-versus-Shopify-POS record scores BUILD: the register is a commodity, and the single inventory record is not.

The rollback plan, which most plans skip

A Shopify POS cutover is not easily reversible, because the transactions written after cutover exist only in Shopify. So the rollback is not "go back to Lightspeed." It is:

• Keep the Lightspeed subscription live and read-only through one full month-end close. Cancelling on cutover day saves one month of subscription and costs you the only copy of the data your accountant will ask for in week three.
• Take a final full export of every object on cutover night, not the week before, and store it somewhere that is not the POS vendor.
• Define the abort condition in advance and in numbers. Ours: if register-level cash variance exceeds the pre-migration baseline for three consecutive trading days at the pilot store, the rollout stops and the remaining stores stay on Lightspeed.
• Pilot on one store, not the smallest one. The smallest store has the fewest transactions and therefore the fewest ways to fail. Pilot on a busy store with a complicated tender mix.

When NOT to start this migration

• Inside 10 weeks of your peak. A retail cutover in October is a decision to spend Q4 debugging.
• While the catalog is mid-restructure. Migrate the catalog you have. Restructure after.
• When nobody owns the gift card liability number. If finance cannot state the outstanding balance today, migration will not produce it.
• When you are on R-Series and the business needs order history in Shopify. That is a third-party import project with its own budget, not a step in this one.