Overview

Lightspeed Overview

Next-Cart treats Lightspeed as one platform family with five supported Source editions. The edition determines the connection method, required values, and preparation procedure for that run, so identify the exact edition before creating credentials or exporting files.

A purchased Lightspeed -> Target Platform migration remains one purchased platform path. Changing Edition changes the Source connection setup; it does not create a different purchased migration path.

In the Documentation sidebar, expanding Lightspeed displays the four API-based editions: C-Series, E-Series, R-Series, and X-Series. Lightspeed Retail (S-Series) is still part of the supported Lightspeed family and is covered in this overview, but its guide remains under Source Data Export Guides because S-Series uses File Upload rather than an API connection. Use the S-Series link in the edition table below to open its export procedure directly.

Use the exact Lightspeed edition

Do not reuse credentials, required values, or setup steps from another edition. Lightspeed Retail (S-Series) uses File Upload; C-Series, E-Series, R-Series, and X-Series use API-based Source setups.

Edition is not version

Choose the Lightspeed edition that owns the Source data. A software version or release number does not become another migration path unless Next-Cart lists it as a separate supported platform.

Choose Your Lightspeed Edition

Lightspeed edition	Source connection method	Connect Stores values	Continue with
Lightspeed eCom (C-Series)	API	Store URL API Key API Secret	C-Series API Connection
Lightspeed eCom (E-Series)	API	Store URL Personal collection URL	E-Series API Connection
Lightspeed Retail (R-Series)	API	API Key	R-Series API Connection
Lightspeed Retail (S-Series)	File Upload	Store URL	S-Series Source Data Export
Lightspeed Retail (X-Series)	API	Store URL Personal Token	X-Series API Connection

What Changes by Edition

• C-Series uses a Lightspeed eCom API Key and API Secret together with the Store URL.
• E-Series follows the supported Ecwid API workflow and uses the Store URL plus a Personal collection URL.
• R-Series uses application authorization that returns an API Key. Its Source setup does not expose a Store URL field.
• S-Series uses File Upload. The standard Source workflow accepts the Product file products.csv, while the Source setup itself still includes Store URL.
• X-Series uses the Store URL and a Personal Token when that credential option is available for the Retail POS account. Do not substitute a private-app application token for the Personal Token field.

Use the edition-specific guide for the credential or export procedure. Use this overview to select the right branch and understand the consequences that apply across the Lightspeed family.

Store Identity When Changing Editions

Store identity follows the actual Store URL fields used by the active connection setup, not the edition name alone.

• For C-Series, E-Series, S-Series, and X-Series, the Source setup includes Store URL. After the connection succeeds, Connect Stores is saved, and the migration advances to Configuration, that Source Store URL becomes locked for the paid migration.
• R-Series has no Source Store URL field. When R-Series is used with a Target setup that includes Store URL, the Target Store URL can become the lock instead.
• Test Connection by itself does not create a Store URL lock.
• Changing Edition later does not clear a lock that already exists. A later run can establish the other side as well, so one Lightspeed migration can accumulate both a Source and a Target lock across different runs.
• If a URL-bearing Lightspeed edition is used after a Source Store URL has already been locked, the submitted Source identity must remain consistent with that registered store.
• If the active Source setup and Target setup both have no Store URL field, that run creates no new URL lock. This can occur with R-Series -> Square. Any lock established by an earlier run still remains in force.

How cumulative locking can develop

Example sequence	Store identity result
C-Series first, then R-Series with a URL-bearing Target	C-Series establishes the Source lock; the later R-Series run can establish the Target lock.
R-Series first with a URL-bearing Target, then C-Series	R-Series can establish the Target lock; the later C-Series run can establish the Source lock.
Later run after both sides are locked	Any Store URL fields used by that setup must remain consistent with the identities already registered for the migration.

This is the Lightspeed-specific operating model. For the complete locking rule, including staging-to-production behavior, URL-equivalence rules, ports, paths, and non-Lightspeed exceptions, see Store URL Locking and Store Identity.

Before You Switch Editions on a Later Run

Before selecting another Lightspeed edition for an existing paid migration:

1. Confirm that the new edition actually owns the Source data you intend to migrate.
2. Check whether the edition uses a Source Store URL and whether a Source or Target identity has already been locked.
3. Prepare only the credentials or files required by that edition.
4. Recheck Configuration after reconnecting so the next migration activity uses the intended Source setup and scope.

Changing the edition is a connection decision. It does not reset migration history, existing Store Identity locks, or the purchased Source-to-Target platform path.

Continue With the Selected Guide

Open the guide for the exact edition selected in the migration. C-Series, E-Series, R-Series, and X-Series are nested under the Lightspeed sidebar group. For S-Series, use Lightspeed Retail (S-Series) Source Data Export, then continue through its File Upload handoff. Complete the selected edition’s credential or export procedure before continuing to migration configuration.

Learn the Concepts Behind the Setup

Documentation explains how to connect and operate the migration. For broader decision context:

• Platform Strategy Hubs explains how platform architecture, data representation, constraints, preparation, and validation affect migration decisions beyond the connection method.
• How the Migration Process Works explains how connection, configuration, representative evidence, execution, and validation fit together as one migration process.