A retail data migration
Lightspeed Retail R Series→Epos Now
Plan this direction around a matrix with multiple sizes, an existing item and location-specific quantities, then verify the receiving Epos Now 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.
Source access
Review representative exports and the available extraction method.
History & balances
Assess sales history, gift cards, loyalty, and credits separately.
Test & acceptance
Agree the records and checks before the final transfer.
Review the Lightspeed Retail R Series source
R Series item/matrix identity and store quantities, with a separate customer extract and explicit liability requirements.
An item import can add quantities to existing stock. Confirm the specific operation before repeating a partial load.
Record the original identifiers, account/edition, included stores, extraction time and any source issues. Preserve an untouched original and verify that files or responses include the full intended record set.
Establish the Epos Now receiving method
Account-authorized Epos Now product/customer/stock methods for the installed environment, with required related records.
A modifier choice is not automatically a stock-bearing variation. Public API resource categories do not prove every required field or regional account permission is available.
Agree create, match and update behavior before preparing a full file. Keep a source-to-destination identity crosswalk rather than placing unrelated internal IDs into receiving fields.
Directional data plan
| Dataset | Source evidence | Receiving decision |
|---|---|---|
| Products and options | Full parents, sellable combinations, original IDs and active/archive status | Equivalent grouping, approved fields and existing-record behavior |
| Identifiers and prices | Full barcode/SKU text, units and price context | Accepted identifiers, selling units and price rules |
| Customers | Source IDs, supported contacts and duplicate candidates | Match rules, receiving method and created/updated/rejected records |
| Location stock | Store/warehouse mapping, quantity state, unit and snapshot | Receiving location and verified set/add behavior |
| History and obligations | Required receipts, cards, credit, rewards and open orders listed separately | Approved native method, transformation, archive or exclusion |
Proposed representative test
Use a matrix with multiple sizes, an existing item and location-specific quantities. In Epos Now, also check a product with modifiers and variations, an existing customer and stock in two locations. These are illustrative planning cases. Write expected identities, grouping and quantities before the sample and compare returned records with the approved map.
Investigate rejected rows, changed identities and stock differences. If history or balances are included, test their side effects separately. Record trading changes after the inventory snapshot and approve exceptions before the launch milestone.
Confirm before booking
- Confirm matrix reconstruction, customer receiving rules and whether the chosen inventory operation adds or sets quantities.
- Confirm API version, authorization, field coverage, pagination, modifier/variant relationships and the actual stock write/read operation.
- Record exact editions, full authorized access, source data coverage, existing destination records and the approved included field map.
- Agree separate outcomes for history, gift cards, credit, loyalty and open commitments; complete a controlled representative test and retailer acceptance before launch.
Check my migration with the actual editions, stores and required records. The final scope follows the access and method review; no pre-existing implementation or universal data support is implied.
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.
Epos Now V4 API: Product, Customer and ProductStock resources exist. ProductStock/Update takes ChangeInStock, an adjustment rather than an absolute opening balance.
Epos Now API access: API access concerns cloud data, not direct till control; actual authorized entitlement and resource coverage need account checks.
Documented workflow for this direction
Prepare the Lightspeed Retail R Series source
Export the intended Item Search records and obtain the separate customer export. Preserve System IDs as source references, matrix dimensions and each store quantity; inspect filters and reconcile counts.
Load the Epos Now records
Map Product and Customer records before stock. The documented ProductStock/Update request uses ChangeInStock: calculate the agreed change against the receiving baseline rather than submitting an absolute balance as a change. Confirm cloud API entitlement and inspect errors before retrying.
Validate this retailer’s relationships
Map R Series matrix children to Epos Now sellable products and retain the source identity crosswalk. Preserve barcodes as text, choose the treatment of modifiers and verify a repeated stock request cannot add the same opening inventory twice.
Obtain authorized samples securely, agree source corrections and exclusions, and compare destination identities, stock and rejects with expected results before launch. These are documented planning methods, not evidence of prior Sqquid delivery. History, orders and liabilities need a separate approved method or archive.
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.
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.
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.