WP All Import User Import - WordPress Plugin

A Practical Guide to WP All Import User Import for Importing WordPress Users

WP All Import User Import is not meant for manually adding a couple of accounts. It is designed for controlled migration and updating of user data: usernames, email addresses, roles, profiles, custom user meta fields, WooCommerce customer data, and, with the right preparation, hashed passwords. This guide focuses on the real workflow rather than a promotional overview: how to prepare your file, where to choose the Users import type, how to map fields, how to avoid sending unnecessary emails to users, how to verify the outcome, and what to do if the import stops or updates the wrong records.

This guide is intended for site administrators, developers, integrators, membership site owners, WooCommerce store owners, and agencies that need to migrate users from an old system, update roles, add user meta fields, or regularly sync account lists from an external source. We will rely on the official WP All Import documentation, the product page, the WordPress.org listing, WordPress role documentation, and several comparable alternatives for context.

The main takeaway: importing users is riskier than importing standard content because you are changing who can access the site. Before you run the import, define exactly which records should be created, which should be updated, which column will be treated as unique, which fields may be overwritten, and how you will confirm that the import worked without side effects.

What Problem User Import Solves

In the standard WordPress admin area, you can create a user manually by entering a username, email, name, role, password, and any extra data added by WooCommerce, a membership plugin, a CRM integration, or a profile directory. That approach works while the number of records is small. Once you are dealing with dozens, hundreds, or thousands of users, manual work becomes a source of errors: inconsistent email casing, missed roles, incomplete profiles, accidental emails, duplicates, and broken links to orders or internal entities.

WP All Import User Import turns that process into a managed import workflow. Your input can be CSV, Excel, XML, Google Sheets, or another supported data source. Inside the plugin, you go to All Import › New Import, upload the file, choose the Users type, confirm that the records were detected correctly, and then drag items from the panel on the right into the appropriate WordPress user fields. After that, you define the unique identifier and set the rules for rerunning the import.

This is more than just "uploading a CSV." What makes the plugin valuable is that it separates decisions that basic importers often hide behind a single button: how to identify a record, what to do with duplicates, which fields to update, whether to send email, how to handle passwords, what to do with users who are no longer in the file, and how to run the task on a schedule.

Where WP All Import User Import Is Especially Useful

The plugin works well for projects where user data already exists in a spreadsheet, another CMS, an older WordPress site, a CRM, an LMS, a WooCommerce export, a membership system, or an internal portal. It helps not only with creating accounts, but also with rerunning the import later when the source data changes. That matters for sites that regularly receive updated lists of employees, students, partners, vendors, customers, directory authors, or members of a private area.

• Migrating users from an old WordPress site to a new one, especially together with WP All Export and a bundle file.
• Importing users from CSV or Excel when the column headers do not match WordPress field names.
• Updating roles, names, custom user meta fields, and contact details without editing every profile by hand.
• Migrating WooCommerce customers as WordPress users with additional billing and shipping fields, when that use case is supported by the data structure.
• Regularly syncing users from an external system through a URL, FTP/SFTP, or an existing file on a schedule.
• Bulk editing: export users, update the necessary columns in a spreadsheet, and import back only the fields that actually need to change.

When Another Approach Makes More Sense

WP All Import User Import is not a substitute for a well-designed access model. If you have not yet decided which roles should exist on the site, which permissions they need, which fields are required, and which values should never be trusted from an external source, sort that out in WordPress first. Importing speeds up the operation, but it does not fix poor data architecture.

The plugin may also be overkill if you only need to add 5 to 10 standard subscribers once, with no custom fields and no repeat updates. In that case, the built-in admin interface or a simple CSV tool is enough. It is also not appropriate as a safe interface for untrusted clients: the official WP All Import documentation explicitly warns that import access grants very broad capabilities, including code execution within import settings. The import screen should remain available only to trusted administrators, not casual editors, contractors, or ordinary site users.

What to Check Before Installation and the First Run

The most common user import mistakes begin in the spreadsheet, not in the plugin. People upload a file, see a successful progress bar, and then realize that some accounts were skipped, roles were assigned incorrectly, emails were sent to everyone, or a rerun overwrote manual edits. That is why preparation matters even more here than it does for importing regular content.

Check the Data Source

Do not use the full file for your first test. Build a small sample of 5 to 20 rows that covers different cases: a new user, an existing user, a user with a nonstandard role, a row with an empty optional field, a record with custom user meta, and, if relevant, a row with a hashed password. A file like this is faster to run, easier to verify, and safer to roll back.

For most imports, the minimum useful set includes a username or email, a role, a display name, and a value that can be used to find the record again later. The email should be unique to a real WordPress account. If you are importing usernames containing Cyrillic characters, spaces, or symbols from a legacy system, keep in mind that WordPress applies its own processing rules to usernames. In ambiguous cases, it is better to prepare a separate column with a clean username in advance and keep the original value in a custom user meta field for reference.

Practical check: open the CSV in an editor that preserves encoding, and make sure the first row contains clear headers, the delimiter is consistent across the file, email addresses are not duplicated, and roles are recorded using the actual slugs that exist on the site.

Separate Creation from Updates

If the file contains only new users, the job is simpler: you can create an import configured to make new records, define the identifier, and run it. If the file is supposed to update existing accounts, the workflow changes. You need to decide in advance how rows in the file will be matched to users on the site: by email, username, ID, an external ID stored in user meta, or another stable key.

Do not test everything at once on the first attempt. First, verify the creation of new test users. Then separately verify the update of an existing test user. Only after that should you apply the same rule to the full file. This order saves time because if something fails, you know which part of the workflow caused it: file upload, field mapping, the unique identifier, or the update rule.

Create a Backup and a Rollback Plan

User imports affect the users table and user meta. If you allow missing records to be deleted or all fields to be updated, the consequences can be more serious than with a regular page import. Before a full run, you need a fresh database backup. For a store, LMS, or membership site, also verify how users are connected to orders, subscriptions, courses, profiles, and internal records.

Your rollback plan should be concrete, not theoretical: you should know where the backup is stored, how to restore the database, who has hosting access, how long recovery will take, and what site changes may be lost between the import and the rollback. Do not run bulk user deletion without a verified backup.

Check Roles and Permissions

WordPress manages access through roles and capabilities. A standard installation includes roles such as administrator, editor, author, contributor, and subscriber, while multisite has a separate Super Admin role. Plugins may add their own roles: customer, member, vendor, instructor, affiliate, and others. Before importing, you need to know not only the human-readable role name, but also its technical slug.

For bulk imports, it is safer to assign the minimum role required. If users only need to read protected content, do not give them the editor role. If WooCommerce customers only need the customer role, do not accidentally import them as administrators because of a bad column value. A user role is not a decorative field. It determines what that person can actually do on the site.

Installation and an Initial Check in WordPress

The official WP All Import documentation describes installation through the standard WordPress interface: the plugin file or add-on is uploaded under Plugins › Add New and then activated. For user imports, you need both WP All Import and the User Import Add-On to be active. If you are working with a commercial build, the files come from the Customer Portal, but this guide does not cover purchasing, entering a license key, or bypassing licensing. The focus here is on configuring a product you already have in working order.

How to Confirm the Required Add-On Is Active

After installation, open All Import › New Import and start a new import using a small test file. The import type list should include a Users option. If it does not, the most likely explanation is that only the base WP All Import plugin is active without the User Import Add-On, the add-on file is not installed, or the current administrator does not have permission to access that screen.

Do not start with the full file just to check the interface. First, upload a mini file with one test row and go as far as the type selection step. If Users is available and the preview looks correct, you can continue preparing the import. If the file is not recognized, look at the format, delimiter, encoding, size, or URL accessibility.

Why Import Access Should Not Be Given to Untrusted People

WP All Import works directly with the database and supports PHP function execution within import settings. That flexibility is powerful, but it also raises the access risk. In a standard single-site installation, access is tied to administrative permissions, and the WP All Import documentation makes it clear that untrusted users should not be allowed to manage imports. If a contractor only needs to prepare the CSV, let them prepare the file, but do not let them run the import in the admin area.

In practice, that leads to a simple rule: one responsible administrator prepares the test, verifies the settings, runs the import, and documents the result. If the project is large, involve a second person to review the file and the assigned roles before launch, but do not broaden access to All Import unless there is a real operational need.

Preparing CSV, Excel, or XML Without Losing Data Meaning

WP All Import is flexible about file structure: the official materials point out that your column names do not have to match WordPress field names because you map them manually in the drag-and-drop interface. But flexibility does not mean the file can stay messy. The clearer the source spreadsheet is, the easier it becomes to verify mapping, the unique key, and repeat imports.

Which Fields Should Be Kept in Separate Columns

For a typical user import, it is helpful to keep separate columns for user_login, user_email, first_name, last_name, display_name, role, the external ID, and custom user meta fields. If you are migrating WooCommerce customers, billing and shipping fields are usually added. If you are migrating a membership project, that may also include subscription levels, status, access expiration date, or an external system ID, but only if those fields are actually used by your membership plugin and stored in user meta in a clear way.

Do not combine multiple meanings into one column if you will have to split them apart manually later. For example, a string such as "Jane Carter, editor, paid" looks compact, but it maps poorly to WordPress fields. It is much better to use separate columns: first name, last name, role, membership_status. The plugin can process data, but a clean source is always more reliable than a clever function.

Passwords: When to Transfer a Hash and When to Assign New Access

The official WP All Import documentation explains that when WP All Export and WP All Import are used together, you can migrate hashed WordPress passwords: the original password is never exposed, and the user can still sign in with the old password. That is a strong migration path between WordPress sites. If the file comes from another system and contains plain-text passwords, assess the risk carefully: storing and transferring such files is dangerous, and after the import they should be removed from insecure locations.

For most real-world migrations, it is safer either to transfer hashes from WP All Export or to import users without sending passwords and then trigger the standard password reset flow. If you do use a password column, verify which mode the plugin expects: a WordPress hash or plain text from a third-party system. A single wrong checkbox can leave users unable to log in.

Encoding, Delimiters, and Large Files

If the CSV contains Cyrillic characters, accented letters, quotes, multiline values, or addresses, verify the encoding before uploading it. The official WP All Import documentation specifically calls out encoding and character set problems, as well as file recognition errors. For CSV, the delimiter also needs to be clear: comma, semicolon, pipe, or another character. On the file review step, WP All Import lets you choose the delimiter if auto-detection is not correct.

Large files are best split into a test fragment first and run that way. If the full import stops partway through, it becomes much easier to tell whether the issue comes from the data or from server resources. The documentation on terminated imports recommends lowering records per iteration if the server kills the process, but if even one record will not process, the problem may be related to hosting, error logs, memory, disk space, or a security layer.

Field Mapping: Where a Correct User Profile Takes Shape

The most important screen in WP All Import User Import is the drag-and-drop mapping screen. On the left are the target WordPress user fields and related sections. On the right are elements from the input file. You do not have to rename CSV columns to match WordPress, but you do need to deliberately drag each source value into the correct field. This is where you decide whether company_id becomes an external identifier, whether membership_level goes into user meta, whether role is assigned as the WordPress role, and whether the email becomes the account email.

User Account Info

The account data section contains the basic fields without which a user record does not make sense. The username must be stable, the email must be valid, the role must exist, and the password must be handled in the correct mode. If you are importing users from another platform, do not blindly copy old usernames if they conflict with WordPress rules or with the business rules of the new site.

For migrations where ongoing access must be preserved, email is often used as the main reference point: it is easy for people to understand, unique in WordPress, and convenient to verify. But email can change, while an external ID from a CRM or legacy database is usually more stable. That is why a strong setup often looks like this: email is kept as an account field and verification point, while a separate external_user_id is stored in user meta and, when needed, used as part of the matching logic.

Other User Info and Display Name

First name, last name, display name, website, and bio affect how the user appears in the admin area, author boxes, account pages, and profile-related plugins. Here, accuracy matters just as much as completeness. If the display name is built from first and last name, check how it will appear for a user who has no last name or who represents a company. If the site publicly displays authors, decide in advance what is safest to show: a real name, a brand name, a nickname, or an internal label.

Do not use the display name field as a container for a role, subscription status, or internal ID. Those values belong in user meta. That keeps the interface clean and prevents technical values from leaking onto public pages.

Custom Fields and User Meta

The official product page highlights the ability to import into user fields added by themes and plugins. In WordPress, that usually means user meta. WP All Import can detect custom fields if they already exist in the database for at least one record, but complex plugins may store data in nonstandard ways. In cases like that, you should not promise automatic compatibility with confidence. You need to verify the structure of the specific plugin, check its documentation, or perform a test import on a copy of the site.

For membership sites and WooCommerce in particular, it is important to separate standard fields from meta fields. Address, phone, company, signup source, access level, CRM ID, and newsletter consent may all look like simple strings in CSV, but inside WordPress they may live in different places. Map based on the actual meta key or interface field, not on a nice-looking column label.

Blocking Email Notifications

In the Import Settings step, the official guidance recommends leaving the option to block email notifications enabled during the import so WordPress does not send unwanted messages to imported users. This matters especially during test runs, migrations of private projects, transfers of legacy accounts, or store setup before public launch.

If you do need to notify new users, first verify the email content, sender, mail domain, SPF/DKIM, the mail plugin log, and the password reset workflow. A bulk import should never turn into an untested mass mailing. One test user should receive the email before you allow it to go out to hundreds of people.

The Unique Identifier and Repeat Imports

The unique identifier is the internal link between a row in the input file and the record that WP All Import creates or updates. The official documentation explains that this identifier is configured in Import Settings, can be found using Auto-detect, or can be built manually from elements in the file, and that it must remain unique and stable across future updates.

This is where many users make mistakes. They pick a field that looks unique today but may change tomorrow: display name, subscription price, status, address, company name, or phone number. On the next import, that column no longer matches the previous record, and the system may create a duplicate, skip the row, or update the wrong profile.

When to Trust Auto-detect

Auto-detect is convenient for an initial test and often chooses a workable key. But for user imports, the administrator should understand exactly what was chosen. After clicking it, inspect the value: it should be unique for each row and should not change when the data is updated. If the file contains an external ID, email, or username, verify that the selected key actually reflects your intended logic.

If the import skips records or creates only one row, a common cause is an empty, static, or repeated unique identifier. In that case, go back to the import settings, review the history logs, and define the key manually. For user imports, email or an external ID is often the best starting point, but the right choice depends on your dataset.

Create New and Match Existing in a User Import Context

The WP All Import documentation distinguishes between logic for creating new records that the import will track itself and logic for updating existing records through match existing. In a user import context, this can be explained more simply. If you are uploading a new list of accounts and want that import to manage those users going forward, use create new records with the correct identifier. If the site already has users created manually or by another process and you only need to update specific fields, use a method for matching existing records.

When updating existing users, it is especially important to choose exactly which fields may be updated. The official documentation on manual record matching warns that if you allow everything to update while your field map is incomplete, you may erase or overwrite data you never intended to touch. For repeat imports, only update the fields that are actually populated and meant to change.

Deleting Missing Users

WP All Import can delete or otherwise modify records that are no longer present in the current file. That can make sense for products or listings, but for users it requires maximum caution. A user may be missing from the file not because they should be removed, but because the export is incomplete, a filter behaved incorrectly, the URL returned a truncated file, or the external service temporarily failed to return data.

If you truly need a sync rule of "not in the file means no longer active," it is often safer to change the role, a user meta status, or a membership flag instead of deleting the account entirely, assuming your project supports that. Full user deletion can affect authorship, orders, subscriptions, comments, and activity history. Before enabling that mode, always test it on a site copy and verify what happens to related data.

A Practical Map of the Key Settings After Installation

After activating WP All Import User Import, you do not need to hunt for one separate page of "best settings." For user imports, what matters is the configuration of the specific import: file source, preview, mapping, identifier, update rules, email notifications, advanced settings, and, if the task repeats, scheduling. That chain is what makes an import safe or risky. Below is a practical settings map worth checking before the first real run.

File Source: Upload, URL, Existing File, or Table

At the start of the import, you choose where the file comes from. Manual upload is convenient for migrations and tests, while URL or FTP/SFTP is more appropriate for regular sync jobs. An existing file works well when hosting already receives the export on a schedule. The source choice affects diagnostics. If the file was uploaded manually and the preview looks correct, the issue is more likely in mapping or the identifier. If the source is a URL, extra risks appear: the external service may return an HTML page, access may be restricted, the file may be empty, the structure may have changed, or the extension may not reflect the true format.

For regular user synchronization, do not start with a URL that depends on your browser being manually logged in. WP All Import needs access to the actual file without your session. If the source is protected, use a method supported by the product and your hosting environment, without exposing secrets to untrusted people or putting them into public notes. In this article and any visual planning, we do not reveal secret URLs or keys because they belong to the site's infrastructure.

Review Import File: Do Not Skip This Screen

The file review screen is not just a formality. It shows how many records were found, how the delimiter was detected, which elements are available on the right, and whether it makes sense to move on to mapping. If the data already looks misaligned here, with rows merged together or corrupted Cyrillic text, further configuration will only hide the problem. Fix the source, not the mapping.

For XML and other structured formats, verify which node is selected as the repeating user record. If the selected node is too high in the hierarchy, WP All Import may treat the entire file as one huge record instead of a list of users. If it is too deep, part of the data may be unavailable during mapping. For CSV, inspect 2 or 3 records with different values rather than only the first row, because problems often surface in a row containing a comma inside an address, quotation marks, or an empty column.

Mapping Templates and Repeatable Workflows

If this is not a one-time migration but a repeated process, your mapping setup needs to be reproducible. The column names in the file do not need to match WordPress, but they do need to stay consistent. If an external data provider renames member_id to id one time and then to legacy the next, the import will require manual review every time. In that case, it is better to agree on a stable format or add a preprocessing step.

For an agency that frequently migrates users between sites, it can be helpful to maintain an internal CSV standard: email, login, role, first_name, last_name, external_id, status, phone, organization, membership_level. Then the only per-site changes are the meta keys and update settings. WP All Import does not require this, but it is a practical discipline that lowers the risk of avoidable mistakes.

Advanced Options and Records per Iteration

You do not need to change advanced settings without a reason. But if the import is large or the server is weak, records per iteration becomes important. The official documentation on terminated imports recommends lowering the number of records per iteration when the process stops early. For user imports, this can be especially helpful on sites where creating a user triggers membership plugins, WooCommerce, email hooks, security tools, or custom business logic.

A safe sequence looks like this: first run a small sample with the default settings. If it works, try a larger sample. If the process fails, reduce the batch size, inspect the history logs, and check the server error log. Do not increase the batch just for speed until you know the database, hosting, and third-party plugins can handle the load. Speed matters, but user data integrity matters more.

Core WP All Import User Import Mechanics in the "Input - Workflow - Outcome" Chain

To keep this guide from turning into a generic discussion of CSV files, let us break down several mechanics that matter specifically for WP All Import User Import and similar bulk user creation tasks. Each one has a configuration point, input data, product behavior, visible outcome, verification step, failure symptom, fix, and limitation.

Mechanic 1: Choosing Users as the Target Import Type

The configuration point is in All Import › New Import after the file is uploaded. The user chooses what should be created in WordPress. The input is a file containing user rows. The product behavior is to show user-specific mapping instead of mapping for posts, pages, products, or taxonomy terms. The outcome is that the interface displays account fields, roles, user info, and custom fields related to users.

Verification: on the mapping screen, you see user fields rather than post fields. Failure symptom: you do not see Users in the import type list, or the mapping screen offers post fields. Fix: confirm that the User Import Add-On is active, WP All Import is installed, and the current administrator has sufficient permissions. Limitation: if the add-on is missing, you cannot get a full user import only through base interface settings.

Mechanic 2: Drag-and-Drop Mapping Instead of a Required CSV Structure

The configuration point is the mapping screen. The input is the file elements on the right and the target fields on the left. The product behavior is that the user manually connects a column or XML element to the appropriate WordPress field. The outcome is that even a file with arbitrary headers can be imported, as long as the administrator understands what each column means.

Verification: use preview, compare 2 or 3 rows, and confirm that email goes into the email field, the role goes into the role field, the external ID goes into a meta field, and the password goes into the correct password field. Failure symptom: after import, a value appears in the wrong place or a required field is empty. Fix: go back to mapping, review the headers, meta key, and sample record. Limitation: WP All Import cannot infer the business meaning of a nonstandard column if a person maps it to the wrong field.

Mechanic 3: Blocking Email Notifications During Import

The configuration point is Import Settings. The input is the administrator's decision about whether standard WordPress notifications should be sent when users are created. The product behavior is to block email notifications during the import run so bulk account creation does not become an accidental mailing. The outcome is that users are created without receiving premature email.

Verification: run a test with one email address, then inspect the mail log and your SMTP plugin settings. Failure symptom: emails are sent after the test run. Fix: enable the block, check for third-party plugins that may send their own messages, and repeat the test with a single user. Limitation: blocking default notifications does not always guarantee that every third-party plugin will stay silent, so critical email workflows need separate verification.

Mechanic 4: The Unique Identifier as the Link Between a Row and a Record

The configuration point is Import Settings, where you can use Auto-detect or define the key manually. The input is a stable value from the file: email, username, external ID, or a combination of those. The product behavior is to remember which row corresponds to which created or updated record. The outcome is that a repeat import updates the expected user instead of creating a duplicate.

Verification: run the first test, change one field in that same row, and import again. Failure symptom: a second user is created, only the first record is updated, or records are skipped. Fix: verify that the key is unique, remove empty values, or choose a different identifier. Limitation: one identifier works only within the logic of a specific import; it does not automatically turn multiple imports into a single universal matching system.

Mechanic 5: Selectively Update Fields

The configuration point is the update rules in Import Settings, especially when using match existing. The input is the list of fields that may be updated during a rerun. The product behavior is to update only the selected data and leave everything else untouched. The outcome is that you can change, for example, the role and phone number without overwriting the display name, email, or profile bio.

Verification: on a test record, manually change one field ahead of time, then import a file that updates a different field. If the manual value stays intact, the setting is working. Failure symptom: empty values from the CSV wipe out existing data. Fix: narrow the update settings down to the specific mapped fields. Limitation: if you allow a field to be updated and the file contains an empty value, the product may correctly write that empty value. That is why empty source columns need to be handled deliberately.

Mechanic 6: Function Editor for Small Data Normalization

The configuration point is the Function Editor in WP All Import or a function call within an import field. The input is a value from a column, such as a phone number or an external ID string. The product behavior is to run a PHP function during the import and save the transformed value. The outcome is that the value reaches WordPress already cleaned up or normalized.

Verification: Preview should show the expected function output for a specific record. Failure symptom: the import crashes because of a PHP error, the value becomes empty, or the format is broken. Fix: simplify the function, check quotes, revert to the original mapping without the function, or preprocess the CSV outside WordPress. Limitation: the Function Editor should not become a place for a complex migration system, especially if the code affects roles, passwords, or access rights.

Practical Example: Migrating Members of a Private Area

Consider a concrete example. You have an old site with members of a private section and need to move them to a new WordPress site, create accounts, preserve email, first name, last name, the subscriber role, an external ID from the old system, and the access level in user meta. Passwords will not be transferred in plain text. After the import, users should appear under Users, and the administrator should be able to see the external ID and access level in the profile or in the plugin that reads those meta keys.

Goal

Create a controlled import with no mass email and no risk of overwriting existing administrators. The test file contains 10 rows, and the full file contains all member records. The unique key is the external ID because it is more stable than the display name and does not depend on email potentially changing.

Preparation

Start by creating a database backup and a site copy for testing. In the spreadsheet, prepare columns for external_user_id, user_email, user_login, first_name, last_name, role, and access_level. For user_login, generate a safe value in advance from the email or external ID so you do not import accidental spaces or Cyrillic internal codes. For the role, use the subscriber slug if the private area checks user meta rather than an editor-level role.

If the membership plugin requires specific meta keys, verify them in that plugin's documentation or by inspecting a test user. You cannot put "access level" into an arbitrary field and expect another plugin to understand it automatically. WP All Import will move the value wherever you map it, but the membership plugin's business logic must be confirmed separately.

Steps in WP All Import

1. Open All Import › New Import and upload the test CSV.
2. Select the Users import type and proceed to the file review step.
3. Confirm that the records were detected correctly: columns are not merged, Cyrillic text is readable, and the number of test rows matches.
4. On the mapping screen, map the email, username, first name, last name, and role to the user fields.
5. Open the custom fields section and map external_user_id and access_level to the required meta keys.
6. In Import Settings, define the unique identifier based on external_user_id or verify the Auto-detect result.
7. Leave email notification blocking enabled unless you are ready to send email.
8. Run the test import and verify the users in the admin area.

Verifying the Outcome

After the test run, open Users and find the imported users by email. Check the role, display name, profile fields, and meta values if they are visible in the interface. Then rerun the import after changing the access_level for one test user. If the key and update settings are configured correctly, the existing record will be updated instead of creating a duplicate.

Also test user sign-in separately. If passwords were not imported, test the standard password reset flow. If hashed passwords were transferred from WP All Export, test login on a sample account and make sure the password is not stored in plain text in your working CSV.

A Common Pitfall with Existing Administrators

Never enable a mode that can update existing users without an exact filter if the file contains an administrator email or a technical account. For the first verification, use a separate test user email address. If you need to update users who already exist on the site, choose manual record matching and limit the list of fields that may be updated. Do not update the administrator role from an external file unless that is the explicit goal of the migration and has been tested separately.

Meta Fields, WooCommerce Customers, and Links to Other Data

The strength of WP All Import User Import is not only in creating accounts, but also in handling additional data. The official materials mention importing user meta and the ability to connect users to other data, such as orders, real estate listings, or other entities. In practice, this is useful, but it requires discipline: the relationship should be built on a stable key, not on an incidental name.

Custom User Fields from Themes and Plugins

Many plugins add fields to the user profile. These may include job title, phone number, company, address, membership level, CRM ID, city, newsletter consent, or an internal status. WP All Import can populate custom fields, but you need to understand exactly how the target plugin stores that data. Simple user meta usually imports in a straightforward way. Complex structures, serialized values, separate plugin tables, or linked records may require documentation, an add-on, an API, or manual verification.

If the exact structure is not confirmed, do not tell your team that "the plugin will understand everything." First, create one user manually through the target interface, inspect which fields appear, run an export or a diagnostic check, then import a test row and compare the result. That takes longer than guessing a meta key, but it is far cheaper than cleaning up thousands of broken profiles.

WooCommerce Customers as WordPress Users

A WooCommerce customer in WordPress is a user with a role and a set of customer meta fields: billing and shipping details, phone number, address, city, country, and other values. The WP All Import documentation for WooCommerce customer imports makes it clear that customer fields differ from ordinary user fields. If your task is specifically to migrate buyers, use the documentation for WooCommerce customers rather than relying only on general user import guidance.

The responsibility boundary here is straightforward: WP All Import moves the data into WordPress, WooCommerce reads its fields from the expected meta keys, and the connection to orders depends on how the orders are imported and matched to users. If you import orders before users, or without the correct link, you may need extra reconciliation later. That is why store migrations usually plan the sequence carefully: users or customers first, then orders, then verification of the customer profile and purchase history.

Preserving Old User IDs

By default, WordPress assigns new IDs to new users. The official WP All Import documentation explains that trying to preserve old IDs is possible through custom code and the API, but only if the desired ID is still unused. If that ID is already taken, WordPress will assign a new one. This is an important limitation: you cannot build a critical migration plan on the assumption that every old ID will be preserved.

A more resilient approach is to store the old ID in a separate meta key such as legacy_user_id and use it to link related imports when the target processes support that. If old records, orders, or objects refer specifically to the numeric ID, first verify whether they can instead be matched by email, username, or an external ID. In a complex migration, preserving IDs may be a separate technical stage, not a checkbox in a standard import.

Reruns, Scheduling, and Ongoing Synchronization

One of the practical use cases for WP All Import User Import is not a one-time migration, but regular user updates from an external file. For example, an HR system may publish a CSV of employees, an LMS may provide a roster of learners, a CRM may update a customer segment, and WordPress needs to keep roles and meta fields current. In that kind of workflow, the unique key, update rules, and schedule become especially important.

What Can Be Automated

The WP All Import documentation describes both manual cron jobs and the optional Automatic Scheduling Service. With manual scheduling, two URLs are used: the trigger starts the import on schedule, and the processing URL runs frequently and keeps processing until the task is complete. That approach exists because a large import may not finish in a single request, and hosting environments often limit execution time.

For user imports, automation is especially helpful when the file comes from a stable source and its structure does not change. If the file structure changes often, automatic runs become risky: WP All Import may no longer find the expected elements, XPath, or columns, and the next import may start skipping records or updating the wrong users. That is why automation should come only after a period of manual verification.

How to Set Up Safe Recurring Updates

First, run the import manually using a test file. Then run it again after changing one field value and confirm that the correct record is updated. After that, enable a limited set of fields for updates. For example, for employee synchronization you might update department, phone, active_status, and the role, but leave email, username, and display name untouched if those are edited directly on the site.

If the source may occasionally return an empty file, do not enable deletion of missing users. It is safer to add a separate status such as "not_in_feed" or stop the import when the record count looks suspiciously low. Conceptually, think of this as a control gate: the file is loaded, the record count looks reasonable, the keys are unique, and only then does the update run.

What to Log After an Automated Import

After each recurring run, review the history logs under All Import › Manage Imports: how many records were created, how many were updated, how many were skipped, and whether there were file, memory, or access errors. For critical user datasets, it is useful to keep a separate control report: run date, file source, row count, number of new accounts, number of updates, number of suspicious rows, and a link to the backup taken before a major change.

If the import has slowed down, the official documentation on slow imports recommends checking server resources, database size, and heavy external operations. User imports usually do not involve image downloads, but they do involve database work, user meta, and possibly third-party plugins, so a large membership site or store can still become resource-bound.

A Small Safe Adjustment Through the Function Editor

WP All Import supports PHP functions inside import settings and includes a dedicated Function Editor. That is a documented product feature, but it should be used with restraint. Do not build complex business logic directly into the import if the problem can be solved by preparing the CSV first. A good use case is a small, reversible normalization step: remove spaces from a phone number, convert an external ID to the expected format, or provide a safe default value.

Below is a small custom adaptation based on WP All Import's documented ability to call custom PHP functions. It strips spaces, parentheses, and dashes from a phone number while preserving digits and the plus sign. This makes sense if you are importing the phone number into user meta or WooCommerce billing phone and want to store it in a consistent format. Before using it, verify a test row in Preview and do not apply the function to fields where the original spacing or formatting matters.

function cb_clean_import_phone( $value = '' ) {
    $value = trim( (string) $value );
    return preg_replace( '/[^0-9+]/', '', $value );
}

In the import field, you can call the function using the pattern described in the WP All Import documentation for inline PHP, replacing the element name with the actual column from your file:

[cb_clean_import_phone({billing_phone[1]})]

The verification is simple: in Preview, compare the original value with the transformed one. After the test import, open the user profile or customer record and confirm that the phone number was saved in the correct meta field. Rolling it back is simple too: remove the function call from the mapped field, restore the original column value, and rerun the import on a test record. If you are not sure how the target plugin uses phone numbers, leave the format unchanged and normalize the data in a separate worksheet before the import.

Verifying Results After the Import

A successful progress bar does not automatically mean a successful migration. After importing users, you need to verify not only the number of created records, but also the meaning of the outcome: who can log in, which role they received, which fields were filled, whether duplicates appeared, whether emails were sent, and whether links to orders or protected content are still intact.

Control Sample

Take several records from the file and locate them in WordPress. Include different cases: a new user, an existing user, a user with a custom role, a user with an empty optional field, and a user with membership data if applicable. Compare the profile values with the source row. If a field is not visible in the interface, inspect it using a tool you trust, but do not edit the database directly unless it is necessary.

For updates to existing users, verify that fields you did not allow to update remain unchanged. For example, if the task was only to update access_level, the email and display name should stay the same. This is the best way to catch overly broad update settings before the full run.

Verifying Login and Access

Create a test user or use a preapproved account. Test logging into WordPress or the customer area. Make sure the role behaves as expected: a subscriber should not see administrative screens, an editor should only see the intended sections, a customer should land in the WooCommerce account area, and a membership user should receive the correct access level. If the project uses page caching, end the session, open a private window, and check the public side of the site without an administrative login.

If a user cannot log in, do not immediately change the entire import. Start by checking a single record: email, username, password mode, role, user status, password reset emails, and security plugins. Bulk changes made before you understand the cause often create a second problem.

Checking the Import History

History logs are available under All Import › Manage Imports. They help you understand how many records were created, updated, or skipped, where an error occurred, and at what stage the process stopped. For repeat imports, this log is especially important: if 300 users were updated yesterday and only 3 today, the external file may have changed, a filter may have cut off the data, or the unique identifier may have become empty.

Make it a habit to save a short note after major imports: the source, the number of rows, the number of users created, the number updated, which fields were updated, and who verified the result. That discipline pays off quickly when, a week later, you need to explain why a user's role changed or why some accounts never appeared.

Troubleshooting Common User Import Problems

Most WP All Import User Import issues come back to the file itself, the unique identifier, update rules, server resources, permissions, or unrealistic expectations about third-party user meta. Below is a practical troubleshooting approach without panic and without destructive actions.

The File Will Not Upload or You See an Import File Error

Symptom: WP All Import does not show a preview, reports a file problem, cannot download the URL, or detects the wrong data type. Possible causes include a file that is too large for PHP limits, a URL that does not return a real CSV/XML/JSON file, a changed file structure, encoding conflicts, a missing file extension, or a server-level block.

What to check: open the URL in a browser and confirm that it returns the actual file, not an HTML page, a login prompt, or an error page. For a local CSV, check the delimiter, encoding, the first row, and quotation marks in multiline values. If the problem appears only with the large file, compare it with a smaller sample. For URL uploads without an extension, the official WP All Import documentation suggests using a fake filename after #/ to help determine the file type.

How to fix it: reduce the test file size, correct the delimiter, convert the CSV to a clear encoding, check hosting limits such as upload_max_filesize, post_max_size, and memory_limit, or ask hosting support to inspect the server error log. When to stop and roll back: if the preview shows merged columns or the wrong record count, do not continue with mapping until the file is being parsed correctly.

The Import Creates Duplicates or Updates the Wrong Users

Symptom: after a rerun, new accounts appear instead of updating existing ones, only the first record gets updated, or some users are skipped as duplicates. The most likely cause is an incorrect unique identifier, a flawed match existing setup, or a repeated key value.

What to check: open Import Settings and see what is selected as the Unique Identifier. The value must be unique for every row and stable in the next file. Check for empty external IDs, duplicate email addresses, or a static value that accidentally ended up in every row. In the history logs, review which records were skipped or updated.

How to fix it: define the identifier manually using the email, username, or external ID. For updates to existing users, configure match existing using a field that truly exists both in the file and on the site. Start by running a single test record. When to roll back: if the full import has already created duplicates, do not try to fix it with another full import. First determine which records were created incorrectly, then restore from backup or remove the test set in a safe way.

Emails Went Out to Users Too Early

Symptom: users receive new account emails even though the migration is still being tested or the site is not ready. Possible causes include the email notification blocking option being turned off, third-party email plugins being active, or the import process creating users in a way that triggers WordPress notifications.

What to check: in Import Settings, find the option for blocking email notifications and confirm that it is enabled for both test runs and migration runs. Check the email log if the site uses an SMTP plugin. Also confirm whether a membership plugin or WooCommerce sends its own message when a user is created or a role changes.

How to fix it: enable notification blocking, test with a single user, and only then run the full import. If a message needs to go out later, send it through a separate controlled process. When to roll back: if the emails have already been sent, restoring the database will not undo that, so it is better to prepare a user-facing explanation and stop any further mailing.

Custom Fields Are Not Visible After Import

Symptom: the import completes, the base users exist, but the membership level, billing phone, CRM ID, or another meta field does not appear in the expected interface. Possible causes include the wrong meta key, a complex storage structure, a field belonging to another plugin, the user record not meeting display conditions, or the value being imported as a string when the plugin expects another format.

What to check: create one user manually through the target plugin and compare which fields it creates. Review the documentation for the plugin that is supposed to read the data. If WP All Import auto-detected a custom field, make sure it is the correct key and not a similar internal field. For WooCommerce customers, check the separate documentation for customer fields.

How to fix it: map the data to the correct meta key, use the value format expected by the target plugin, and test the result on a single record. When to roll back: if you imported values into the wrong meta keys at scale, first save a list of the affected fields, then remove or correct them on a copy of the site rather than directly in production without a plan.

The Import Stops, Times Out, or Runs Too Slowly

Symptom: the process does not finish, returns a 503, 504, timeout, or a terminated import message. The WP All Import documentation recommends starting by lowering records per iteration and reviewing server error logs. Possible causes include hosting limits, a large database, insufficient memory, a security module, a Cloudflare timeout, or heavy processing by a third-party plugin.

What to check: run a small sample. If that works, the issue is probably related to size or resources. If even one record fails, look for a data error, PHP issue, permission problem, or plugin conflict. Review the history logs and ask your hosting provider to inspect the error log at the time of the run.

How to fix it: lower records per iteration, run the import during a less busy time, disable unnecessary heavy operations, verify server resources, and use manual cron with trigger and processing URLs for recurring jobs. When to roll back: if the import partially created users and then stopped, do not rerun the full file until you understand the identifier and update settings. Otherwise, you may create duplicates.

Users Cannot Log In After Migration

Symptom: the accounts appear in WordPress, but login fails. Possible causes include the wrong password mode, a password being imported as a hash when the system expected plain text, plain text being handled as a hash, the username changing during import, the email not matching, a security plugin blocking access, or the user receiving a role without access to the intended area.

What to check: one test account, the password mode, email, username, role, password reset ability, the email log, and security plugin restrictions. If the password was transferred from WP All Export as a hash, confirm that it is mapped to the correct field and was not altered by the spreadsheet. If the source is not WordPress, do not promise that the old password will still work unless that has been verified separately.

How to fix it: in most cases, it is safer to send the standard password reset after migration than to store and import plain-text passwords. When to roll back: if the import wrote incorrect passwords at scale, restore the backup or run a controlled reimport of the password field for a test group first, then for the full database.

Official Video on User Import

In the WP All Import documentation, the exact video How to Import WordPress Users is referenced alongside the materials on preserving old user IDs. It works well as a visual companion to the sections on All Import › New Import, choosing Users, mapping, and Import Settings. Use the video not instead of testing, but as a quick way to see the screen flow before running your own test.

Questions That Usually Come Up Before Launch

Do I Need a Separate User Import Add-On?

Yes. To choose the Users import type in WP All Import, you need the User Import Add-On to be active alongside WP All Import. If All Import › New Import does not show a Users option, first check that the correct add-on is installed and activated before troubleshooting the CSV.

Can I Import Users from Excel Without Converting to CSV?

The official WP All Import materials describe support for CSV, Excel, XML, and Google Sheets in modern import workflows. But for complex migrations, CSV is often easier to control: you can clearly see the headers, delimiter, encoding, and test rows. If the Excel file causes errors, save a test sample as CSV and see whether the problem goes away.

Which Unique Identifier Should I Choose for Users?

Choose a value that is unique for every row and does not change on repeat imports. That is often an email address, a username, or an external ID. A display name, role, phone number, status, or address is not a stable key. If the file contains an external ID from a legacy system, it is often useful to store it in user meta and use it as the foundation of your migration logic.

Can I Keep Old Passwords?

When migrating between WordPress sites using WP All Export and WP All Import, you can transfer hashed passwords so users can continue signing in with their old passwords without exposing the original string. For third-party systems, it depends on the format. If passwords are stored in plain text, assess the risk carefully and, in most cases, prefer the standard password reset flow after migration.

Why Are the Membership Plugin Fields Missing After Import?

Because a custom field in a CSV is not automatically the same thing as a real field in the target plugin. You need to know the meta key, the value format, and the conditions under which the plugin displays the data. Create a test user manually, inspect the field structure, and only then map it in WP All Import.

Should I Enable Deletion for Users Missing from the File?

Only after testing on a copy of the site, and only if you fully understand the consequences. For users, it is usually safer to change a status, role, or user meta value first rather than deleting the account completely. Full deletion can affect authorship, orders, subscriptions, and activity history.

Can I Give WP All Import Access to an Editor or Client?

The official WP All Import documentation warns that import access should only be granted to trusted users. The plugin modifies the database and supports code execution in settings. It is better to let an editor or client prepare the CSV while leaving the actual import run to an administrator.

What Should I Do If the Import Stops Halfway Through?

Do not blindly rerun the full file. First review the history logs, check which records were created, reduce records per iteration, inspect the server error log, and make sure the unique identifier will not create duplicates on the next run. If you have a backup from before the import, keep it ready until the investigation is complete.

When WP All Import User Import Is the Right Choice

WP All Import User Import is worth using when user data is important to how the site operates and the manual admin workflow is no longer enough: account migrations, membership database transfers, role updates, external list synchronization, user meta imports, or preparing WooCommerce customers. Its strength lies in the controlled chain of "data source - preview - mapping - unique identifier - update settings - run - history logs - result verification."

Before the real run, follow a short and safe path: prepare a test CSV, verify roles and meta keys, enable email notification blocking, define a stable unique identifier, run a test with 5 to 20 rows, and check Users, login, user meta, and the import log. Only then should you move on to the full file. If the test confirms that the plugin fits your use case, you can download WP All Import User Import and test it on a site copy or staging environment.

If all you need is a simple one-time CSV import with no meta fields, or if you do not have access to backups, staging, and role verification, start with a narrower tool or a manual import of a small group. Bulk user import should not be a quick experiment. It should be a careful procedure. When handled that way, WP All Import User Import can save hours of manual work while preserving control over access, data integrity, and repeatability.