A retail data migration

Lightspeed Retail R Series→Clover

A move from Lightspeed Retail R Series to Clover needs an explicit map from a matrix with several sellable sizes, an existing item and separate store quantities to the receiving records.

Plan this migration Data migration: $2,999. Scope confirmed before booking.

The records we review.

Products & variants
Style, size, and color relationships
SKUs & barcodes
Identifiers used across your stores
Customers
Supported fields and matching decisions
Opening inventory
Quantities mapped to each location
Existing destination records
Products and customers already in your next system

The decisions
we make first.

  1. Source access

    Review representative exports and the available extraction method.

  2. History & balances

    Assess sales history, gift cards, loyalty, and credits separately.

  3. Test & acceptance

    Agree the records and checks before the final transfer.

Assess the Lightspeed Retail R Series source

R Series inventory and item/matrix identity, with separate customer and liability data.

R Series item imports can add stock to existing quantities. A repeated import must be reconciled rather than treated as a replacement snapshot.

Keep an untouched original and a record of account, edition, location coverage and extraction time. The customer must provide full authorized access and be able to access their own data. Do not infer missing fields or access from a vendor family name.

Plan the Clover destination

Merchant inventory/customer workflows with approved write permissions; confirm item variants, modifiers and stock separately.

A modifier and a stock-bearing variation are different relationships. Third-party rewards and payment configuration are separate from merchant catalog records.

Inspect existing receiving records before choosing create, match or update behavior. An exported internal ID should remain in a reconciliation crosswalk unless the receiving specification explicitly accepts it.

Directional data decisions

DatasetLightspeed Retail R Series evidence to preserveClover decision to confirm
Products and variantsComplete grouping, source IDs, sellable combinations and item statusEquivalent parent/variant structure and supported receiving fields
Identifiers and pricesSKUs, full barcode text, unit and price contextMatching rule, permitted identifier representation and accepted price behavior
Customer contactsSource identity and duplicate candidates, separately from liabilitiesReceiving method, existing-profile rules and rejected-row report
Location stockStore/warehouse map, quantity type, unit and snapshot timeCorrect receiving location and set-versus-add operation
History and commitmentsRequired receipts, gift cards, credit, loyalty and open orders listed individuallyNative receiving method, approved transformation, archive or exclusion for each

A representative test for this direction

Use a matrix with several sellable sizes, an existing item and separate store quantities. In the receiving Clover setup, also inspect an item with variants and modifiers plus a customer whose loyalty is held in an app. Use these illustrative examples to plan your project’s sample and agree expected results before a production import.

Write expected identities, grouping and quantities before the sample load. Compare returned records and rejected rows, approve exceptions and capture changes made after the stock snapshot. Test any proposed history or balance operations separately so an item import cannot silently create a second liability or stock movement.

Official references

What the vendor documentation establishes

R Series item import/export: New records leave System ID blank; existing records retain it. Store Quantity on Hand adds inventory rather than replacing it. Matrices and serials have separate rules.

R Series customer import: Customer templates go through Retail Imports. Custom fields are excluded; confirm actual supported characters and columns before preparing data.

R Series customer data: Customer exports and identity management are distinct from item exports.

Additional vendor boundaries

Clover data model: Items, variations/modifiers, stock and customer records have separate relationships; an approved field map and operation for the complete direction is still required.

Clover app permissions: Application permissions govern accessible records; a general merchant account does not demonstrate the required dataset access.

Planning this direction with your project lead

Lightspeed Retail R Series source records

Export the intended Item Search records and customer data separately. Preserve source System IDs, matrix dimensions and store quantities without reusing those IDs as identifiers in another application.

Clover receiving records

Create or match merchant-scoped items and their related groups/options, then customers and stock. The item-stock PUT uses quantity for the current count; deprecated stockCount is not the proposed field. Regional permissions and the installed account are engagement checks, not evidence of a universal connector.

Resolve the transformation before loading

Distinguish a sellable variant with its own stock from a modifier used on an order. Carry prices, barcode text and tax context through the identity map, and reconcile stock per merchant/location. A successful product creation does not demonstrate that customer balances or historical orders moved.

Acceptance is specific to your retailer

Use the representative case above with the retailer’s actual catalog, customer matches and store quantities. Record the intended result, extraction cutoff, rejects and recovery steps before loading. History, gift cards, credit, loyalty and open orders each need an agreed native method, archive or exclusion. Required account access, sample approval and launch milestones are engagement checks—not a claim of past Sqquid delivery or universal support.

Official method references

Migration scope and responsibilities

The standard migration fee is $2,999 USD for the confirmed scope.

Tailored to your retailer data

Every migration is unique. Your catalog, barcodes, orders and customer information are unique and proprietary to your business. We work closely with you to tailor the migration for the best possible outcome, agree the included records and define acceptance checks for your stores.

Routes offered subject to feasibility

We offer the currently listed migration routes subject to retailer-specific feasibility and an agreed scope. This includes POS migrations into Runit.

A project lead for your migration

Sqquid assigns a project lead to each migration. The lead is responsible for migration correctness and oversight of the entire migration dataset, including planning and managing data reversal when needed. The reversal method, dependencies and acceptance checks are agreed for your retailer’s systems and data.

Retailer-provided ERP and finance approvers

For ERP-related work, the retailer must provide an ERP approver and a finance approver. They approve the receiving requirements, included retail data, financial treatment and acceptance results within their responsibilities. Sqquid’s project lead coordinates the migration with them; full ERP implementation remains separate work.

Access to both systems

You must provide Sqquid full authorized access to both systems and be able to access your own data. Arrange access through an agreed secure process. Do not put passwords, API tokens, payment information or customer export files into the general enquiry form.

Source data quality

Sqquid is not responsible for migration errors caused by poor data supplied by the customer. Source issues, proposed corrections and exclusions need to be recorded before the transfer is accepted.

Earlier work and guarantee limits

Sqquid does not guarantee a migration that started before Sqquid was hired. Any guarantee is limited to the data migration work performed by Sqquid and expires on the launch date. Record the agreed launch milestone in the written scope; do not assume post-launch guarantee coverage.

Vendor charges and separate work

Vendor charges are passed to the customer in addition to the confirmed migration fee. POS implementation, hardware, payment setup, staff training and ongoing integrations have separate responsibilities and scope. A Sqquid software subscription is not required for the migration service.

Corrections before launch

We correct errors in our own migration work at no additional charge before launch.

Refunds for errors caused by Sqquid

If a migration error occurs and Sqquid is at fault, we will refund the fees the retailer paid us.

Your systems. Your next chapter.

From the first export to the final review.

Tell us where your data is today, and where you’d like to go. We’ll help you understand the next step.

Check my migration Retail data migration for $2,999. Scope confirmed before booking.