Store URL Locking and Store Identity

Store URL Locking and Store Identity

A paid Migration can lock the Source Store URL, the Target Store URL, or both when the required Source and Target setups in the Connect Stores step are successfully connected and the customer proceeds to the Configuration step. The applicable lock becomes official at that Phase 1 to Phase 2 transition and remains in force across later runs, configuration changes, upgrades, and extensions.

The locking rule

Active connection setup	Lock created when the connected setup proceeds to Configuration
The Source setup includes Store URL	The Source Store URL is locked. The Target Store URL remains changeable when the Target setup uses a URL field and no separate Target lock has been established.
The Source setup has no Store URL, and the Target setup includes Store URL	The Target Store URL is locked.
Neither active setup includes Store URL	No URL lock is created for either side.

Entering a URL or using Test Connection does not by itself create the project URL lock. Test Connection is optional. After the required Source and Target setups are successfully connected, selecting Continue to Configuration commits the applicable Store URL identity and the lock becomes official when the Configuration step opens.

Confirm the store before continuing to Configuration

The applicable permanent Store URL lock is committed when a successfully connected Connect Stores setup proceeds to the Configuration step. Confirm the intended Source and Target Stores before selecting Continue to Configuration.

What can change after a URL locks

Situation	Rule
Source URL is locked	Later runs that use a Source URL must submit the locked Source Store URL identity. Equivalent URL formatting is normalized as described below, but a different Source Store is not allowed within that purchased Migration.
Source URL is locked, but Target URL is not	The Target can be changed to another valid store on the purchased Target Platform when the active Target setup uses a URL field. Reconnect and review Configuration before the next migration activity.
Target URL is locked	Later runs must submit the locked Target Store URL identity. Equivalent URL formatting is normalized as described below, but a different Target Store requires a separate purchased Migration.
Connection parameters must change	Wait until the migration is no longer queued, running, processing, or stopping.
A later migration action is started	Existing URL locks remain. A new configuration, another migration activity, Upgrade, Extend, or Entity Points Plan change does not reset them.

Continue the previous migration in Additional Options does not resume an execution session and does not change or reset a Store URL lock. It carries the most recent migration state into the current one so records not transferred in that previous state can form the new-data delta while supported relationships use the carried context. Execution recovery follows the Run Mode, Stop Migration / Resume Migration, and return-flow rules described in Migration Actions and Additional Options.

Staging and production stores

A staging-to-production change is possible only while the relevant Target Store identity is still allowed to change under the locking rules.

Project state	Can the Target Store change?
Connection values are being prepared or optionally tested, but Continue to Configuration has not yet committed the connected setup	Yes. The applicable URL is not locked until the successfully connected setup proceeds to the Configuration step.
The Source URL is locked and the Target URL is still unlocked	Yes, to another valid store on the purchased Target Platform. Reconnect the intended production store and review Configuration before the next activity.
The Target URL is locked	No. A different Target Store requires a separate purchased migration.
The submitted Target URL differs only by scheme, default port, hostname capitalization, query, fragment, or trailing slash	It can still represent the same locked store identity. Use the comparison rules below before treating it as a different store.

Do not use a staging store for a paid Migration on the assumption that it can always be replaced later. Confirm which side can lock for the selected Source and Target setup before the successfully connected setup proceeds to the Configuration step.

Source setups without a Source Store URL

Most Source setups identify the source store with Store URL. These setups are exceptions because Connect Stores does not request a Source Store URL:

• Clover
• CSV
• eBay
• Lightspeed Retail (R-Series)
• Square
• XLS
• XML

When the Target provides a Store URL

If one of these Source setups is used with a Target that provides Store URL, the Target Store URL becomes the project lock when the required connected setup proceeds from the Connect Stores step to the Configuration step.

For example, CSV -> Shopify locks the Shopify Target URL when the connected CSV-to-Shopify setup proceeds to the Configuration step, because CSV has no Source URL. Later migration activity can use another valid Product CSV file, but it cannot redirect that purchased migration to another Shopify store after the Target URL is locked.

When the Target also has no Store URL

Square can create no new URL lock

Square is a Target setup without Store URL. If the active Source setup also has no URL, that run creates no new URL lock. Any lock already established for the paid migration remains in force.

File Upload does not determine URL locking

Do not infer URL behavior from the connection method alone. Lightspeed Retail (S-Series), Squarespace, and Wix File Upload setups still include a Source Store URL.

Lightspeed cumulative locking

A purchased Lightspeed -> Target Platform Migration can use supported Lightspeed editions whose connection fields differ. The Edition selection changes the Source connection setup for a run, not the purchased platform path. Successive connected setups can therefore establish cumulative Source and Target URL locks when the customer proceeds to the Configuration step with edition/setup combinations that expose different URL fields.

Source lock first

Run	Connection behavior	Lock state after the run
1. Lightspeed eCom (C-Series)	C-Series includes Store URL. When the connected C-Series setup proceeds to the Configuration step, the Source identity is locked.	Source locked. Target remains unlocked.
2. Lightspeed Retail (R-Series)	R-Series has no Source Store URL. If the Target provides Store URL, proceeding to the Configuration step with the connected R-Series setup establishes the Target identity.	Source locked + Target locked.
Later URL-based edition	The Source and Target fields are checked against the registered identities.	Both locked identities must match.

Target lock first

The sequence can begin with Lightspeed Retail (R-Series) instead. When the Target provides Store URL, proceeding to the Configuration step with a connected R-Series setup can establish the Target lock first. A later connected URL-based Lightspeed setup can add the Source lock when that setup proceeds to the Configuration step.

Changing Edition never clears a lock

Once a Source or Target URL lock is established at the Connect Stores to Configuration transition, selecting another supported Lightspeed edition does not reset it. A later setup must satisfy every registered identity that applies to the fields exposed by that edition.

How URL identity is compared

Next-Cart compares hostname + non-default port + path rather than the complete URL string. Hostname comparison is case-insensitive; path comparison is case-sensitive.

For a locked URL of https://example.com/shop/:

Submitted URL	Result
http://example.com/shop	Matches
https://EXAMPLE.com/shop/	Matches
https://example.com/shop/?x=1#top	Matches
https://example.com:443/shop	Matches
https://example.com:8443/shop	Does not match: non-default port differs
https://www.example.com/shop	Does not match: hostname differs
https://example.com/Shop	Does not match: path case differs
https://example.com/other	Does not match: path differs

Scheme, query strings, fragments, default ports, hostname capitalization, and a trailing slash do not create a different store identity by themselves. A different hostname, a different non-default port, or a different normalized path identifies a different store.

Repeated migration activity does not unlock store identity

A purchased Migration can be run as many times as needed while the Migration remains active. Every run must remain within the fixed Migration Path, satisfy every established Store URL lock, stay within supported scope and service validity, and have enough available Entity Points Plan capacity for newly counted records.

Repeated activity does not allow the project to move between unrelated stores. A test-to-production Target change is possible only while the Target identity is still unlocked. Once the Target URL is locked, moving the same purchased Migration to a different production store is not permitted; a separate purchased Migration is required for that different Target Store.

Migration issues can be escalated through AI Help, a Support Agent conversation, or a Support Ticket. Technician involvement, execution responsibility, and any additional work depend on the active Migration Service and the agreed scope rather than a blanket promise that every repeated migration or store change is included at no additional fee.

Related tasks

• Connection Setup Requirements to confirm the fields used by the selected platform, method, or Lightspeed edition.
• Connect Your Source and Target Platforms to check Source and Target connection requirements.
• Test Platform Connections to verify access without changing the URL-lock state.
• Troubleshoot Connection Setup when a locked store identity or connection value prevents the setup from completing.