Migrating Your POS Without Losing Data — A 14-Day Playbook

We've migrated hundreds of retailers off Square, Clover, Lightspeed, KORONA, Heartland, NCR, and a half-dozen other POS platforms onto vertical POS systems. The migrations that go sideways have a pattern: someone treated it as a hardware install instead of a data project. This guide flips that — treat the data as the project, treat the hardware install as the easy part.

Why 14 days

Shorter migrations skip steps. Longer migrations lose momentum and stretch into months. Fourteen days gives you:

• One week to export, validate, and re-import data while the old system still runs
• Three to four days for staff training and parallel testing
• A defined cutover night with full support coverage
• A week of post-cutover reconciliation to catch anything that drifted

You can compress this to 7 days for a single-location operator with a clean catalog. You can stretch it to 30 days for a multi-location chain with custom integrations. Fourteen is the sweet spot for most.

Day-by-day plan

Below, what actually happens on each of those days.

Day -14: kickoff and data export request

The single most time-sensitive action on day one is submitting the data export request to your current vendor. Some vendors respond in 24 hours; others take 7–10 business days and require a written request through a specific channel. Vendors that are about to lose you as a customer are not motivated to move fast — assume the worst case.

What to ask for:

• Full item catalog — every SKU, parent and variant, with cost, retail price, tax mapping, vendor, category
• Customer database — name, email, phone, address, loyalty balance, store credit, lifetime spend
• Sales history — at least 13 months (covers year-over-year reporting)
• Open balances — gift cards, store credit, layaways, house accounts
• Employee records — names, roles, hire dates (not Social Security numbers — payroll keeps those)
• Vendor records — purchase order history if you'll keep using the same suppliers

Some vendors will only export to their proprietary format. Ask for CSV; if they refuse, ask for whatever they offer and budget time to convert.

Simultaneously, your new vendor starts account provisioning — new merchant account application, processor underwriting (especially important for counter-culture verticals where underwriting can take 5–7 days), and hardware ordering.

Day -13 to -10: data validation, the unglamorous core

This is where migrations live or die. The exports you got from the old vendor are almost never clean. Expect:

• Duplicate customer records (same email, different capitalization; same phone, different format)
• Orphan SKUs with no category or vendor mapping
• Discontinued items still flagged as active
• Inventory counts that don't match the floor (cycle counts have been deferred)
• Gift card balances that don't tie out (the old POS forgot a few)

Walk through each export file with a real person, not a script. The data quality issue you don't catch now becomes a customer-experience issue on day +3 when someone tries to redeem a gift card the new system doesn't know about.

For inventory specifically, this is also your chance to clean the catalog. Migration is the rare moment you have the leverage to retire dead SKUs, fix bad category mappings, and consolidate variants. Don't waste it.

Day -7 to -4: hardware staging and training

Hardware arrives. Stage it at the store — terminals, printers, scanners, payment devices, customer-facing displays, cash drawers. Confirm each component talks to the next. Do not install yet at the actual counter; stage in the office or stock room.

Payment processor re-certification is submitted in parallel. If you're using the same processor with new POS software, this is a same-day approval. If you're switching processors, expect 3–5 business days.

Staff training runs over two sessions:

• Session 1 — checkout flow, customer search, tender types, basic returns/voids. Everyone attends. About 90 minutes.
• Session 2 — manager track. Reports, end-of-day, voids/refunds, employee management, inventory receiving. Managers and key staff only. About 2 hours.

Print cheat sheets and tape them to the back of each terminal. New muscle memory takes 2–3 weeks; the cheat sheet bridges the first week.

Day -3 to -1: parallel test, final export, freeze

Day -3 is the parallel transaction test — pick five real customer orders that came through that day and ring them on both the old system and the new system. Note any differences in:

• Total (tax calculation differences are the most common gotcha)
• Inventory deduction (matrix items can drift if mapping is off)
• Loyalty earn
• Receipt format
• Payment authorization speed

Fix anything that doesn't match.

Day -2 confirms peripherals — payment device tap/insert/swipe, barcode scanner across your weirdest packaging, scale (if you sell by weight), kitchen display (if you have one).

Day -1 is the final data export from the old system. This is the export that gets imported the night of cutover — everything from -10 was for validation, this one is for the actual handoff. After this export, the old system runs in lock mode — no new SKU adds, no customer record changes. Sales still process, but no master-data changes. This freeze is what keeps the cutover clean.

Day 0: cutover night

Cutover happens after close. The sequence:

1. 1Close the day on the old POS as normal — Z-out report, end-of-day reconciliation, cash drop
2. 2Export the final delta since the day -1 export (today's sales, new customers, inventory adjustments)
3. 3Import the delta into the new POS
4. 4Run a sanity check on top customers, top SKUs, gift card balances
5. 5Power down the old terminals at the counter
6. 6Bring the new terminals from staging to the counter
7. 7Run a test transaction on each new terminal — small dollar, refund immediately
8. 8Confirm the new system shows the correct opening cash count for the next morning

Total time: 3–5 hours for a single-location store. Plan to be there until midnight.

Day +1: launch day

Cutover support — onsite if local, remote screen-share if not — is on standby for the entire first business day. The first 4 hours of the first day surface 80% of the issues. After that the team has the muscle memory.

What goes wrong on day +1:

• A receipt printer doesn't connect on first boot (usually a power-cycle fix)
• A SKU rings up at the wrong price (catalog mapping error; fix in real time)
• A returning customer's loyalty balance is short (run the reconciliation query, top them off)
• A staff member forgets a step from training (cheat sheet)

None of these are catastrophic. All of them are easier with someone standing by.

Day +3 to +7: reconciliation

The most important step nobody plans for. For the first 7 days, you run a variance report comparing what the new POS captured against what the old POS would have captured. Look for:

• Daily sales totals — within $5 of each other, allowing for tax rounding
• Top 20 SKU unit counts — should match
• Loyalty earn/redeem — totals should reconcile
• Tip totals — should match within rounding
• Cash drop — should match the cash drawer count

A variance of more than 1% on any of these signals a configuration issue, not a normal drift. Common causes: a tax code mapped wrong, a discount stacking incorrectly, a promo that didn't migrate.

By day +7 the variance is either zero or you know exactly why it's nonzero. That's the signoff point.

What we always carry across, and what we usually leave behind

Always migrate:

• Active SKUs (last 12 months of sales)
• Active customers (last 24 months of transactions)
• Gift card and store credit balances (all open)
• Loyalty point balances (all active accounts)
• Tax mappings
• Employee records and roles

Usually leave behind:

• Discontinued SKUs (export to archive, don't import)
• Customer records with no transactions in 36+ months
• Sales history detail older than 13 months (export to PDF archive; don't carry transactional data forward)
• Stale promotions
• Legacy hardware configurations

The instinct is "migrate everything." It's wrong. Migrating dead data into a new system clutters the search, slows queries, and gives staff bad data to act on. Be ruthless.

Migrating off specific platforms

The export workflow is similar across vendors, but a few common origin platforms have quirks worth flagging up front:

• Square / Square for Retail — catalog and customer exports are clean CSVs. Caveat: their "categories" sometimes nest in ways that don't map 1:1; flatten before re-import. Gift cards on Square have to be balance-exported manually per card.
• Clover — uses a multi-table export. Item modifiers (variants) export separately from items and need to be re-stitched. Loyalty data exports as raw points only — historical activity is not portable.
• Freedom POS — catalog exports to CSV with vendor codes intact. The tricky part is shift report history — Freedom keeps shift data in a separate database that doesn't export by default. If you need it for tax or audit purposes, request a full database dump at least 14 days before cutover; their support team can take a week to respond.
• Lightspeed Retail — clean exports overall, but the "matrix" attribute (variant inventory) doesn't always survive — verify each multi-variant SKU manually.
• QuickBooks POS (legacy) — Intuit sunset this product, so many migrations originate here. Convert the QBPOS file via Intuit's export utility, then map fields manually; field names are non-obvious.

Regardless of origin platform: do the export EARLY in the 14-day window. The single most common project delay is the prior vendor taking 5+ business days to deliver an export they said would take 24 hours.

Payment processor re-certification

Worth its own callout: when you switch POS software, your payment processor has to re-certify the integration even if you're keeping the same processor. The new POS sends transactions in a slightly different format; the processor has to validate that the format is correct before going live.

Re-certification requirements vary, but typically include:

• Test transaction set (sale, void, refund, partial refund, tip adjust)
• Settlement test (close batch, confirm settlement)
• Decline handling test
• EMV / contactless / swipe across the test set

If you're using the same processor, this is usually approved same-day. If you're switching processors, plan for 3–5 business days plus underwriting time on the merchant account (longer for high-risk MCC codes).

For broader context on the POS/processor/merchant-account split, see /resources/blog/pos-vs-payment-processor-vs-merchant-account.

Catalog mapping — the hardest data project

Old SKU → new SKU mapping is the data work that takes the longest. Three patterns:

• 1:1 mapping — old SKU `BLU-VAPE-12` maps to new SKU `BLU-VAPE-12`. Fastest; spreadsheet does it.
• N:1 consolidation — multiple legacy SKUs collapsed into one matrix parent with variants. Most common for shops that grew without a SKU discipline. Requires careful mapping; do not automate.
• 1:N expansion — one legacy SKU split into variants for the first time. Rare but happens when the old POS couldn't handle variants and the new one can.

Catalog mapping is also the right time to standardize SKU naming. If your old catalog has `BLUE_VAPE_12`, `Blue-Vape-12`, and `bluevape12`, the new catalog should have one canonical format.

For data-migration best practices in general, NIST's SP 800-160 systems engineering guidance covers the broader principles of trustworthy data transitions — overkill for a single-store POS migration but useful framing for multi-location operators.

Where Lifelong fits

We run this 14-day playbook for every merchant onboarding:

• Day -14 kickoff call with the project lead from our team and the operator
• Export coordination with the outgoing vendor — we know the export pathways for the major platforms
• Catalog mapping done by our onboarding team, not handed back to the owner
• Hardware shipped pre-configured to staging, then installed onsite
• Two-session staff training included in onboarding
• Cutover night with our team online or onsite
• 7-day reconciliation signed off before we close the migration ticket

We've run hundreds of these migrations. The reason they work is the playbook — not improvisation, not heroics.

For more on how we onboard new accounts, see our specialty & counter-culture retail POS and talk to our Atlanta team to start a migration conversation.

FAQ

Can I migrate POS without closing the store?

Yes. The actual cutover happens after close, so you don't lose business hours. You also don't run two POS systems live at the same time — that creates reconciliation chaos. Old system runs through close on day 0; new system opens on day +1.

What's the biggest mistake operators make?

Underestimating data validation. They assume the export is clean, they import it, and they find broken catalog mappings on day +3 when a customer can't redeem a gift card. Spend the time on days -10 through -7 looking at the data.

How much does a POS migration cost?

Depends on the new vendor. Software is usually $79–export const blogPosts: BlogPost[] = [ 99/month per location. Hardware is export const blogPosts: BlogPost[] = [ ,500–$3,500 per station one-time. Migration labor is sometimes included in onboarding, sometimes $500–$2,000 one-time. Total first-year cost for a single-location migration: $3,000–$7,000 including hardware and one year of software.

What if my old vendor refuses to export my data?

This happens, especially with bundled-processor POS vendors that don't want you to leave. Three options: (1) escalate in writing to a manager, (2) export what you can via the merchant-facing UI (screen-scrape every customer and SKU if you have to), (3) the nuclear option — file a complaint with your state Attorney General's office on data portability grounds. We've never had a migration fail because of a vendor refusing to export; some have just been slower than they should be.

Do I need to migrate sales history?

For most retailers, no — keep an archived PDF of the last 13 months of reports from the old system and don't carry transactional history into the new POS. You preserve the audit trail without polluting the new system with stale transactional data. Multi-location chains and operators with tax-audit concerns sometimes do migrate detail; most don't.

Get a migration plan

If you're switching POS systems in the next 90 days, we'll walk through your specific catalog, processor, and hardware setup and give you a written 14-day plan. No commitment. talk to our Atlanta team to book.