Migrating from Square to RetailPOS
Last reviewed 2026-05-26 · by the RetailPOS team
Most owners who switch from Square do it at one of three trigger points: they open their second shop and discover “multi-location reporting” is a $40/month upgrade per location; they hit the 90-day report retention wall and can't pull the data their accountant asks for; or their food cost is mysteriously high and Square's lack of recipe-driven inventory means they can't find the leak.
This guide walks through the migration honestly. Some things carry over cleanly (catalogue, customer list, your Stripe account, your hardware). Some don't (sales history, Square Loyalty point balances, integrations you set up via Square's marketplace). The migration is straightforward but it pays to plan for the cutover weekend rather than fight a half-done switch on a busy Saturday.
What carries over cleanly
Catalogue (items + variants + prices)— Square's Items export gives you a CSV with one row per variant. RetailPOS imports the same shape via POST /v1/imports/items. Modifier groups + options come across; modifier recipes (if you set them up on Square via a third-party app) don't — you set those up fresh.
Customer list — Square Customers export gives you name + email + phone + spend total. RetailPOS imports via POST /v1/imports/customers. Tags + notes come across. Per-customer loyalty point balances do NOT (different ledger; see below).
Stripe account— your Stripe account is yours. Square processes cards through their own merchant of record; you weren't on Stripe before. To move processing to Stripe, sign up for a Stripe Reader M2 (free, $59 list ships with the account); the till routes card sales through Stripe instead of Square.
Hardware— iPads, Star printers, Honeywell scanners, cash drawers all work as-is. The only thing you can't reuse is the Square card reader itself (it's locked to Square's SDK).
What doesn't migrate
Sales history— your past sales stay on Square. They're yours to keep there + export for accounting; RetailPOS doesn't backfill historical sales into its own ledger because the data would be ambiguous (different SKUs, different tax IDs, different timestamps). Day-one on RetailPOS is a clean slate.
Loyalty point balances— Square Loyalty's ledger doesn't export in a form RetailPOS can ingest. The migration path: do a final “Cash out your points” promotion on Square in the last week, then start fresh on RetailPOS with the same earn rate (typically 1 point per AED/USD).
Square-marketplace integrations— if you connected Square to QuickBooks, Mailchimp, etc. via their App Marketplace, those connections don't come across. RetailPOS has its own connector layer (see /integrations); reconnect to your accounting tool on the new system.
Recipes (if any)— if you set up recipe-style nested items on Square via a third-party app, those don't carry over. RetailPOS' recipe BOM is a different shape (ingredient-level depletion); you set it up fresh, which is usually less work than migrating the half-baked version.
Step-by-step cutover (do this on a Sunday night)
Tuesday before: Sign up for RetailPOS, pick your vertical kit, sign up for Stripe (if not already). Test the till with sample sales in your Stripe test account.
Thursday: Export your Square items + customers as CSV. Import them on RetailPOS via the admin import flow. Verify counts match.
Friday: Configure modifier groups, taxes, tip presets, end-of-day close rules. Set up your stylist + commission rates (if salon), recipes (if coffee / bakery / restaurant), or per-piece tracking (if jewellery / electronics).
Saturday: Run a parallel test — ring 5-10 sales on RetailPOS alongside your Square till to catch anything off. Test refund, void, end-of-shift cash count.
Sunday close → Monday open: Final Square close at Sunday EOD. Last full data export from Square (sales history, receipts) — save these for your accountant. Monday morning: start ringing on RetailPOS. Square stays as a read-only archive for 90 days while you settle into the new system.
What about cards already authorised but not captured?
Pre-authorised but uncaptured cards from Friday/Saturday Square sales finish out on Square — they were authorised against Square's merchant of record, the capture has to clear there. New sales from Monday onward route through your Stripe account. The split is clean as long as you draw the cutover line at end-of-day Sunday.
Refunds for sales rung on Square
Refunds for Square-rung sales process through Square's refund flow — the original transaction lives there. Customer brings back an item bought last week? Look up on Square; issue the refund on Square. The cash + card movement clears on the original tender; your books reflect it via the Square export.
From Monday forward, refunds for RetailPOS-rung sales process through RetailPOS. The customer-facing flow is identical; the back-end split is invisible to anyone but your accountant.
Common gotchas
Item modifiers in Square use a different structure.Square's modifier flow is per-item; RetailPOS' is per-modifier-group reused across items. If you had “Size” modifier on 30 items, you set up the Size modifier group once on RetailPOS and attach it to all 30. The first 5 minutes feel different; after that it's less work.
Tax classes don't auto-map.Square's “Tax category” field doesn't translate 1:1 to RetailPOS' tax classes. Plan to re-classify items into Standard / Reduced / Zero-Rated / Exempt during the cutover. Tedious but one-time.
Cash drawer assignments per shift.Square's drawer model is per-device; RetailPOS' is per-shift (a register-shift opens with a float, closes with a count). If you currently treat your drawer informally, this is a small process change. Most owners welcome it; some staff find it more rigorous.
Frequently asked
- How long does the migration take in total?
- About 5-8 hours of focused work spread across one week. Item + customer imports take minutes; the bulk is configuring modifier groups, recipes (if applicable), tax classes, and stylist commission rates (if applicable). The Sunday cutover itself is about 90 minutes.
- Can I run both Square and RetailPOS in parallel for a week?
- Yes. Most owners do a 2-day parallel run on the Friday-Saturday before cutover. The risk is splitting customer loyalty + retention across two systems; do the parallel run with internal-only sales (your staff ringing test purchases) rather than real customers.
- What happens to my Square Loyalty members?
- The point balances don't migrate. Plan a “Cash out your points” promotion in the last week on Square — most customers redeem; the rest get a courtesy email + a one-time discount code on RetailPOS that approximates their accumulated value. After cutover, the loyalty ledger starts fresh.
- Do I lose my historical data?
- No — Square keeps your historical data per their data-retention policy (90 days on the entry tier; longer on paid tiers). Export everything before cutover and save it for your accountant. RetailPOS doesn't backfill historical sales because the data shape would be ambiguous.
- Will my card readers work?
- Square readers won't (they're locked to Square's SDK). Stripe Reader M2 will (ships free with a Stripe account). Star printers, Honeywell scanners, cash drawers, iPad tills — all work as-is.
- What if I'm on Square Restaurants (the higher tier)?
- Same migration path. The KDS + course-fire features carry the most configuration; you'll re-configure kitchen ticket printing on RetailPOS during the cutover. Plan to spend 2-3 extra hours on kitchen flow setup.
Open your shop in 30 seconds.
No card. Free until your first 100 sales. Bring your own Stripe; keep your hardware.