How to Export WooCommerce Customers to CSV
A customer export can look successful while still being the wrong file. It may contain newsletter subscribers instead of shoppers, a list of emails with no addresses, or every WordPress user regardless of role. You often discover the gap only when the file is needed for a migration or account review.
WooCommerce customers are WordPress users with WooCommerce profile data. They are not products, posts, or orders, so Shirely gives them a dedicated export path. The result is one row per user with the customer role, including the account fields plus billing and shipping details held by WooCommerce.
Decide why you need the export
The purpose affects how you should handle the result. A migration copy needs identifiers that the importer can use. An internal review may need only contact and address fields. A data-access request has its own scope and legal process; a general customer CSV is not automatically a complete compliance response.
Before exporting, decide:
- who needs access to the file;
- where it will be stored;
- whether it will be imported into another Shirely-powered store;
- how long the copy should be retained;
- whether order history is needed separately.
Run the export on demand when you are ready to secure and review the output. Customer export is not one of the catalog Automation export-slot types in Shirely 1.3.
What the customer CSV includes
The exporter reads WooCommerce customer objects and writes these columns:
customer_id, origin_ref, user_login, user_email, role, first_name, last_name, date_registered,
billing_first_name, billing_last_name, billing_company, billing_address_1, billing_address_2,
billing_city, billing_state, billing_postcode, billing_country, billing_email, billing_phone,
shipping_first_name, shipping_last_name, shipping_company, shipping_address_1, shipping_address_2,
shipping_city, shipping_state, shipping_postcode, shipping_countryThe account and address data sit on the same row, which makes a profile easy to inspect in a spreadsheet and straightforward to map during a customer import.
The export does not include order history. It also does not export passwords or password hashes. If you are preparing a full store migration, export orders separately and plan how customers will regain access through the destination store's normal password-reset process.
Why this cannot use a product or post query
WooCommerce products are post-based catalog objects. Customers are users. Their billing and shipping values live in user-related metadata and are exposed through WooCommerce's customer layer.
That distinction matters. A generic post export cannot produce a reliable customer list, and an export of all WordPress users can include administrators, editors, or service accounts that do not belong in a customer migration.
Shirely selects users with the customer role by default and builds each row from the appropriate account and WooCommerce profile fields. It keeps customer work separate from the product and order workflows so the result has a clear meaning.
Keep customer_id and origin_ref together
For a Shirely export-import round trip, retain both identifier columns.
customer_id is the local WordPress user ID. It is useful on the source store, but the same number may belong to a completely different user on the destination. origin_ref gives the importer provenance that helps distinguish a genuine same-source match from an accidental numeric collision.
Do not edit those columns to make IDs “line up” across stores. If the destination cannot safely establish the match, resolving the row is better than overwriting an unrelated account.
Email remains an important natural key for customer matching. Before migrating, look for duplicate or malformed email values in the source data and decide how those exceptions should be handled.
Spreadsheet safety is part of the export
Shirely writes a UTF-8 CSV with a byte-order mark for spreadsheet compatibility. It also prefixes values that could be interpreted as spreadsheet formulas when they begin with characters such as =, +, -, or @.
That protection helps a spreadsheet treat those cells as text. It does not make the file non-sensitive. Names, addresses, phone numbers, and emails are personal data, so use appropriate storage, access, transfer, and deletion practices.
If you only need to inspect a few fields, consider working from a controlled copy and removing unneeded personal columns before sharing it with another team.
Verify the export before relying on it
Open the CSV and check a small, varied sample:
- the number of rows is plausible for users with the customer role;
user_email, names, and registration dates are in the expected columns;- billing and shipping addresses have not shifted;
- international characters are readable;
- billing and shipping values that differ remain distinct;
- no administrator or unrelated WordPress role appears in the file;
customer_idandorigin_refare present for a planned round trip.
For a migration, import a handful of these rows into staging. Confirm both a new account and an existing-email match before trusting the full file.
Frequently asked questions
Which users are included?
By default, Shirely exports WordPress users with the customer role. It does not treat every WordPress user as a WooCommerce customer.
Are customer passwords exported?
No. Passwords and password hashes are not part of the CSV.
Does the file include customer orders?
No. Export the order history through the dedicated WooCommerce order export.
Can I open the CSV in Excel or another spreadsheet?
Yes. The file uses UTF-8 spreadsheet compatibility and includes formula-trigger protection. Continue to treat it as sensitive personal data.
Does this require WPML or Matrix Mode?
No. Customer accounts are not translated catalog rows and do not use Matrix Mode.
For the return path, follow how to import WooCommerce customers from CSV. If the migration also includes sales history, prepare a separate WooCommerce order export and verify the dependencies on staging. The documentation covers the wider workflow.