A retail data migration
Rain POS→Shopify POS
Plan Rain POS to Shopify POS around ordinary products, customer contacts and opening stock first. Serial records, repairs, rentals and balances need their own feasibility decisions.
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.
Prepare the Rain POS source
Export products through Inventory > Products > Bulk Actions > Export. Use Customers > Customers > Options > Bulk Customer Actions > Download Customers for the customer CSV, rather than exporting a marketing list. Obtain store quantities through Inventory > Bulk or the Inventory report, recording location/status filters and the snapshot time. Separate available stock from reservations.
Keep an untouched extract, included-store list and source-to-destination identity crosswalk. Each retailer’s catalog, barcodes, orders and customer information are proprietary and unique; the field map is agreed with that retailer.
Load Shopify POS in separate steps
Build Shopify product CSVs first, then customer CSVs, then a location inventory file tied to the resulting variant identities. Inspect existing products and customer overwrite settings before loading. Keep Rain IDs in the reconciliation crosswalk; they are not Shopify IDs. Customer CSV does not recreate orders, passwords or historical spending.
Use Rain’s customer record download as the contact source. Inspect its actual columns before mapping addresses, consent and duplicate candidates into the destination customer template. The source customer ID belongs in the crosswalk unless the destination explicitly supports it; an email list or an account-balance report is not a substitute for contact records.
Illustrative mapping for this direction
These fictional rows describe acceptance checks, not an executed migration or a verbatim vendor template. Download the actual current templates for the engagement.
| Dataset | Source example | Receiving decision |
|---|---|---|
| Sellable item | Rain product ID, SKU 0017, barcode 00123401 | Match or create the intended Shopify variant; preserve barcode text and original ID in crosswalk |
| Customer | Rain customer ID and supported contact fields | Map into Shopify customer CSV; resolve shared email/phone candidates before overwrite |
| Store stock | Item: 3 on hand at A, 2 at B, reservations listed separately | Map to Shopify locations; review destination inventory export and approved stock state before update |
Where Shopify already hosts the retailer’s online catalog, match existing variants instead of creating a second listing. Reconcile Rain available/reserved stock to the agreed Shopify inventory state; the numbers are not interchangeable.
Keep complex records out of an ordinary stock file
Do not flatten serial numbers, repair/work orders, rental contracts, consignment commitments or reserved items into an ordinary quantity without an agreed outcome. Rain’s inventory reports document serial visibility/printing; that alone does not establish a full serial export and reload. The sold-serial SVP extract is not a complete in-stock serial register.
Agree a supported technical method, a reference archive or an explicit exclusion for each requested complex dataset. Customer contacts do not recreate gift-card liabilities, store credit, rewards, receipts or open orders. If any of those are required, establish their identity links and financial treatment separately before accepting that scope.
Acceptance before launch
Check every included store, barcode and sellable combination against the crosswalk. Reconcile created, matched, updated and rejected records; compare stock by store and record trading changes after the snapshot. Check a duplicate-contact candidate and a corrected-file retry for unintended duplicates or extra stock. The project lead and retailer agree exceptions, reversal steps and launch signoff. These project checks do not imply prior delivery evidence.
Vendor documentation and limits
- Rain bulk product and inventory operations distinguishes new products, updates, adding quantities and editing quantities, with separate location identifiers.
- Rain customer records and bulk templates establishes customer CSV download/upload independently of marketing lists.
- Rain spreadsheet rules explains header preservation, customer address format and blank-cell behavior.
- Rain inventory reports documents filtered quantity exports and the distinction between on-hand and reserved stock.
- Shopify product/item workflow
- Shopify customer workflow
- Shopify location inventory workflow
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.