Paid Memberships Pro Import Users from CSV - WordPress Plugin

Guide to Migrating Members with Paid Memberships Pro Import Users from CSV

This guide to Paid Memberships Pro Import Users from CSV will help you prepare a safe CSV file, map its columns to WordPress data and membership levels, run a test member migration, and verify that accounts, permissions, and subscriptions appear as expected. We will focus on a practical migration path: from auditing the old database to checking several real member accounts, without confusing a proper migration with simply uploading email addresses.

This add-on is useful when a restricted-content site receives not one new visitor at a time, but an established list of people: club members, students, access purchasers, subscribers from an older platform, or employees of a partner organization. In that situation, creating accounts manually creates two problems. First, someone can easily receive the wrong level of access. Second, the site owner loses the connection between the original spreadsheet and what WordPress now displays. CSV import provides a controlled bridge between those states, but that bridge is reliable only when the headers are accurate, the mapping rules are clear, and the first run is small.

The key benefit of Paid Memberships Pro Import Users from CSV is that it works with more than standard user fields. It can use Paid Memberships Pro membership data, so a single row can connect an account to a numeric membership level ID, dates, payment details, and custom metadata. That does not mean every row should include every available field. On the contrary, a reliable file includes only values whose purpose you can explain and then verify. For an initial migration, the most important values are a username or email address, a membership level ID, and a pre-approved set of custom fields.

When Importing Members Actually Solves the Problem

Not every spreadsheet requires this add-on. If you only want to create a few test users without membership levels, WordPress's built-in user creation may be faster and easier to understand. If the task is to migrate orders, payments, courses, or profiles with an unclear structure in bulk, first separate account data from external-system data. The importer becomes especially valuable when a list must create or update users and assign them a specific Paid Memberships Pro membership state at the same time.

A common use case is launching a new version of a restricted site. The old system contains a spreadsheet with email addresses, names, access levels, and expiration dates. The new WordPress site already has membership levels, account pages, and content restrictions configured. The import does not automatically create these levels from text names: it receives membership_id, which is the numeric identifier of an existing level. For that reason, the spreadsheet cannot be prepared independently of the new site. First create and test the levels in Paid Memberships Pro, then record their IDs in the working sheet, and only afterward map the original statuses to membership_id values.

Another common case is cleaning up and updating an existing database. For example, an editorial team may want to add a contract number, training group, or consent indicator to the profiles of people with active access. If a CSV value should become user metadata, the column header must match the required meta_key. It is useful to split this goal into two passes: first update profile data using a stable matching key, then adjust memberships with a separate, short file. This order reduces the chance that a duplicate row will overwrite a name, role, or metadata because of an accidentally blank cell.

Who This Approach Is For

Importing is appropriate for a site owner responsible for the member database who can validate the data source; for a developer moving a site to new infrastructure; for an administrator of an educational project, club, or association; or for an agency that receives an approved spreadsheet from a client. The common factor is simple: someone is responsible for the source list, and the migration can first be performed on a site copy or a small sample. Even with a limited number of rows, this approach is useful when membership level affects access to materials, the account area, group functionality, or recurring notifications.

It is less suitable when "a spreadsheet was found, but nobody knows what its fields mean." Do not use an import to guess the structure of an old database, recover unknown passwords, or change roles in bulk without an audit. Passwords in a CSV file are especially sensitive. The developer's documentation specifically advises against importing passwords. For new users, it is safer to send an email with a password setup link than to store secrets in a spreadsheet. You also should not use a membership level as a substitute for a WordPress role: for a standard member, the subscriber role is usually sufficient, while editorial and administrative permissions should not be added to the working file "just in case."

Three Outcomes to Define Before Opening the CSV

Before editing the first cell, define outcomes that can be verified without guesswork. The first outcome is the rule used to find an existing person. The documentation lists user_id, user_login, and user_email for updates. Choose one primary key and clean up its values: email addresses should not contain extra spaces, and usernames should not change between exports. The second outcome is the membership each segment should receive. Mapping "premium" from an old spreadsheet to a specific membership_id must be approved separately, not left to the person uploading the file. The third outcome is which fields will be available after migration and where you will see them: on the user profile, in the member list, in the account area, or in a later export.

Practical principle: an import is not the moment you upload a file; it is a repeatable procedure. If you cannot explain where a row came from, which key maps it, and where the final state will be checked, that row is not ready to process.

Data Map: User, Membership, and Subscription Are Separate Layers

The most useful preparation is to stop treating a CSV row as a single "profile." It can contain three distinct layers of data. The first is the standard WordPress account: username, email address, name, display name, and role. The second is the Paid Memberships Pro membership state: level, payment settings, status, and start or end date. The third contains details of an external recurring subscription: a subscription ID at the payment provider, the gateway in use, and sometimes a customer ID. These layers meet in a single row, but they are checked in different parts of the admin area and carry different risks if something goes wrong.

If you are migrating only free access or an old list with a fixed term, an account, membership_id, and a carefully entered date may be enough. If you are migrating active recurring charges, you cannot stop at a level and amount. To continue or update such a subscription, the documentation requires membership_subscription_transaction_id and membership_gateway; without that connection, the payment mechanism cannot associate a future event with the correct member. Active recurring subscriptions should therefore be handled as a separate working task with additional verification, rather than mixed with a standard migration of free members.

This separation also helps when speaking with a client or colleague. Instead of the vague promise to "migrate everyone," you can agree on specific actions: "create accounts," "assign levels," and "link only confirmed active subscriptions." Each item then has its own file, test group, and acceptance criteria. Never consider a migration successful merely because the number of users in WordPress has increased. Success means that selected test users can sign in, have the expected level, and can or cannot view protected content according to the intended rule.

Preparing WordPress and Installing the Add-On Safely

Before working with the spreadsheet, make sure Paid Memberships Pro itself is installed, active, and has the levels that will be assigned to members. The add-on does not replace the core plugin and should not be the first part of your site setup. It is best to test membership levels, account pages, content restriction rules, and the user sign-in process in advance with one manually created test member. Then, if an import fails, you can distinguish a data problem from a problem with the site itself.

Create a site copy or working environment where you are allowed to process an anonymized sample. A backup is not just a formality; it is a clear rollback point. Before making a bulk change, you must have a way to restore the database and files if an incorrect column updates existing records. In the working environment, use several test addresses that do not belong to real customers. This lets you see what the email, sign-in flow, account area, and restricted content look like without sending notifications to real people.

The next step is to create a short decision log. Five lines are enough: the source filename, date received, person responsible for the data, selected matching key, and list of columns approved for import. It is also useful to record the mapping between old statuses and levels on the new site. For example, an old status such as "member through the end of the season" may map to one numeric ID, while "mentor" maps to another. Do not put passwords, full payment identifiers, or other secrets in this log. Its purpose is to give the team a repeatable process, not to create a second copy of sensitive data.

What to Check in the Core Plugin Before Uploading

Open the Paid Memberships Pro membership levels section and review not only the names but also the numeric IDs. The CSV uses membership_id, not the visible level name. If levels were created in a different order on the test site, their IDs may differ from those on the production site. This is one of the most frustrating error types: the import finishes, but people receive an existing yet incorrect level of access. Add a check for two or three levels by both ID and actual content access to your checklist.

Check member fields if you plan to migrate additional information. Paid Memberships Pro custom fields have their own keys, and these keys may be used as CSV column headers. Record the exact key, not a translation or a human-readable form label. For nonstandard data used by another site component, first determine exactly where that component stores the value. You cannot assume that a header such as "Company" will automatically become the correct metadata field. A separate two-row test file will show whether the value appears where expected and does not damage the profile.

Finally, check the email workflow. The import screen includes a new-member notification setting that sends the new user an account name and a password setup link. For the first technical test, it is sensible to turn off delivery or send the test only to team addresses. Once verification succeeds, decide who should receive the message and when, whether sign-in instructions will be published, and where questions should be directed. A bulk email sent before access truly works creates more support work than the migration itself.

Installation and a First Run Without Unnecessary Actions

Once preparation is complete, install the add-on using the method available through your license and infrastructure: through the Paid Memberships Pro add-ons section or through the standard WordPress plugins screen with an archive you have already obtained. Activate it after installation and make sure the Users > Import Members path appears in the Users menu. Do not begin by uploading the full spreadsheet. First open the import page and download the sample CSV available there. That file does not need to include every possible field, but it shows the expected header format and helps you understand the mapping process.

On the import page, choose the file and read the settings before pressing the button. Notify Members controls notifications for new accounts. Update Existing Users determines whether the importer should update a user found by username or email. Skip Existing Members is useful when you are concerned about duplicate records with the same active level: this mode does not change the level for matching existing members. It is not a universal safety shield. It does not fix an incorrect matching key, make an empty column safe, or replace a file comparison.

For large lists, the interface may offer batch processing through AJAX. Its purpose is not to make an import fast at any cost, but to reduce the risk that a browser or server interrupts one long operation. Even with batch processing, the administrator remains responsible for order and control: keep an unchanged copy of the source CSV, prepare a separate file containing a test subset, and record exactly which file version was processed. Do not edit the spreadsheet in several cloud documents at the same time during import. An unpredictable row change between the test and production run destroys repeatability.

Minimum Contents of a Test Sample

A good first file includes five to ten rows selected to reflect future data types: one new user, one existing user, one member with an additional field, one person with time-limited access, and, only when genuinely needed, a separate row with active subscription data. Do not include anyone with an administrative role in the test. Every row should have a known expected outcome. For example, a new test user should receive the "Basic" level, an existing user should retain their username and receive an updated profile field, and a time-limited record should show the specified end date.

Before running the import, ask another person to review the file. This check catches simple but expensive mistakes: the membership-level column has shifted by one position, an email address contains a space, a decimal value uses a thousands separator, or a translated label was used as a header instead of a key. Import tasks depend on format as well as data. The file must be a true CSV with one header row and no hidden spreadsheet worksheets. If the source came from spreadsheet software, export a separate copy and make sure delimiters and encoding have not split one value into multiple columns.

How a Test Run Works: From File to Mapping Screen

Once the test file is uploaded, the add-on should not be a black box. After you select the file, it shows a mapping stage: each column can be connected to a WordPress or Paid Memberships Pro field, while an unnecessary column can be set to Skip. This is where the data's fate is decided. A column name in the source spreadsheet may be convenient for an accountant or manager, but on the mapping screen you need to select the field that matches its meaning. Do not map a "Status" column to a membership level until you have shown that its values genuinely represent levels on the new site.

Work through the mapping from left to right and state the answer to this question for every column: "What will appear in WordPress after confirmation?" For user_email, the answer is the address and a possible lookup key for an existing user. For membership_id, it is assignment of an existing level. For a custom meta_key, it is a value in user metadata. If you have no answer, choose Skip. Importing optional, unclear information adds no value and makes rollback more difficult.

Stage checkpoint: by the time you click Confirm Mapping and Import, you should have more than hope for a "sensible import." You should have a short table of expectations for every test row. After completion, you will compare the actual outcome against it.

How to Build a CSV File You Can Explain and Verify

A high-quality CSV file has two qualities: its structure is clear from the first row, and every subsequent row describes one specific expected outcome. Do not start by exporting "all columns just in case." That kind of export often includes internal technical values, old statuses, duplicate fields, and blank columns. First make a working copy of the source spreadsheet, then create a separate import file with a minimal set of headers. The original must remain unchanged so you can return to it if data is questioned.

For standard member creation, user_login or user_email is usually sufficient, along with membership_id if the person needs a level immediately. The username must be unique. An email address must also be unique for the account and works well as an understandable key when migrating from an older system. If you are updating existing users, the documentation permits matching by user_id, user_login, or user_email. Do not use different approaches within one file without a clear plan: finding one person by email and another by username makes verification and troubleshooting harder.

Standard WordPress fields make future records readable: first_name, last_name, display_name, and role. However, add them only when the source is reliable, not by default. A blank display_name in an old export should not accidentally replace the existing member's carefully formatted name. For newly created standard members, it is sensible to retain the default role or use subscriber when that aligns with site policy. Paid Memberships Pro membership and a WordPress role manage different types of access. Giving someone an editor role because they receive a paid level is unnecessary and unsafe.

Membership Level and Date Columns

The key field for assigning membership is membership_id. It contains the identifier, not the visible name. If the file needs to describe an initial payment, recurring payment amount, cycle, and cycle limit, separate fields are available: membership_initial_payment, membership_billing_amount, membership_cycle_number, membership_cycle_period, and membership_billing_limit. Use them only when reliable data is available. You must not invent billing frequency from the name of an old plan, because that information affects the displayed membership and the user's expectations.

For time-limited records, you may need membership_startdate, membership_enddate, and membership_timestamp. Dates should use one consistent format: YYYY-MM-DD. Take special care with an end date: it should not be set for lifetime access or an active recurring subscription. Also remember that a value of 0 in membership_id is used to cancel an existing membership. This capability is useful only for a specifically approved cleanup operation, not as a way to indicate "we do not know the level" or an empty cell.

Rather than mixing different account types in one sheet, it is more practical to create clear segments: new members with a free level, active members with a fixed term, existing users whose profiles need updating, and people with active subscriptions. The same header template can be reused, but the permitted values and verification steps differ by segment. For fixed-term access, the end date and a real check of restrictions afterward matter most. For an active subscription, the payment-provider connection and the appearance of a record in the subscriptions list are more important.

Additional Fields and Metadata Without the Chaos

The add-on treats recognized additional columns as user metadata. This is convenient when you need to migrate a contract number, training group, CRM identifier, or another verified field. But convenience does not eliminate the need for planning. First create or locate the required field on the site, determine its exact meta_key, and then use that key as the CSV header. A human-readable label may be in Russian while the key is in English with underscores; they must not be confused.

If the field was created through Paid Memberships Pro User Fields, verify not only that the value is saved but also where it appears. Some fields are visible in the admin area, others appear in a profile or checkout page, and some exist only for internal processing. After the test import, open the user profile, locate the value, sign in with the test account, and make sure confidential information has not accidentally appeared on the public site. A CSV file does not know which fields should be hidden. That is controlled by field settings and the site theme.

Do not put arrays, complex JSON objects, spreadsheet formulas, or custom notes with unknown delimiters into a CSV until you have tested that format separately. A simple text string, number, or short code is more reliable. If one person has multiple values, determine whether the specific field expects repeated rows, a special format, or a separate entity in another plugin. When that is not confirmed, leave the complex portion outside the bulk import and handle it through a safe, separate process.

A Small Training Example

Imagine a private library with two levels: "Reader" and "Curator." Their numeric IDs have already been recorded in the working log on the new site. For new readers, the file includes user_email, user_login, first_name, last_name, membership_id, and library_card. The library_card column exists on the site as metadata and is used by staff when assisting a member. A curator receives a different pre-verified membership_id, but not a WordPress editor role. This keeps restricted-content access separate from the ability to edit pages.

user_email,user_login,first_name,last_name,membership_id,library_card
This email address is being protected from spambots. You need JavaScript enabled to view it.,reader.demo,Jane,Carter,12,LB-00418
This email address is being protected from spambots. You need JavaScript enabled to view it.,curator.demo,Emily,Wilson,18,LB-00419

This example is illustrative. Before a real upload, replace the numeric values with the level IDs for your site and use your own test addresses. Do not copy the example into a working spreadsheet without checking its encoding and delimiter. After import, find the first record by email, open its profile, and confirm that it has the correct level, the name was retained, the library_card field appeared, and the public site does not expose it unnecessarily.

Column Mapping: Do Not Trust Similar Names

The mapping screen exists precisely because source column names rarely match internal keys exactly. Choose a target field for every column based on the intended outcome, not on a similar-sounding label. "Payment Date" and membership start date can describe different events. "Customer Status" may be a commercial label rather than a membership_status value. "Plan" often stores a marketing name, while the importer needs a level number. A questionable column should be set to Skip until the data owner confirms its meaning.

A useful technique is to add a temporary "expected outcome" column to the working spreadsheet, then remove it before export or skip it on the mapping screen. It can contain clear notes such as "create reader," "update card number," "do not change level," or "do not upload until subscription is verified." This column is not intended for the WordPress database, but it helps a reviewer see the purpose of every test row. If the expected outcome cannot be stated briefly, the file is not ready.

After mapping, do not rush to confirm the import even if every field looks familiar. Take a screenshot or make a text record of the selected mappings in your log. If you run the process again a week later or hand it off to another specialist, that information will explain why one column was skipped and another became metadata. It also protects against the temptation to change mappings by eye after some people have already received access.

What Changes After You Confirm the Import

After you run Confirm Mapping and Import, the add-on processes the rows and applies the selected rules. For a new person, it creates a WordPress account if the data allows one to be created. For an existing user that was found, update mode uses the selected matching key. If a level is assigned, Paid Memberships Pro creates or updates the membership state. Additional columns become user metadata. In other words, a row is not simply added to a list: it affects several connected states, which is why the outcome must be checked in multiple places.

A minimum post-test review includes the user list, the member profile in Paid Memberships Pro, the account area after sign-in, and one protected page. When updating an existing user, also compare the original and final name, role, and critical metadata. If dates are involved, verify that the date is displayed sensibly and the level was not unexpectedly canceled. If anything does not match, do not immediately edit the full spreadsheet. Record the test row number, saved mapping, and observed symptom. The next section explains the mechanics of membership levels and subscriptions before you expand the sample.

Why Membership Level and an Active Subscription Need Different Checks

The most important boundary when using Paid Memberships Pro Import Users from CSV is between assigning a level and preserving a working recurring subscription. A membership level determines the membership state a person receives on the site. A subscription connects that state to an external payment service that may later send a renewal, failed payment, or cancellation event. If the file contains only membership_id, the user may appear to have the correct access, but the external recurring charge will not automatically become a managed part of the new account. These are two different migration tasks, and mixing them without validation is risky.

The add-on documentation identifies two required fields for continuing or updating an existing subscription: membership_subscription_transaction_id and membership_gateway. The first connects the record to the subscription ID at the payment provider; the second identifies the gateway that handles that subscription. Depending on the situation, you may also need the amount, number and period of the billing cycle, and, for Stripe, pmpro_stripe_customerid. These fields are not meant to make a user profile look complete. They are needed to connect future gateway events to the correct member and membership record.

If the source system does not provide a reliable subscription identifier or you cannot confirm the gateway in use, do not try to restore the connection by assumption. Import accounts and approved levels through a separate process, and leave active recurring charges for a verifiable migration procedure involving the payment provider and developer. That decision is more honest than creating the appearance of an active subscription that does not update later. This article addresses data from an existing product, not payment setup: at the first sign of uncertainty, stop the business operation on a test copy and confirm the source of the details.

Processing Chain: Input Data, Rule, Visible Outcome

It is useful to view this behavior as a sequence of five verifiable stages. The input is a CSV row: a unique account key, profile data, a level ID, and, when needed, subscription fields. The mapping screen then determines which value becomes which field. After confirmation, the importer creates or finds the user. Paid Memberships Pro then applies the membership data and, if an accurate subscription link is present, stores information that lets payment events be associated with that member. The visible outcome is not only a row in the Users list, but also a specific level on the member profile, access to protected content, and, when applicable, a record in the subscriptions section.

There is no safe place in this chain for values that are only "approximately correct." An error in user_email can create a duplicate instead of updating an account. An error in membership_id assigns the wrong level or cancels membership when the value is 0. An error in a subscription identifier means future events cannot find the intended record. That is why it is useful to process the subscription layer separately even when every column could technically be uploaded in one file. A separate file is easier to verify because it contains only the matching key, level ID, gateway, subscription ID, and required billing-cycle settings.

Plan for a Member with Standard Access

For a member who should receive free, manually paid, or time-limited access, the workflow is relatively straightforward. Prepare a stable user_email or user_login key, assign a confirmed membership_id, and add start and end dates if needed. Run a test with one user. Then sign in with that account, open the account page and a protected page. If access is date-limited, check how the period is displayed and decide who will manage the expiration later. There is no need to add external subscription fields when they serve no purpose.

An important detail is that the number of rows and the number of users are not always the same. The add-on supports multiple levels for one person through duplicate rows, but only for groups of levels that allow multiple memberships. In addition, extra rows may overwrite standard WordPress data, custom metadata, and payment fields. The developer recommends importing users without membership data first, then importing membership details in a separate file containing only user_email and the required membership fields. This two-pass approach is especially useful for complex profiles because it protects names, roles, and metadata from accidental overwrites in the second row.

If One Person Has Multiple Levels

Do not model multiple levels as a comma-separated value inside membership_id. A multiple-level approach uses a separate row for each level and depends on the membership-group rules configured on the site. First test this capability with two test levels that are allowed to be combined. Then make sure the second pass contains only the minimum required data. Repeating first_name, roles, custom fields, or payment details in every row increases the risk that a blank or outdated value will be processed last and overwrite the correct one.

This workflow needs two checks: both expected memberships should be visible for the person in the admin area, and the public site should allow access to materials permitted by the combined levels. If the second level does not appear, do not add rows to the full file from memory. First open the membership-group settings, repeat the test with minimal columns, and make sure the cause is not a "one level from this group" restriction. That restriction is part of the membership model, not a CSV error.

Plan for Migrating an Active Subscription

An active recurring subscription requires a longer preparation stage. First confirm that the required level exists on the new site and the appropriate payment gateway is selected. Then export from the old system only records for which the source of the subscription identifier and status are genuinely clear. In the working file, map the user's address to user_email, the level to membership_id, the gateway to membership_gateway, and the subscription identifier to membership_subscription_transaction_id. For a Stripe migration, the documentation also recommends transferring amount and cycle settings, the Stripe customer ID, and, when available, the most recent payment ID so the account and records retain more correct context.

Amounts in a CSV require discipline. Do not use a thousands-separated format such as 1,000.00: the comma is also a common CSV delimiter and may cause the amount to be read incorrectly. Before testing, make sure numeric columns are separated from text correctly in the exported CSV and that the billing period uses the expected format. If spreadsheet software automatically changes codes, dates, or long identifiers, set those columns to text format before export. A subscription identifier must not be shortened, converted to scientific notation, or rounded.

Verification after importing an active subscription includes an additional screen: open Memberships > Subscriptions and locate the test record. Compare the user, level, subscription identifier, and billing data against the control sheet. Then sign in to the member's account and confirm that the expected state is displayed. Do not trigger a real charge merely to test the migration. For a migration you are unsure about, the developer recommends starting in test mode and, after confirming the outcome, separately linking production data correctly. This is a technically sensitive process, so actions involving real payment details should be performed only with a clear rollback plan.

Import Settings You Should Not Choose Automatically

Three checkboxes on the upload screen are especially important. New-member notifications should reflect the site's readiness and communication plan. Updating existing users should be enabled only when the selected key is truly reliable and the objective is an update rather than creation of a new list. Skipping existing members with the same active level is useful as protection against duplicate level changes, but it does not eliminate the need to review the file. These settings answer different questions and should not be enabled as a bundle "for safety."

After deciding on the settings, save the CSV version and a list of the selected checkboxes. This small detail makes troubleshooting much easier. If someone asks the next day why a user did not receive an email or why a level did not change, you will not need to guess whether the relevant setting was enabled. In a bulk migration, a decision log is not bureaucracy; it is part of a safe outcome.

Practical Example: Migrating a Club with Two Access Levels

Let us walk through a complete but safe example that can be adapted for an educational project, private club, or resource library. The goal is to migrate active members from an old spreadsheet to a new WordPress site running Paid Memberships Pro without giving access to the wrong segment or sending emails too early. Assume the new site already has "Member" and "Mentor" levels, while the old file contains an email address, first name, last name, internal member number, status, and access end date. Active external recurring subscriptions are not included in this first example because they require a separate, confirmed set of details.

The successful outcome is defined in advance. A new member receives an account with the subscriber role, the correct Paid Memberships Pro level, and an internal member-number field. An existing member does not receive a duplicate: their record is found by email, only the approved field is updated, and the level changes only where intended. A person whose access has ended does not receive an active level by mistake. After the run, an administrator can open the log, identify the source file, select the test rows, and show that the outcome matches the approved spreadsheet.

Step 1: Prepare Levels and a Control Matrix

In the Paid Memberships Pro admin area, first review the levels. Record not only their visible names but also their numeric IDs in the log. Then create a control matrix outside the future CSV: which original statuses may be migrated, which membership_id corresponds to each one, whether an end date is required, and whether the row should update an existing person or create a new one. Statuses with unclear meanings, such as "archived," "awaiting response," or "old," should not be included in automatic assignment. Mark them for manual review.

Check the account page and two pieces of content with different access rules. Manually create one test member for each level. Sign in as them in a separate browser window and confirm that the first sees the basic material while the second sees the additional material. This manual check takes little time, but it establishes the baseline against which the import will be compared. If a level does not open the required page before the CSV is uploaded, the problem is not the importer and must be solved before migration begins.

Step 2: Create a Narrow File for the First Run

Select six rows from the source list. Use two new basic-level members, one new mentor, one existing user with a member number to update, one person with an end date, and one questionable record that you deliberately will not import. For the first five, prepare the headers user_email, user_login, first_name, last_name, membership_id, membership_enddate, and the exact custom-field key, such as club_member_number. If only one person needs an end date, leave the field blank for the others rather than inserting an arbitrary date.

Validate the values separately. The email address should match the address used by the real test user. The username should not contain spaces and should not change during a repeated export. Confirm the numeric level ID against the admin area. Enter dates strictly in YYYY-MM-DD format. Compare the internal member number with the source. If the original spreadsheet includes a role, do not move it into the test file until you have established that WordPress truly needs it. In this example, the role remains the default and access is determined by membership level.

Step 3: Upload the CSV and Configure Mapping

Open Users > Import Members and select the prepared file. For the first run, do not enable notifications for real users. If one row represents an existing test account, enable updating existing users only after confirming the selected email address. Use the option to skip existing members according to the purpose of the test: if you are specifically testing a level change, it should not hide that test; if you are testing protection against a repeat run, it may be useful.

On the mapping screen, assign each column to its corresponding field. Profile fields connect to the matching WordPress fields, membership_id connects to the membership level, membership_enddate to the end date, and club_member_number to user metadata. There are no columns outside the file, which is the advantage of a narrow sample. If you need to retain an internal technical note for the test, do not send it to WordPress automatically: put the note in the run log or select Skip.

Before confirming, return to the control matrix. State the expected outcome for every row. For example: "Jane - new user, basic level, number CL-101"; "Michael - found by email, only the number changes"; "Olivia - mentor, no administrator role"; "Sophia - level with the specified expiration date." If even one expected outcome is unclear, cancel the mapping screen and fix the CSV. That is faster than analyzing consequences after a bulk run.

Step 4: Check the Outcome in Four Places

When the import finishes, do not rely only on the interface message. Open Users and find the created accounts by email. Check that no accidental duplicates exist and that the username and role are sensible. Then open Memberships > Members or the profile of a specific member and confirm the level. The third check is the user profile, where the club-number custom field should appear. The fourth is the public-facing site: sign in with a test account and check the account page, basic content, and mentor-level content.

Your review should include negative examples as well as positive ones. A basic-level member must not see the mentor section. Someone with an expired or unassigned level must not receive access to protected content. Sign out and make sure the page does not remain open due to browser caching or a test-state session. If the site uses caching, clear it through the normal procedure only after changing access rules, and perform the test in a fresh session. Do not consider the access mechanism fixed until you have tested at least one denial.

How to Record Results Without Excess Personal Data

A test report does not need a copy of the entire database. A list of anonymized row codes, the selected action, outcome, and note is enough. For example: "T-01 - created - basic level - access to page A granted"; "T-04 - updated by email - club number changed - no access to page B." This kind of log helps reveal that an error belongs to a specific row type rather than the whole import. It also lets you repeat verification after changing mappings without sharing email addresses and internal numbers in work chats.

If the test succeeds, do not immediately change the spreadsheet structure for the full run. Make a copy of the verified template and add data in segments. A sensible order is usually: new accounts with a simple level first, then updates to existing profiles, then time-limited records, and finally a separate active-subscription project. After each segment, repeat a short review of randomly selected rows. Smaller batches give you time to spot patterns while consequences remain limited.

How to Safely Expand a Test into a Bulk Migration

Moving from six rows to hundreds does not change the method, but it increases the cost of a mistake. Before a large run, reconcile the counts: how many rows are in the completed CSV, how many are new, how many should be updated, and how many were excluded manually. This does not need to be a complex report. What matters is that the final numbers make sense and can be compared with the outcome. If a file contains 400 rows and the plan calls for 350 new users and 50 updates, "400 processed" does not yet prove that the right thing happened.

Split files by risk. The safest segment is new people without payment history or complex metadata. Next come updates to existing users by stable email address. The most sensitive segment includes records with multiple levels, expiration dates, and recurring-subscription details. Do not combine them to save one click. This does not increase the amount of work linearly; instead, each file gets a short list of verification criteria, and when something goes wrong, you know where to look.

Keep an unchanged source file and the final CSV under clear filenames. Do not put secrets or passwords in the filename. After a successful segment, record the run time, selected settings, and number of processed rows. If a later run unexpectedly changes someone's level, you can compare it with the prior file instead of trying to remember what the spreadsheet contained. This control is especially important because a repeated import may leave orphaned data or unintentionally cancel a subscription. You must not repeat a bulk run "just in case."

Outcome check: before moving to the next segment, randomly select at least a few representatives of every row type and confirm the user, level, profile field, and access. If any of these four indicators does not match, stop expanding the migration and fix the rule using the test sample.

Post-Import Verification: Access, Profiles, and Reporting Data

A bulk migration does not end with a button in the admin area. It ends when you have verified that the user truly received the expected state. Paid Memberships Pro has several independent places where the outcome can be seen: the WordPress user list, the member list and profile, the subscriptions section when applicable, the account page, and protected material on the public-facing site. Check them as one chain. A record may exist in WordPress but have no level. A level may appear in the admin area while a protected page still shows an old state because of caching. An active subscription may look like a level while not being linked to the correct external identifier.

Start with a control sample. Take several rows from each segment: a new member, an updated existing user, a person with custom metadata, a record with an end date, a record with multiple levels if that model is used, and a separate member with an active subscription if one was migrated. For each person, record the original expected outcome before opening the admin area. Then check the outcome in the same order every time. A consistent sequence reduces the chance that you forget to assess access or review the wrong record.

Four Questions for Every Test Account

The first question is: did you find the exact intended user? Search using the selected key, usually email. During updates, it is particularly important to confirm that a second record with a nearly identical address or username has not appeared. The second question is: which membership level does Paid Memberships Pro show? Compare it to the control matrix, not the attractive name in the old spreadsheet. The third question is: were the expected profile data retained? Open the user profile and locate only metadata approved for import. The fourth question is: what does the person see after signing in? That is the check the entire operation was performed for.

For the last question, use a separate browser session or window without administrative authentication. Sign in with the test account, open the account page, a basic protected-content page, and, when relevant, higher-level material. Then sign out and try to open the protected page again. Testing a denial is no less important than testing allowed access. If a basic member can see mentor content, do not compensate by changing the CSV. First determine whether the content restriction and the level assigned to that page are configured correctly.

Reconciliation Through Export Without Re-Uploading

After completion, it is sensible to create a control export of the member list using Paid Memberships Pro's standard tools. In the members section, you can export the entire list or a filtered subset to CSV. This export is useful for comparison, not for immediately uploading it again. Compare the number of records per level, selected email addresses, and key custom fields with the control matrix. If you migrated only one segment, filtering by the corresponding level will make the comparison compact and clear.

Export-based reconciliation is especially effective at finding classification mistakes. For example, an old status may have been mapped to the wrong level, which becomes visible through an unexpected number of members in a group. It can also show that a custom field is blank or uses a different format. Do not turn this export into the new source file for the next import without analysis. An export reflects the state of the new site and does not necessarily have the same structure or header purpose as the original migration file.

For groups containing sensitive data, limit the comparison to the minimum necessary fields. Do not email the full export or attach it to tasks without protection. Importing and exporting are convenient, but both processes create copies of the database. Limit the people who can access source files, and after migration is complete, remove temporary copies from shared folders in accordance with the project's policy. This is an organizational measure, not a plugin feature, but it directly affects the security of member-data processing.

Custom Fields, Groups, and Related WordPress Mechanisms

CSV import is useful for more than an initial migration. It can become part of an ongoing process when responsibilities are defined clearly. Paid Memberships Pro stores and uses membership data. WordPress stores the account and role. An external CRM or spreadsheet may remain the source of primary information. Your goal is not to make every system do the same thing, but to agree which one owns each type of data. For example, a management CRM owns the contract number, the site owns access status, and the payment provider owns the actual recurring subscription.

When you add a custom field, describe its lifecycle. Who enters the value? In which form is it edited later? Should the member be able to see it? Does it affect access or serve only as a reference? A stable meta_key can be imported from CSV, but changing that key later will cause new values to be stored separately from old ones. For that reason, choose keys thoughtfully once; text labels can be changed through field settings without renaming the key itself.

Group Accounts: Why Parent Records Must Come First

If the project uses the PMPro Group Accounts add-on, importing child members requires a different sequence. First configure group accounts and prepare the parent file. The parent record uses a pmprogroupacct_group_total_seats column containing the number of available seats. After parent records are imported, the group receives an identifier that can be found in the Group Accounts panel on the relevant member's edit page. Only then should you prepare the child-record file using pmprogroupacct_group_id. This is not merely an organizational preference: a child record needs an existing group identifier to connect to.

Do not try to place parents and children into one untested CSV hoping that rows will be processed in the right order. Split the work into at least two files, test with one group, and verify not only the user list but also the seat count, child-to-parent connection, and actual access. If the source spreadsheet contains only the parent's email and not the confirmed ID of the created group, the first pass must stop with the parent records. Once the IDs are available, you can continue in a separate file.

A Practical Connection with Member Export

A useful and safe combination is a standard member export followed by a focused update import. First, an administrator exports a filtered CSV list, such as members at a specific level. Next, a working copy is enriched with only one verified field, such as a training-cohort code, and turned into a narrow update file. It includes user_email as the key and the field's meta_key. Name, role, and membership fields are not needed in this second file. After testing with two people, you can process the entire selected level.

This is not official automatic synchronization; it is a practical approach based on documented import and export capabilities. Its advantage is the minimal number of fields affected. The risk is that someone may use an outdated export or change an email before the update. Before running it, compare the export date, limit the time between export and import, and keep the ability to roll back only the added field. If the outcome is unsuitable, remove or correct the value through the standard user profile or prepare a narrow reverse file rather than repeating the entire migration.

Modes Best Left Disabled Until Data Is Confirmed

The import interface offers several useful capabilities, but each increases the impact of an error if the input file has not been verified. New-member notifications should remain disabled until you have checked the email, password setup link, sign-in page, and actual access. Updating existing users should not be enabled merely because "someone might already exist." It is justified when keys are clean and the fields to update are listed in the log. Active-subscription data should not be added to a general file until the gateway and identifier are confirmed.

Repeated imports require special caution. The documentation warns that repeated runs may leave orphaned data or accidentally cancel subscriptions. Therefore, after a successful run, do not treat the same file as a button to press "just in case." If you need to make a correction, prepare a new short file with one clear purpose: update metadata, assign a level to a specific segment, or verify a separate subscription connection. The narrower the file, the easier it is to explain its effects and reverse the action.

When You Should Stop the Migration

Stop if the mapping screen does not clearly show where a column will go; if the number of processed rows does not match the plan; if a test user receives an unexpected level; if their role changes; if a custom field contains someone else's data; if actual access does not match the level; if a subscription does not appear in the expected section; or if an email is sent before verification is complete. Stopping is not a failure. It is the correct outcome of a control stage that prevents an error from being scaled up.

Safe rollback: do not fix a bulk failure with another bulk import. Record the affected segment, restore a verified copy if necessary, and first reproduce the issue with one test user. Once you understand the cause, change only the narrow file and only the required state.

Import Troubleshooting: Finding the Cause Before Running It Again

Member-migration errors are rarely solved by uploading the same file again. One symptom can have several causes: a duplicate may be created because a different key was used, a level may not be assigned because its identifier is wrong, a field may not appear because the meta_key is incorrect, access may look wrong because of caching or restriction settings, and an active subscription may not be linked because a transaction identifier is missing. Good troubleshooting moves from the observed outcome to one small, testable CSV fragment, not from the assumption that "the importer did not work."

Before making any change, record four things: the file name and version, the row number or anonymized row code, the settings selected on the import screen, and the exact symptom. Then create a minimal test with one row of the same type. This is much more important than opening the full list. When the test row behaves as expected, you can compare it with the problematic row one field at a time. When the test also fails, you have a safe environment for checking mappings, level settings, and access rules.

The User Was Created but No Level Was Assigned

Symptom: the record appears in Users, but the expected membership does not appear in the member list or on the profile. First check that the CSV actually contains membership_id and that the column was mapped specifically to the level field on the mapping screen. Then compare the number in the test row with the level identifier in Paid Memberships Pro settings. Do not compare it only with a name such as "Standard" or "Premium": the import uses a numeric value. If the file contains a text status from the old system instead of a number, the level cannot be assigned correctly.

Fix: do not manually change levels for hundreds of people as your first response. Create a one-row test CSV with a stable key and the correct membership_id, repeat the mapping, and check the outcome with a new test user. If it is correct, prepare a separate narrow file for the affected segment containing the user key and level only, without names, roles, passwords, or unrelated metadata. The rollback is to return the level to its previous confirmed state or restore the site copy if the affected segment is too broad.

A Duplicate Appeared Instead of an Update

Symptom: after the run, WordPress contains two similar accounts while the old one was not changed. This usually means the selected key did not match exactly: the email contains a space, uses a different case or address, the username changed, or the expected value is missing from the row. Check whether Update Existing Users was enabled and which key your plan specifies. Do not try to determine the cause from the person's name, because identical names are not a key.

Fix: locate both records, determine which one was original, and stop further imports. On a test copy, clean up the key value, prepare one row with the exact existing user_email or user_login, and confirm the update. Only afterward should you decide how to handle the duplicate through the normal admin area and your data-retention policy. Do not delete an account at random before checking which one contains the membership, orders, or profile information.

A Custom Field Is Blank or Appears in the Wrong Place

Symptom: the level is assigned, but a client number, group, or other additional value does not appear in the profile. A common cause is that the CSV header contains the field label instead of its meta_key, or the column was skipped on the mapping screen. Another cause is expecting an internal field to appear on a public page even though it was created only for the admin area. First open the custom-field definition, then compare its key with the test-file header exactly.

Fix: import one test row with the correct key and a minimal field set. Find the value in the expected location. If the field should be visible to the user, configure its display through the normal tools and check the public site with a test account. If the field is confidential, do not expose it merely for easier verification. Rollback means correcting one metadata field in the test record or using a narrow reverse file, not importing the entire database again.

Site Access Does Not Match the Level

Symptom: the admin area shows the required level, but a protected page opens for the wrong person or does not open for someone who should have access. The cause may be outside the CSV: the restriction rule may be assigned to different content, another level may be in use, the browser may retain an old session, or the cache may display a page without an up-to-date check. First sign in as a control user in a clean session, then check the account page and the protected content itself. Compare the page rule with the ID of the assigned level.

Fix: correct the access rule or clear the cache through the site's standard procedure, then repeat both the allowed-access and denied-access checks. Do not assign a second level merely to make a page open: that can hide a rules error and broaden access beyond the plan. If the issue occurs again on a site copy without caching, limit the next import and consult the core membership system documentation using one reproducible test case.

A Subscription Does Not Appear or Update

Symptom: the user has a level, but the expected record is missing from the subscriptions section, or an error occurs when payment data changes. Check for exact membership_subscription_transaction_id and membership_gateway values and, for the relevant workflow, correct customer and billing-cycle details. Also confirm that the identifier was not automatically transformed by spreadsheet software and that the gateway matches the actual payment method. A level by itself does not create a connection to an external subscription.

Fix: stop the bulk portion, isolate one anonymized test record, and compare it with the source of the payment details. For a Stripe migration, begin in a controlled test environment if you are uncertain about the data. Do not create fake identifiers or treat a manually assigned level as a final replacement for an active subscription. The rollback is to stop importing subscriptions until the exact field set has been confirmed and you have consulted the person responsible for the payment integration.

A Repeated Import Unexpectedly Changed Data

Symptom: after another run, a value disappeared, a level changed, or orphaned records appeared. The documentation warns that repeated imports can leave orphaned data or accidentally cancel subscriptions. Check whether the repeated CSV contained blank columns, outdated profile values, or a membership_id value of 0. Compare file versions and note which checkboxes were selected in each run.

Fix: stop repeating the run. Restore a confirmed state in the test environment, then create a minimal file only for the needed correction. If the error affected many accounts and a verified backup exists, restoring the database through an approved process is safer than trying to guess reverse values from memory. After rollback, update the process log: another run is allowed only with a new clear objective and a new test sample.

Video Walkthrough of CSV Preparation and Upload

For readers who find it more useful to see the mapping screen once than reread the sequence of actions, the developer provides a focused add-on demonstration. The video shows CSV preparation, starting an import, common pitfalls, and working with custom fields. The time markers are particularly useful for a repeat viewing: file preparation begins shortly after the introduction, the import itself is shown in the middle portion, and error handling and additional fields appear closer to the end. Use it to confirm the interface path, but still perform your own migration first with a small sample.

When This Import Is the Right Choice

Paid Memberships Pro Import Users from CSV is worth using when a site is already built on Paid Memberships Pro and the task is defined as controlled creation or updating of members with clear access levels and profile fields. It is especially useful for migrating from an old system, periodically updating an approved segment, or preparing group accounts in the correct order. Its strength is not that it performs a large upload with "one click," but that it provides a clear mapping screen and lets you turn a verified row into an observable site outcome.

Before the main run, return to one simple criterion: can you identify the user key, level, approved additional fields, and verification method for every row? If so, start with a small sample, compare the account, membership, profile, and access, then proceed in segments. If not, clarify the data and rules first rather than trying to compensate for uncertainty with import settings. Once the test is confirmed, you can get the WordPress version and apply the procedure to your prepared site copy.

A good outcome is visible not in the number of processed rows, but in the predictable member experience: the person receives the correct account area, sees permitted materials, does not receive unnecessary permissions, and the administrator can explain the record's origin and state. That verifiability is what makes a database migration a manageable task rather than a risky one-time action.