/ Journal — Migration
How to Migrate Customers and Order History to Shopify Without Losing Useful Data
When you migrate customers to Shopify, getting rows into the Customers screen is the easy part. The harder job is preserving what makes those records useful: a reliable identity, valid contact details, defensible marketing consent, usable addresses, account access, purchase context, loyalty status, tax treatment, and enough history for support teams to help people after launch.
( Short answer )
A technically successful import can still create a poor customer experience.
Duplicate profiles split order history. Old passwords stop working without warning. Every imported contact is marked as subscribed. Historical orders inflate reports or trigger notifications. Service agents can no longer see what a customer bought, paid, returned, or was promised.
Short answer Customer migration
Short answer
Export customers and orders from the source, preserve immutable originals, profile and deduplicate the data, map every field to Shopify or a documented archive, choose the account transition, import products before customers and customers before orders, run controlled test loads, and reconcile relationships rather than counts alone. Treat consent, privacy, support access, and launch communications as part of the migration—not cleanup after it.
/ Useful data
Decide what “useful data” means before mapping fields.
The source platform probably contains more customer data than Shopify needs, but less structure than the business assumes. A field is worth migrating when it supports a real customer, legal, operational, analytical, or service requirement. Everything else should be retained in an appropriately governed archive or deliberately excluded. Start with questions that describe outcomes.
Turn each answer into a field requirement, an owner, and an acceptance test. “Customer data migrated” is not a test. “A sampled customer can sign in, view the correct three orders, retain an unsubscribed email state, and be found by support using their old order number” is.
01Can a returning customer sign in or regain access without contacting support?
02Can they see the orders you have promised will remain visible?
03Can an agent identify them, understand prior purchases, and handle a return or warranty question?
04Will email and SMS platforms receive the correct consent state?
05Will loyalty, subscriptions, store credit, tax exemptions, B2B relationships, and discounts still work?
06Can finance reconcile historical transactions without treating them as new sales?
07Can the business answer access or deletion requests after the source system is retired?
/ Field map ( 10 )
Build a source-to-Shopify customer field map.
Shopify customer records can hold core identity and contact fields, addresses, marketing preferences, tags, notes, tax settings, locale, and metafields. The exact import route matters. Shopify’s native customer CSV is suitable for common profile data; an app or GraphQL Admin API workflow is usually better when you need multiple addresses, custom fields, detailed consent metadata, repeatable upserts, or stronger error handling.
( Source data → likely Shopify destination — migration decision )
01First and last name → Customer name fields — Normalize encoding and avoid inventing a name from an email address.
02Email and phone → Customer contact fields — Normalize case and phone format; decide how to handle shared, missing, invalid, or duplicate values.
03Billing and shipping addresses → Customer addresses and default address — Preserve multiple useful addresses where the route supports them; do not assume the latest address is the default.
04Email, SMS, or WhatsApp consent → Channel-specific marketing consent — Map state, date, source, and opt-in level where available. Unknown is not subscribed.
05Segments and groups → Tags, customer segments, metafields, or app records — Rebuild dynamic audiences from dependable attributes instead of migrating stale labels blindly.
06Birthday, preferences, external IDs → Defined customer metafields — Create definitions, types, validation, access rules, and retention logic first.
07Customer service notes → Notes, tags, helpdesk records, or secure archive — Exclude irrelevant, sensitive, subjective, or ungoverned free text.
08Tax status → Tax-exempt setting and exemptions — Validate against current business and legal rules rather than copying an old flag without evidence.
09Loyalty and store credit → Loyalty app, native capability where applicable, or metafields — Move balances and ledgers through the destination system’s supported process, then reconcile totals and samples.
10Legacy customer ID → Metafield, tag, or migration crosswalk — Keep a durable crosswalk from source ID to Shopify ID for orders, support, integrations, and reruns.
Shopify’s current GraphQL customer input supports names, unique email and phone values, locale, notes, tags, tax fields, marketing consent and metafields. Shopify also treats customer data as protected data for apps, so API access should be limited to a legitimate need and the migration solution should meet the applicable protected-customer-data requirements.
( Keep a migration crosswalk )
Never use email alone as the permanent key.
People change addresses, families share inboxes, guest checkouts may create inconsistent records, and malformed imports can produce duplicates. Maintain a protected crosswalk containing the source customer ID, destination Shopify customer ID, import batch, transformation version, status, and error reason.
Apply the same principle to products, variants, and orders. Those crosswalks make relationships reproducible and let you rerun a failed batch without guessing which record already exists.
Migration crosswalk Source → Shopify
Source IDSource customer ID
Shopify IDDestination Shopify customer ID
BatchImport batch
VersionTransformation version
StatusStatus
ErrorError reason
/ Clean and deduplicate ( 09 )
Clean and deduplicate without erasing evidence.
Data cleanup should be deterministic. Keep the raw export immutable, transform a working copy, and log every rule. That gives you a defensible path back when a merge decision is wrong.
Consent should normally follow the most restrictive valid state when evidence conflicts, subject to legal advice and your documented policy. A later unsubscribe must not be overwritten by an older subscribe event simply because the subscribed source row looked more complete.
01Normalize email case and whitespace without changing the actual mailbox.
02Parse phone numbers with country context and retain the original value for investigation.
03Standardize country and region values to formats accepted by the destination.
04Validate character encoding so accented and non-Latin names and addresses survive.
05Identify duplicate emails, phones, postal addresses, source IDs, and suspiciously similar names.
06Separate true duplicates from household members and business contacts who share details.
07Choose which profile wins for names, addresses, consent, tax status, loyalty, notes, and creation date.
08Record merged source IDs so their orders can connect to the surviving Shopify customer.
09Quarantine records that cannot be resolved safely instead of forcing an import.
/ Passwords and accounts ( 03 )
Customer passwords and accounts need a separate plan.
Do not promise that existing passwords will transfer. Passwords are generally stored as one-way hashes, and platforms use different hashing and account systems. Native customer CSV migration does not turn a source password into a working Shopify credential.
Your transition depends on the Shopify account model selected for the store:
01 · Passwordless
Passwordless customer accounts
Customers sign in using the supported verification flow, so the migration communication should explain the new experience rather than ask everyone to create another password.
02 · Password-based
A password-based or legacy account experience
Imported customer profiles still require an activation or password-setting journey. Test invitation behavior, templates, links, expiry, deliverability, and what the customer sees if they check out before activating.
03 · External identity
Shopify Plus with an external identity design
Multipass or another supported identity architecture may be relevant, but it is not a shortcut for copying password hashes. Define identity ownership, logout, account linking, and failure handling.
( Operational rule )
Do not send account invitations during a bulk test import.
Account messaging should state what changed, how to sign in, whether old order history will appear, how subscriptions or loyalty are handled, and where to get help. Prepare agents for common cases such as a missing code, an email typo, a duplicate profile, or an order attached to a different address.
Operational rule Account invitations
Operational rule
Do not send account invitations during a bulk test import. Use suppressed communications or controlled test addresses, then schedule the real activation campaign after production data and account pages pass QA.
/ Marketing consent
Preserve marketing consent, not just a yes/no column.
Marketing consent is not an enrichment field. It is evidence about whether and how a person agreed to receive messages. Shopify’s current API models channel-specific consent and can include a state, consent update time, opt-in level, and source location. The available fields differ by channel and import route.
Build a consent matrix before loading customers:
( Source state → destination treatment — required evidence )
+Subscribed → Subscribe only when the record is valid for that channel — Evidence: Source, timestamp, method, applicable wording or system evidence
+Unsubscribed → Preserve unsubscribe/suppression — Evidence: Latest opt-out event and channel
+Pending or unconfirmed → Map to the supported pending/not-subscribed behavior — Evidence: Original flow and confirmation state
+Unknown, blank, or ambiguous → Do not infer subscription — Evidence: Quarantine or retain as non-marketable until lawfully captured
+Invalid or bounced → Keep suppression in the marketing platform — Evidence: Bounce or invalid-address status
Coordinate Shopify with the email service provider, SMS platform, CRM, and consent-management platform. If one system imports an unsubscribe while another immediately syncs an older subscribed state back, the migration has failed even if both loads completed.
Have privacy or legal counsel confirm the handling appropriate to your markets. Consent rules, retention duties, and lawful bases are not interchangeable across the United States, United Kingdom, European Union, and other regions.
/ Addresses
Handle customer addresses as structured operational data.
Addresses affect more than the account page. They influence service, tax, fraud review, shipping labels, B2B workflows, and the ability to match historical orders. Common source problems include a full address stored in one line, missing country codes, free-text states, obsolete addresses, duplicate defaults, and unsupported characters.
Preserve billing and shipping addresses on each historical order even if the customer profile also has an address. An order is a historical transaction; replacing its address with the customer’s current default destroys context.
Test international records deliberately. Use samples with apartments, military formats, diacritics, long company names, non-Latin scripts, territories, and phone-country mismatches. Do not “fix” a valid international address merely because a domestic validation tool does not recognize it.
/ Order history options ( 05 )
Choose how much order history to migrate.
Shopify customer profiles become substantially more useful when relevant historical orders are attached, but importing every legacy transaction is not automatically the right choice. Native Shopify CSV tools support order export, not general historical order import. Depending on the source and requirements, historical orders are typically moved using a migration app, a supported API/custom app workflow, or a platform-specific service.
Shopify’s current Admin GraphQL API includes an order creation capability with fields for customer association and historical context, but the implementation, permissions, API version, financial semantics, and downstream side effects must be validated for your store. Never design from an old migration script or deprecated API behavior without checking the version used at launch.
01 · Full
Full order migration
Best when: Customers and agents need detailed history; returns, warranties, analytics, or account visibility depend on it.
Tradeoff: Highest mapping and validation effort; greater risk of notifications and reporting side effects.
02 · Recent
Recent or policy-based history
Best when: Only a defined service, return, warranty, or reporting period must remain active.
Tradeoff: Older orders need a searchable archive and a clear support workflow.
03 · Summary
Summary data on customer
Best when: Segmentation needs lifetime value, first order, last order, or category affinity, but line-level history is not required.
Tradeoff: Customers cannot inspect original transactions; summaries must not masquerade as Shopify-calculated history.
04 · Archive
External archive or helpdesk view
Best when: Historical records must remain available to staff but should not enter Shopify operational reporting.
Tradeoff: Agents need a reliable lookup tool, access controls, and retention process.
05 · Hybrid
Hybrid approach
Best when: Recent orders need full functionality while older transactions only need service visibility.
Tradeoff: Requires explicit boundaries and training so teams know where to look.
( Order mapping )
Map the parts of an order that support must understand.
For each imported order, decide how to represent the source order number, order date and timezone, customer or guest identity, currency, line items, SKU or legacy product reference, prices, discounts, shipping, tax, duties, payment state, fulfillment state, refunds, cancellations, returns, addresses, notes, and tracking.
Historical products may no longer exist in Shopify. Preserve enough line-item text and external identifiers for an agent to recognize what was purchased. Avoid attaching an old order to a current variant merely because the SKU was reused; that can make the history look precise while being wrong.
/ Reporting and automation ( 07 )
Protect reporting and automation.
Historical orders can trigger staff notifications, customer emails, fulfillment logic, ERP exports, loyalty accrual, review requests, VIP flows, fraud tools, webhooks, and revenue reporting. Before the first test import, inventory every listener that reacts to an order being created or updated.
( Before the first test import )
+Suppress customer and staff notifications where supported and appropriate.
+Pause or filter marketing, loyalty, review, ERP, WMS, helpdesk, and analytics automations.
+Tag or otherwise identify migrated orders consistently.
+Preserve the original transaction date where the chosen method supports it.
+Define whether imported transactions belong in Shopify reports, a BI layer, or neither.
+Ensure migrated paid orders do not attempt payment capture and fulfilled orders do not ship again.
+Re-enable integrations in a controlled order after reconciliation.
/ Import sequence ( 09 )
Use the right import sequence.
Relationships determine the sequence. Products and variants need destination identifiers before historical line items can reference them. Customers need destination identifiers before orders can be associated reliably. Supporting systems need destination customers before loyalty, subscription, B2B, or helpdesk records can attach.
01
Step 01
Freeze schemas and mappings
Define destination fields, metafields, app models, statuses, and validation rules.
02
Step 02
Capture immutable source exports
Include customers, addresses, consent events, orders, refunds, fulfillments, loyalty, subscriptions, and relevant notes.
03
Step 03
Load foundational catalogue records
Create products and variants or at least the crosswalk required by the order strategy.
04
Step 04
Import customers
Create clean profiles, addresses, consent, tags, tax settings, and external identifiers.
05
Step 05
Build the customer ID crosswalk
Resolve duplicate and failed profiles before creating related records.
06
Step 06
Load dependent customer systems
Migrate loyalty, subscriptions, company relationships, store credit, or helpdesk links using the new IDs and each vendor’s supported process.
07
Step 07
Import historical orders
Start with a small representative batch and keep automation controlled.
08
Step 08
Run the final delta
Capture customers, consent changes, addresses, and orders created or modified after the main extract.
09
Step 09
Reconcile, then activate
Do not send invitations or enable all integrations until acceptance criteria pass.
( The final delta )
The delta deserves its own design.
A customer might unsubscribe, change an address, place an order, receive a refund, or merge profiles between the main export and cutover. Track both created and updated records, define the cutoff timestamp in one timezone, and make reruns idempotent.
/ Test pack ( 10 )
Test with representative data before scale.
A random sample is not enough. Create a test pack covering the conditions most likely to expose mapping failures:
+Registered and guest customers, including profiles with no orders.
+Duplicate emails, duplicate phones, missing email, and invalid contact data.
+Subscribed, unsubscribed, pending, unknown, bounced, and channel-specific consent.
+One address, multiple addresses, international formats, and changed defaults.
+Tax-exempt, B2B, wholesale, loyalty, subscription, and high-value customers.
+Single- and multi-currency orders, discounts, gift cards, tax, duties, and shipping.
+Paid, pending, canceled, partially fulfilled, fully fulfilled, refunded, partially refunded, returned, and disputed orders.
+Orders containing deleted products, reused SKUs, bundles, custom items, and edited lines.
+Customers whose email or identity changed after an older order.
+Records with non-Latin text, diacritics, long fields, and unusual punctuation.
Run three levels of validation: structural checks on files and required fields; aggregate reconciliation across counts, totals, statuses, currencies, and consent states; and field-level inspection of known records. Then test actual journeys in the storefront, customer account, admin, helpdesk, marketing platform, and downstream systems.
( Reconciliation )
Reconcile relationships, not only record counts.
“100,000 customers imported” says nothing about whether the right orders, addresses, or consent states are connected to them. Use reconciliation reports that compare source and destination at several levels.
Validation layer Examples
CustomersTotal, success, failure, duplicates, missing email, missing phone, tax-exempt, account path, and records by market
ConsentSubscribed, unsubscribed, pending, unknown, latest event dates, and suppressions by channel
AddressesProfiles with addresses, multiple-address count, country distribution, invalid regions, and default-address match
OrdersCount and gross/net/refund totals by month, currency, financial state, fulfillment state, and source channel
RelationshipsOrders attached to intended customers, guest orders retained as guests, line items matched correctly, and legacy IDs searchable
Side effectsNo unintended emails, shipments, loyalty points, review requests, ERP postings, or duplicate analytics events
Set tolerance rules before launch. Counts should often match exactly; currency totals may require documented rounding treatment; known exclusions should appear in an exception report with an owner and reason. Every failed row needs a disposition: corrected and rerun, accepted as an exclusion, or retained in the archive.
/ Privacy, security and retention
Plan privacy, security, and retention into the migration.
Customer and order exports are concentrated personal data. They should not move casually through inboxes, personal cloud drives, shared spreadsheets, or long-lived developer laptops.
Some transactional records must be retained for tax, accounting, fraud, warranty, or legal reasons even when a customer asks for deletion. Document which system holds those records, the lawful basis, the retention period, and how access is limited. Obtain qualified advice for the markets where you operate.
01Minimize exports to fields required for the approved migration purpose.
02Encrypt files in transit and at rest; restrict access by role and remove it promptly.
03Use synthetic data where realistic personal data is not needed for development.
04Keep an audit trail of exports, transformations, uploads, access, failures, and deletion.
05Define retention periods for raw exports, staging data, crosswalks, logs, and the source archive.
06Avoid logging full addresses, emails, phone numbers, or notes in routine error output.
07Ensure vendors and apps have appropriate data terms, scopes, environments, and deletion processes.
08Design how access, correction, deletion, and restriction requests will be handled across Shopify and retained archives.
/ Support readiness ( 08 )
Prepare customer support for launch.
The support team is often the first place migration defects appear. Give agents a tested workflow rather than a warning that “some account issues are expected.”
( What agents need )
+A searchable mapping from legacy customer and order identifiers to Shopify records.
+A read-only archive or helpdesk view for history not migrated into Shopify.
+Macros for account access, missing order history, consent concerns, loyalty discrepancies, returns, and duplicate profiles.
+An identity-verification policy before changing emails, merging profiles, or exposing historical orders.
+A clear escalation route for data corrections and a rule against manual fixes that will be overwritten by the final delta.
+A known-issues log with customer impact, workaround, owner, and resolution status.
+Staff training using the same representative test customers used during QA.
+Daily reconciliation of account-related contact volume during stabilization.
Do not merge customers casually in response to a ticket. A merge can expose another person’s history if two people share a household email or phone. Require appropriate verification and preserve an audit trail.
/ Launch acceptance ( 13 )
A practical launch acceptance checklist.
01Raw source exports are complete, protected, and recoverable.
02Every source field has a destination, archive, or approved exclusion.
03Duplicate and identity rules are documented and repeatable.
04Customer, product, variant, and order crosswalks are complete.
05The chosen account journey works on production-like templates and email settings.
06Consent states and suppressions reconcile by channel.
07Addresses render correctly and preserve order-time history.
08Order counts, totals, refunds, currencies, and relationships reconcile within agreed tolerances.
09No unintended notifications, fulfillment, payment, loyalty, review, or marketing actions occurred.
10Support can find a migrated customer by current and legacy identifiers.
11The final delta has been rehearsed, timed, and assigned.
12Privacy, retention, archive, and deletion procedures are approved.
13Rollback or forward-fix criteria are explicit and owned.
( How Signature Works approaches it )
We treat migration as an engineering and operating-model problem, not a file upload.
The work starts with data profiling and business requirements, then moves through destination architecture, field mapping, repeatable transformations, controlled imports, reconciliation, account UX, integration testing, cutover, and stabilization.
For an established brand, the right solution is often hybrid: the customer sees the history they need; support retains deeper searchable context; finance and BI preserve the historical record; and Shopify is not burdened with misleading or operationally dangerous data. The design should fit how the business actually serves customers after launch.
/ FAQ ( 08 )
Frequently asked questions about migrating customers to Shopify.
Can I migrate customers to Shopify with their passwords?
Usually not. Source platforms generally store password hashes that cannot be converted into Shopify credentials. Plan for Shopify’s selected customer-account login flow or a controlled activation/password-setting journey, and communicate the change before launch.
Can Shopify import customer order history?
Historical orders can be migrated, but Shopify’s normal CSV tooling is not a general order-import route. Stores commonly use a migration app, a supported custom/API process, or a specialist service. Test permissions, historical dates, statuses, relationships, reporting, and automation side effects before scale.
What customer fields can be migrated to Shopify?
Common fields include name, email, phone, addresses, locale, tags, notes, tax settings, marketing consent, and custom data in metafields. The exact fields and fidelity depend on the import method, account architecture, apps, and quality of the source data.
Should all old orders be imported into Shopify?
Not necessarily. Import the history required for customer accounts, support, returns, warranties, loyalty, operations, or reporting. Older data can remain in a governed searchable archive when loading it into Shopify would add risk without improving the customer or staff experience.
How should email and SMS consent be migrated?
Map each channel separately and preserve the latest valid state plus evidence such as timestamp, source, and opt-in level where available. Keep unsubscribes and suppressions. Do not treat a blank or unknown value as permission to market.
In what order should customer and order data be imported?
Create the required product and variant references first, customers second, and historical orders after customer IDs are available. Then load dependent systems, run the final delta, reconcile relationships, and only enable account invitations and automations after acceptance tests pass.
How do I prevent duplicate customers during a Shopify migration?
Profile the source, define deterministic identity and merge rules, retain source IDs, and maintain a source-to-Shopify crosswalk. Do not rely only on email: shared addresses, changed contact details, guest orders, and invalid values all require exception handling.
How do I verify a Shopify customer migration?
Compare aggregate counts and monetary totals, consent distributions, address coverage, failures, and exclusions. Then inspect representative records and test real journeys across customer accounts, Shopify admin, support, marketing, loyalty, subscriptions, finance, and fulfillment systems.
Official Shopify references:
Shopify Help Center: Importing and exporting customer lists
Shopify Help Center: Migrate to Shopify
Shopify Admin API: CustomerInput
Shopify Admin API: customer email marketing consent input
Shopify Admin API: orderCreate
Shopify developer guidance: protected customer data
Shopify features, APIs, permissions, and account models change. Confirm the current documentation and API version used by your store and migration tooling before implementation.
/ Next
Move customer history without creating launch-day confusion.
Signature Works plans and delivers Shopify and Shopify Plus migrations involving complex customer data, historical orders, integrations, custom apps, account journeys, and operational cutovers.
If you need to migrate customers to Shopify while keeping consent, service history, and downstream systems dependable, we can help define the scope, build the migration, and prove it before launch.
Also worth a look: Migrations and rescues · Custom apps and features · Shopify technical ownership
/ Next
Want this done on your store?
Tell us what’s going on. A first look costs nothing.