Should we run Lightspeed and Shopify POS side by side while building out the new ecommerce store, or migrate everything in one cutover?
A parallel run works for catalog and inventory and fails for the register. Lightspeed's own Shopify integration requires Retail POS to be the system of record and warns that updates made in Shopify may be overwritten or cause syncing issues (Lightspeed, September 2026). Two live registers against one stock pool produce two counts.
The vendor has already answered half of this
Lightspeed publishes a first-party Shopify integration for X-Series, and its documentation is unusually direct about the hierarchy: "Retail POS should be treated as the system of record," and "updates made in Shopify may be overwritten or cause syncing issues" (per Lightspeed X-Series support, September 2026). It shares "product, inventory, customer, and sales information between both systems," and by default "your sales in Shopify are automatically recorded in Retail POS."
Read that as what it is. During a parallel period on this integration, Shopify is a downstream sales channel of Lightspeed, not a peer. That is a perfectly good arrangement for building an online store while the registers stay put. It is not a migration, and it does not get you closer to one.
Two documented limits matter before you lean on it:
- "You won't be able to sell products exclusively on Shopify" (per Lightspeed, September 2026). Online-only SKUs need a different plan.
- "SKUs and handles must match between systems beforehand." Shopify product images do not sync back to Retail POS.
The three shapes of parallel, graded
| Shape | What runs where | Verdict |
|---|---|---|
| Catalog and inventory parallel | Lightspeed is system of record; Shopify is a sales channel behind the integration; all registers stay on Lightspeed | Do this. It is what the integration is built for, and it lets the online store be real before the registers move. |
| Split-store parallel | Store A on Shopify POS, stores B to E on Lightspeed, inventory not pooled between them | Tolerable and time-boxed. Works only if you accept that the two estates have separate stock and do not promise customers a transfer between them. |
| Same-store dual register | Both systems selling the same stock in the same room | Never. There is no reconciliation design that survives it. |
Why the third shape fails specifically
An inventory decrement is not a message, it is a claim on a physical object. Two systems both authoritative over one shelf will each believe they sold the last unit. The failure is not that the numbers drift; it is that neither number is wrong from inside its own system, so nobody can adjudicate. You end up doing a full physical count to resolve it, which is exactly the cost the parallel run was supposed to avoid.
How long a parallel period is tolerable
The honest answer is bounded by month-end, not by weeks. Every close during a split estate is a close where someone reconciles two sets of books by hand. One close is a manageable inconvenience. Three is a hiring decision.
Our working rule: a catalog-and-inventory parallel period can run as long as the ecommerce build needs, because there is one system of record and the integration enforces it. A split-store parallel period should cross at most one month-end close, and the date it ends should be in the plan before it starts.
When a single cutover is genuinely right
- Single location. There is no split-store option and no reason to invent one.
- Two to three locations with one stockroom. The reconciliation cost of a split estate exceeds the risk of one weekend.
- When the Lightspeed contract ends on a hard date. Design to the date rather than pretending it is soft.
When NOT to cut over all at once
- More than about five doors. One store's worth of unknown unknowns is a learning cost. Fourteen stores' worth on the same night is an outage.
- When tender mix differs by store. The store that takes account payments and layby will fail differently from the one that takes cards.
- When the pilot store has not closed a month yet. The first close is where the register problems become finance problems.
The Deploi point of view
Our own position, from building on Shopify. Separate from the facts above.
- Our take: Parallel the data, never the register. The useful parallel period is the one where Lightspeed stays the system of record and Shopify is a channel, which is precisely the arrangement Lightspeed's own integration enforces. The moment a second register starts writing to the same stock, you are not de-risking, you are manufacturing a reconciliation project.
- What we refuse to scope: A same-store dual-register period. It is chosen because it feels reversible, and it is the least reversible option on the list, because after a week nobody can say which system holds the true count and the only route back is a physical inventory. We will scope a catalog-and-inventory parallel or a time-boxed split-store parallel, and we will say no to the third.
- Where we disagree: The standard migration advice is "run both for a while to be safe." That advice is imported from systems where the data is a record of something that already happened. Inventory is not a record. It is a reservation against a physical object, and reservations do not tolerate two owners.
- What this page adds: that Lightspeed publishes a first-party Shopify integration which explicitly makes Retail POS the system of record, blocks Shopify-exclusive products, and therefore defines what a legitimate parallel period looks like before you design one.
Reviewed by Martin Dejnicki, Director of SEO & AI Search. Facts verified 2026-09-14.