Shopify POS Migration: What to Move Before Stores Go Live

A Shopify POS migration is not finished when the data imports.

The store has to open. Staff need to find the right product, scan the right barcode, choose the right customer, process the right return, trust the inventory count, close the register, and explain the day in reporting. If one of those pieces is wrong, the migration becomes a retail problem, not a data problem.

The question is not only "can products, customers, and orders move to Shopify POS?" The better question is what each record needs to do after the move.

Import in the order the business depends on

Migration order matters because retail records depend on each other.

Shopify's migration guidance says products should be imported before customers, and customers before historical orders, so orders can connect to the right products and customers. That is a technical rule, but it is also a useful operating rule.

Products are the selling layer. Customers are the service and relationship layer. Orders are the history layer. If those layers are imported out of sequence or with weak identifiers, the new POS can show data without giving staff the context they need.

Before migration, decide:

• Which products and variants should be active in Shopify POS.
• Which products should stay historical, hidden, archived, or online-only.
• Which customer records should merge, update, or stay separate.
• Which historical orders should move for returns, exchanges, warranty, support, and reporting.
• Which records need to connect to loyalty, Klaviyo, accounting, ERP, or support systems after launch.

Do not treat import order as an admin detail. It decides whether the store team can work cleanly on day one.

Clean products before they become retail problems

Product data looks harmless in a spreadsheet.

In store, the same data controls search, scanning, checkout, inventory, receipts, returns, exchanges, staff training, product recommendations, and reporting. A duplicated SKU, stale barcode, inactive variant, confusing product title, or wrong tax category can slow down every transaction that touches it.

Shopify's product CSV import documentation explains that imports can publish products to sales channels and can overwrite matching handles when selected. That is powerful, but it also means the team needs to know exactly which product fields are safe to overwrite before the import runs.

For POS migration, review product data in retail language:

• Product title, variant title, SKU, barcode, vendor, product type, collection, tax category, and price.
• Whether each product is sellable in store, online, both, or neither.
• Which variants need barcode fixes before launch.
• Which products are discontinued but still needed for returns.
• Which bundles, kits, gift cards, services, deposits, repairs, or custom items need special handling.
• Which product records need metafields or tags for reporting, merchandising, or lifecycle marketing.

The goal is not a perfect catalog. The goal is a catalog that staff can sell from without guessing.

Decide which customers should merge

Customer migration is where POS data can either strengthen the business or make customer identity worse.

Retail systems often contain duplicates, missing emails, phone-only profiles, households sharing one account, loyalty IDs, staff test customers, wholesale accounts, and old notes that should not drive marketing. If those records move without a matching rule, Shopify can inherit the mess.

Shopify's customer CSV guidance allows customer imports and includes an option to overwrite existing customers with matching email or phone. It also supports tagging customers from a CSV import. Those options are useful only when the team has decided what a match means.

Before importing customer data, define:

• Whether email, phone, legacy customer ID, loyalty ID, or Shopify customer ID is the primary match key.
• Which duplicate records should merge, which should remain separate, and which should be archived.
• Which POS customers have usable marketing consent.
• Which customer tags are reliable operating rules and which are old migration residue.
• Which fields staff should see at checkout.
• Which fields Klaviyo, loyalty, support, or analytics should receive after launch.

Do not let the import create a bigger audience for weak data. A larger customer table is not useful if the business cannot trust who the customer is.

Move only the historical orders that have a job

Historical orders are tempting to move in bulk.

Sometimes that makes sense. Sometimes it creates noise. The right decision depends on what staff, support, finance, marketing, and customers need after launch.

Shopify's POS launch checklist calls out historical order migration because it can preserve customer purchase history and support returns or exchanges. Shopify's broader order documentation also supports exporting order data for analysis and recordkeeping.

For a POS migration, historical orders usually need one of four jobs:

• Support returns and exchanges inside the active return window.
• Give staff enough purchase context to serve the customer.
• Preserve finance, tax, reconciliation, warranty, or audit context.
• Feed lifecycle, loyalty, VIP, replenishment, or customer-value reporting.

That does not mean every order must become a fully usable Shopify order. Some history can live in a reference file or reporting warehouse. Some should move into Shopify. Some should stay out because it would confuse staff or distort reports.

Before launch, decide the cutoff window, required fields, refund and exchange behavior, gift receipt handling, legacy discounts, tax treatment, and how migrated orders should appear in reports.

Map locations before inventory moves

Inventory migration is not only quantity.

For retail, inventory means product, variant, location, sellable state, transfer state, receiving state, damaged state, pickup availability, and ownership. If those rules are unclear, Shopify POS can be technically connected while stores still argue about which stock can be sold.

Shopify's retail migration guide is useful because it treats migration as a retail setup path, including products, customers, inventory, locations, payments, hardware, staff, taxes, and launch tasks. That is the right frame.

Before moving inventory into Shopify POS, define:

• Which locations represent stores, warehouses, pop-ups, events, repair stock, or internal inventory.
• Which locations can sell through POS.
• Which locations can fulfill online orders.
• Which stock is reserved, damaged, in transfer, on hold, or not available to sell.
• Who can adjust counts.
• Which transfers or receiving workflows must be complete before launch.
• Which reports decide whether the inventory import matched reality.

If this article feels close to inventory sync, that is intentional. The migration creates the base layer that the later sync has to trust. For deeper inventory rules, read the Shopify POS inventory sync guide.

Set staff, roles, PINs, and registers before training

Staff setup is not a launch-day admin task.

It affects checkout speed, returns, discounts, cash tracking, customer edits, store access, manager approvals, and accountability. If everyone shares a login or receives the wrong access, the data after launch will be harder to trust.

Shopify POS staff management controls who can use POS, which locations they can access, and which POS tasks they can complete. Shopify also notes that actions in Shopify POS are associated with the staff member who entered the PIN, while POS permissions are managed separately through POS roles on POS Pro locations.

Before training starts, decide:

• Which staff need POS access.
• Which locations each person can access.
• Which roles can process returns, discounts, cash tracking, customer edits, inventory adjustments, and manager overrides.
• Which registers, devices, card readers, receipt printers, barcode scanners, and cash drawers belong to each location.
• What staff should do when a device, PIN, barcode, customer lookup, or payment path fails.

Training is much easier when the system already reflects how the store works.

Protect reporting and reconciliation

A POS migration can look successful at checkout and still fail in reporting.

Leadership needs to compare old and new sales, finance needs reconciliation, retail managers need register and staff reporting, ecommerce needs channel context, and marketing needs enough customer and product data to understand repeat behavior. If these teams define success after launch, the first reports will surprise everyone.

Before go-live, define the reporting baseline:

• Daily sales by location, channel, register, payment method, staff member, and product category.
• Returns, exchanges, discounts, gift cards, taxes, tips, cash movement, and payment fees.
• Inventory adjustments, transfers, shrink, damaged goods, and sell-through.
• Customer records created in store, customer records matched to existing profiles, and consent capture.
• Lifecycle handoff into Klaviyo, loyalty, support, or analytics.
• Which legacy reports need a one-time bridge during the transition.

The purpose is not to recreate every old report. It is to preserve the reports the business uses to make decisions.

Test the first week, not only the first transaction

A clean test sale is not enough.

The first week of retail will include imperfect data, staff questions, returns, exchanges, out-of-stock products, discounts, offline moments, device issues, customer lookup problems, and reporting questions. The QA plan should include those cases before real customers find them.

Test scenarios like:

• Sell a normal product with a barcode scan.
• Sell a product with variants, tax rules, or discounts.
• Look up a migrated customer and attach the customer to the sale.
• Create a new customer and confirm consent behavior.
• Return a historical order from the legacy POS window.
• Exchange an online order in store.
• Sell the last unit at one location and check inventory behavior.
• Process a manager-approved discount or return.
• Close a register and reconcile payment totals.
• Confirm reporting by location, staff member, product, and channel.

Each scenario should have an expected result in Shopify POS, Shopify admin, inventory, reporting, support, and any lifecycle system that uses the data.

Treat POS migration as store operations work

Products, customers, and orders are only the visible part of Shopify POS migration.

The real work is deciding how the store will run after those records move. Which products can staff sell? Which customers can they trust? Which historical orders can they return? Which inventory counts are real? Which permissions protect the business? Which reports replace the old daily rhythm?

Lake House Group treats Shopify POS migration as retail operations work, not only data transfer. If you are moving stores onto Shopify POS and need the products, customers, orders, inventory, staff, registers, reporting, and launch QA mapped before go-live, talk to Lake House Group about Shopify POS migration.

Related reading

• Shopify POS integration services
• Shopify POS inventory sync
• Unify POS and marketing data on Shopify
• Shopify customer data migration during replatforming