Paid Memberships Pro Import Members From CSV - WordPress Plugin

A Guide to Safely Importing Members with Paid Memberships Pro Import Members From CSV

Paid Memberships Pro Import Members From CSV is not meant for a simple one-off user add. It is built for cases where you already have a member list in a spreadsheet and need to move it into WordPress carefully, assign access levels, preserve important custom fields, and, when possible, connect existing subscriptions to Paid Memberships Pro.

In this guide, we will walk through a practical workflow from CSV preparation to final verification: which fields are required, where to find the import screen, how to interpret Notify Members, Update Existing Users, and Skip Existing Members, why a test import matters more than speed, and which warning signs mean you should stop the import before running the full file.

We will also cover subscription migrations, repeat imports, multiple levels for one member, custom fields, error diagnosis, and comparable tools. This guide is written for membership site owners, WordPress administrators, and developers who already understand which membership levels should exist on the new site, but want to avoid accidental access cancellations, duplicate users, and order-related chaos.

When This Plugin Actually Makes Sense

Importing members looks simple only as long as you are dealing with two or three users. Once your spreadsheet includes membership levels, expiration dates, multiple payment gateways, extra profile fields, and existing subscriptions, manual entry becomes too risky. The real value of this plugin is that it works with PMPro membership data, not just basic WordPress user records.

In practice, Paid Memberships Pro Import Members From CSV is useful in several scenarios. The first is launching a new site when members were previously collected through a form, CRM, older platform, or even an offline registry. The second is migrating from another membership solution, where you need to move users over and match them to PMPro levels. The third is bulk-updating existing members: for example, adding a new custom meta key, fixing a display name, assigning a new level to a user group, or correcting an access expiration date.

It is important to understand where the plugin stops being the right tool. It is not a complete migration project by itself if the old site contains complex access logic, custom order tables, non-standard billing workflows, or historical data you need to preserve as an accounting record. It helps import members and related fields, but decisions about which data to carry over, how to connect subscriptions, and how to protect content after the migration still belong to the administrator.

Who It Is For

This plugin is especially well suited to sites with a clear membership structure: associations, private communities, training sites, paid newsletters, member directories, clubs, and similar projects where users get access based on a PMPro level. If you have a spreadsheet with email addresses, names, membership levels, and dates, the plugin can turn that spreadsheet into a manageable member database.

It also works well for developers or agencies migrating a client site from another system. In that case, the value is not just the import itself, but the ability to build a test CSV in advance, run a few sample rows, spot errors, confirm field mapping, and only then proceed with the full migration.

When Another Approach Is Better

If the task is just a standard user import without membership levels, a more general WordPress user importer may be enough. If you need to sync users from an external CRM on a schedule, you are better off looking at tools with automated scheduling and more flexible source handling. If you have active payments created in a system PMPro cannot connect to actual payment gateway subscription IDs, you should not promise seamless recurring billing continuity from a CSV import alone.

Quick takeaway: this plugin is worth using when you are moving or updating members specifically for PMPro and you are ready to validate the CSV structure ahead of time. It should not be your first tool for an unplanned "one-click" migration.

What to Prepare Before Installation and the First Import

The most common mistake in a bulk import is starting with the Import button instead of starting with a data map. A membership site has several responsibility layers: the WordPress user, profile meta fields, the PMPro level, a placeholder order, the payment gateway, and the subscription. If even one of those layers is poorly represented in the spreadsheet, the import may technically succeed while still producing the wrong result.

Before installing the plugin, do not start with the full CSV. Start with a working plan. That plan should clearly show which users will be created from scratch, which will be updated, which membership levels will be assigned, which fields will be stored as user meta, which members have active subscriptions, and which members simply need access until a specific date.

Check Your PMPro Setup

First, make sure the main Paid Memberships Pro plugin is already installed and configured. The required membership levels must already exist in the admin area, because the CSV uses the numeric membership_id, not a friendly level name. You can find these IDs under Memberships > Settings > Levels. If you put a level name in the spreadsheet instead of the numeric ID, the import will not be able to assign the membership correctly.

If the site uses PMPro level groups, verify in advance whether the specific group allows multiple active levels for the same member. PMPro documentation explicitly notes that extra rows for the same user should only be used where level groups allow multiple levels inside the group. This matters for membership organizations where one person can belong to both a core community and an additional program at the same time.

Create a Backup and a Staging Site

Importing members changes real user records, meta data, and membership relationships. That is why a safe process starts with a backup and a staging site. Ideally, the first test run happens on a copy of the live site where unnecessary emails, payment actions, and automated notifications are disabled.

For a migration from an active membership site, it is especially important to limit changes in the old system while the CSV is being prepared. If the old site continues accepting registrations and payments during preparation, the data will drift quickly. That is when you need a final sync plan: first a test import, then a freeze or short maintenance window, and only then a final CSV with the latest changes.

Build a Field Mapping Plan

The mapping plan answers one simple question: "which column in the old spreadsheet becomes which PMPro or WordPress field." The minimum set depends on your goal. To create or update a user, you need one identifier: user_id, user_login, or user_email. To assign a level, you need membership_id. To preserve subscription data, you need membership_subscription_transaction_id and membership_gateway.

If the spreadsheet includes custom fields, use the actual meta_key values, not the human-friendly labels from the old interface. For example, a field labeled "Company" on a form may actually be stored as company_name. This is especially important for PMPro User Fields: the plugin imports custom fields by meta key name, not by the visible field label.

Installing the Add On and the First Admin Check

Paid Memberships Pro Import Members From CSV is a premium Add On. The standard installation path is through Memberships > Add Ons, where the administrator finds the add-on, installs it, and activates it. If the plugin is installed manually, use the standard WordPress screen at Plugins > Add New > Upload Plugin and upload the ZIP archive there.

After activation, a new screen appears in the admin area at Users > Import Members. This is the main working screen: here you select the CSV file, define import options, and then map CSV columns to WordPress or PMPro fields. If the menu item is missing, first check the current user role and permissions related to user management. The plugin release notes specifically mention capability checks tied to user creation, so the account you are using must have the appropriate privileges.

What to Check Right After Activation

Do not upload the full file right away. Open Users > Import Members and make sure you can see the link to the sample CSV. You can use that template as a starting point, but do not treat it as a complete list of every possible column. The documentation warns that the template may include fields you do not need and may omit fields required for a specific migration.

Next, confirm that the membership levels are already created on the site. If the import needs to assign paid levels, note their numeric IDs. If the import needs to store custom fields, open the PMPro User Fields settings or review the old data source and record the exact meta keys. If you are moving active subscriptions, prepare the payment gateway data as well. Without these checks, the import screen may look ready even though the CSV is still incomplete.

The First Import Settings

At the file selection stage, three settings matter most. Notify Members sends new users an email with their username and a password reset link. That can be helpful during a controlled launch, but risky on a staging site or with an unverified file. Update Existing Users lets you update existing users when a match is found by username or email. For migrations where users already exist in WordPress, this is usually necessary. Skip Existing Members helps avoid changing a member's level when the file includes a duplicate with the same active membership level.

The best first run is a test import of 5-10 rows using either test users or carefully chosen real users. After that, check the user list, the PMPro member list, the member account page, and, if necessary, the order list. If the result does not match the plan, fix the CSV. Do not try to "patch up" a full import by hand afterward.

How to Build a CSV Without Hidden Traps

A CSV for member imports is not just a spreadsheet of email addresses. It should only include columns whose purpose you understand and are ready to verify after the import. The more unnecessary columns you include, the higher the risk of accidentally overwriting user data, roles, dates, or meta keys.

PMPro documentation divides fields into several groups: core WordPress user columns, membership level columns, subscription columns, custom fields, and special cases like parent-child relationships. We will use that same logic below, but with a practical focus: what is essential, what is risky, and what should only be imported when there is a clear reason.

User Identifiers

To match an existing record, use user_id, user_login, or user_email. If you are migrating from another WordPress site, user_email is usually safer than an old numeric ID because that ID may already belong to someone else on the new site. If the import is happening on the same site and you are certain of the current WordPress IDs, user_id can work well for precise updates.

The user_pass field exists technically, but passwords should only be imported when you have a specific reason and understand the expected format. In most cases, it is safer not to import passwords and instead let users reset them via email or the login page. That reduces the risk of mistakes involving hashes, encoding, and the security of the source data.

User Role

The role column defines the WordPress role. PMPro documentation recommends leaving ordinary imported members with the basic subscriber role. That is a sensible default: access to paid content should come from the PMPro level, not from elevated WordPress capabilities. If the import accidentally assigns members the editor or administrator role, that is far more serious than assigning the wrong membership level.

Membership Level and Dates

The field used to assign a level is membership_id. This is the numeric PMPro level ID. The value 0 has a special meaning: it cancels a user's existing levels. So never use 0 as a temporary placeholder. If the level is not yet known, it is better to remove that column from the test import or explicitly decide that this user should not have active membership access.

The fields membership_startdate, membership_enddate, and membership_timestamp should be in YYYY-MM-DD format. For an active recurring subscription, an end date is usually not appropriate: the documentation notes that you should not set an end date for lifetime access or an active recurring subscription. If you add an end date where the user is supposed to renew automatically, you may accidentally cut off access early.

Billing Amounts and Order History

The fields membership_initial_payment, membership_billing_amount, membership_cycle_number, membership_cycle_period, membership_billing_limit, membership_trial_amount, and membership_trial_limit help present the membership and its order details correctly. They are especially important if the member should see accurate billing terms on the account page.

But these fields should never be filled in approximately. If the old source stores pricing with a currency symbol, text-based billing periods, or a localized number format, normalize the spreadsheet first. Use plain numeric values for billing amounts with no extra symbols. For the billing period, use values PMPro accepts, such as Day, Week, Month, or Year.

Field Mapping and Import Logic

After you select a file, the plugin asks you to map the CSV columns to WordPress or PMPro fields. This has become especially important since the plugin added more flexible field mapping logic: the CSV no longer has to match the expected headers exactly, but the administrator still needs to understand what is actually entering the system.

The rule on the mapping screen is simple: if a column is not needed, set it to Skip. Do not import everything that happened to appear in an export from the old system. Old internal IDs, temporary service fields, legacy plugin statuses, and technical flags can clutter usermeta or create the false impression that the migration was more complete than it really was.

How to Think During Mapping

Think of the import as a chain: input - plugin logic - result - verification. The input is a CSV row. The plugin logic creates or updates the user, assigns the level, adds the order, and stores meta fields. The result appears in Users, Memberships > Members, Memberships > Orders, and on the member account page. Verification tells you whether the outcome matches what you intended.

If you cannot say in advance where you will verify the result of a specific column, that column probably should not be imported on the first pass. For example, first_name and last_name are easy to check in the user profile. membership_id is checked in the PMPro member list. membership_subscription_transaction_id is verified through the order and gateway connection. But an unclear column like old_status_flag is better skipped until you know exactly what it means.

Multiple Levels for One User

To assign multiple active levels to one user, use multiple CSV rows. Each row contains the same user and a separate membership_id. But there is an important nuance here: additional rows can overwrite custom fields and billing fields. That is why the official recommendation is to first import users without membership details, then run a second import for memberships only, keeping only the user identifier and the membership-related columns.

This two-step approach takes longer, but it reduces risk. The first import handles user creation and core meta data. The second handles levels. If you discover an error on step two, you will be fixing membership relationships instead of simultaneously changing users, roles, names, and additional fields.

Custom Fields and Arrays

The plugin can import PMPro custom fields and other usermeta values as long as the CSV uses the correct meta keys. Things get more complicated when a field stores an array, multiple selected values, or data from a third-party plugin. In that situation, start by checking the documentation for that specific field and test with a single row. If the format is not confirmed, do not include that complex value in the full import.

For PMPro User Fields, it is best to create those fields on the new site ahead of time. Then the import will not just store a meta key in the database, it will match a real profile field and a clear admin workflow. After the test import, open the user profile and make sure the value appears where the administrator expects to see it.

How to Adapt a CSV for Different Data Sources

The same import screen will be used differently depending on where the spreadsheet came from. An export from an old PMPro site, a file from another membership plugin, a CRM export, and a manually maintained admin spreadsheet may look similar on the surface. Underneath, they contain different identifiers, different status values, and different date logic. If you force them into one template without understanding the source, you can end up with a nicely formatted CSV that carries the wrong meaning.

Export from Another PMPro Site

This is the most straightforward scenario, but it is still not automatic. An older PMPro site already uses similar concepts: levels, orders, members, subscriptions. However, the numeric level IDs on the new site may be different. So you cannot simply copy membership_id from the old export if the levels were recreated on the new site. First build a conversion table: old level, new level, new numeric ID, level group, and whether multiple levels are allowed.

For active subscriptions, it is useful to pull the latest successful order and the subscription-related fields. But even in a PMPro-to-PMPro migration, you still need to verify the payment gateway, webhooks, and IPN handling. The import may create the correct database relationship, but future gateway events still need to be sent to the new site and processed by the new PMPro installation.

Moving from Another Membership Plugin

This is where similar words can be misleading. The old product may call something a membership, product, plan, or subscription, but that does not mean its ID can be dropped directly into membership_id. PMPro needs the ID of a level created on the new site. The old product ID is only a source value for mapping, not a final value.

If the old plugin exports multiple files for members, subscriptions, and transactions, do not try to combine them by guesswork. First identify the primary link key. In most cases, that will be the user's email plus a subscription ID or transaction ID. Then build an intermediate table where each row contains only the fields PMPro actually needs. For older statuses like active, expired, trialing, pending, or cancelled, decide in advance which ones should be imported and which ones should not be treated as active members.

CRM, Association Spreadsheet, or Offline Registry

These sources usually know nothing about PMPro levels or payment gateways. They typically provide a name, email, company, membership type, payment date, or expiration date. In this kind of import, do not invent subscriptions. It is better to import the users, level, start date, and end date, then allow future renewals to happen through the normal PMPro workflow.

A useful practice is to add a working column like migration_note for your own use, but not import it. You can use it to record why a person is being assigned a certain level, where a date came from, or whether the member needs follow-up after the import. On the mapping screen, set that column to Skip so it does not clutter usermeta.

Final CSV check: if the spreadsheet contains a field you cannot explain as a future WordPress user field, PMPro membership field, or subscription field, it should not go into the first full import.

Migrating Active Subscriptions and Payment Relationships

The most sensitive part of this entire process is moving active subscriptions. In PMPro, a subscription must be tied not only to the user, but also to the payment gateway's subscription identifier. The documentation states that to continue or update an existing subscription, the CSV must include membership_subscription_transaction_id and membership_gateway. Without them, the gateway integration will not know how to connect future payment, cancellation, or failure events to the correct member.

In practice, that means this: if the old system cannot provide the real subscription ID from Stripe, PayPal, or another gateway, the import will not turn a one-time data dump into a working recurring billing relationship. It may create the user and assign the level, but future gateway events remain a separate problem. That is why before the final import you need to validate not only the member table, but also the subscription and transaction exports from the old system.

What to Look For in the Old System

For Stripe, subscription IDs typically start with sub_. For PayPal, PMPro documentation identifies the I- prefix. These values belong in membership_subscription_transaction_id. The membership_gateway field must use the gateway code PMPro expects, such as stripe for Stripe.

If you are moving from one PMPro site to another, the data can be taken from orders: under Memberships > Orders, locate successful orders for active members and export the fields needed for import. If the migration is coming from another platform, you will usually need to match the user's email to the subscription ID in the old payment gateway. That is often the most time-consuming part of the migration.

When Subscriptions Cannot Be Preserved Automatically

PMPro's official documentation explicitly warns that for some platforms, existing subscriptions cannot be preserved as manageable PMPro subscriptions. For example, if the old system does not use real gateway subscriptions and instead creates recurring charges as separate payments, a CSV import cannot turn that history into a true subscription relationship. In that case, it is safer to import users with an end date or membership status, then build a renewal path through PMPro afterward.

Do not treat this like a minor technical footnote. For the business, it affects revenue and communication with members. If the subscription cannot be preserved, members need clear instructions on what to do when renewal time comes, and the administrator needs to verify what emails and payment pages the user will see.

The Filter for Canceling Old Subscriptions

The plugin includes a filter named pmproiufcsv_cancel_prev_sub_on_import. By default, it does not cancel existing subscriptions at the gateway when an import runs. That is a protective default: an accidental import should not mass-cancel billing agreements. This filter should only be changed by a developer who fully understands the consequences and has tested the process on a staging site.

For most administrators, the correct conclusion is simple: do not try to manage gateway subscription cancellations through CSV without a separate migration plan. Member imports and payment migrations are related, but they are not the same process.

Practical Scenario: Move Members from an Old Spreadsheet into PMPro

Let us walk through the scenario that shows up most often on real sites. Imagine a membership club with two levels: basic access and professional access. The old spreadsheet includes email, first name, last name, company name, the old membership status, start date, end date for annual members, and some active Stripe subscriptions. The goal is to move those members into PMPro, avoid sending accidental emails during testing, and verify the result before the full launch.

Goal

Create WordPress users with the subscriber role, assign the correct membership_id, preserve the company field as custom user meta, and for active Stripe subscriptions connect membership_subscription_transaction_id together with membership_gateway. After the import, the member should appear in Memberships > Members, and the administrator should see the expected level and profile details.

Preparation

1. Create a backup and a test copy of the site.
2. Create the membership levels under Memberships > Settings > Levels and write down their numeric IDs.
3. Create the company custom field in PMPro User Fields or confirm that the meta key already exists.
4. Build a test CSV with 5-10 rows: a new user, an existing user, a user without an end date, a user with an end date, and a user with an active subscription.
5. Disable notifications on the staging site or leave Notify Members turned off.

Import Steps

1. Open Users > Import Members.
2. Select the prepared CSV file.
3. Leave Notify Members turned off for the test run.
4. Enable Update Existing Users if the file includes users who already exist on the site.
5. Enable Skip Existing Members if there is a risk of duplicates with the same active level.
6. Click Import and review every column on the mapping screen.
7. Set unnecessary legacy service columns to Skip.
8. Click Confirm Mapping and Import and wait for processing to finish.

Verifying the Result

After the test import, open Users and find each test user. Then open Memberships > Members and confirm the level. For the member with an end date, make sure the date appears as expected. For the member with a subscription, verify the order and the subscription fields. If there is a public account page, log in as the test user or use a safe method to inspect the profile so you can see the access exactly as the member would.

Important nuance: if even one row behaves incorrectly in the test import, do not run the full file. Fix the CSV structure or the mapping first. Repeat imports can create extra data or alter subscriptions, so it is much safer to catch the problem in a small test set.

Validation After the Full Import

You should not treat the full import as successful just because no error appeared on screen. Bulk operations often look clean on the surface, but individual rows may skip a field, assign the wrong level, create a duplicate, or leave a subscription unlinked. That is why every full import needs a short but strict quality check afterward.

Spot-Checking a Sample

Select several types of members: a new user, an existing user, a member with an active level, a member with an end date, a member with a subscription, a member with custom fields, and a member whose row contained unusual data. For each one, check the same set of points: user profile, member list, order, account page, and access to protected content.

If the site structure allows it, create a test protected page for each level and confirm that a member with the correct level can see the content while a user without that level cannot. This is a fast way to catch a membership_id problem when the level was imported incorrectly or not imported at all.

Counts and Reports

Compare the number of rows in the CSV with the number of users and members created or updated. Do not expect a perfect one-to-one match if the file contains multiple rows for one person, rows for multiple levels, or skipped records. But any difference should still be explainable. If the CSV contains 1,000 unique email addresses and WordPress only adds 870 users, you need to find out which rows failed and why.

For membership sites, it is also useful to check the number of members assigned to each level. If one level unexpectedly ends up with zero members, the CSV probably contains the wrong membership_id or the mapping was not confirmed correctly. If all members received the same level, you may have used a fixed value where the import should have used a CSV column instead.

Emails and User Experience

If Notify Members was enabled during the final import, check a test mailbox and review the email content. New users should clearly understand how to access the site and reset their password. If emails were disabled, prepare a separate onboarding email or instruction flow. Do not leave members in a situation where the account exists but they have no idea how to log in.

Safe Settings and Small Improvements for Large CSV Files

For a small file, the default settings are usually enough. For a large CSV, predictability matters more: processing should not run into server limits, a repeated run should not damage subscriptions by accident, and the administrator should know how to locate the row that caused an error.

Recent plugin releases improved AJAX processing and row-level error reporting. That matters for larger files because the import runs in batches instead of one heavy request. The add-on also exposes a filter named pmprocsv_ajax_import_batch that changes the batch size. The default is 50 imports per iteration.

When to Reduce the Batch Size

If a test import stalls on weak hosting, times out, or the server struggles to process custom fields and orders, you can reduce the batch size. That will make the import slower, but more stable. This should only be done after testing and only in a safe place: a child theme, a small utility plugin, or Code Snippets.

add_filter( 'pmprocsv_ajax_import_batch', function( $batch_size ) {
    // Reduce the batch size for weak hosting or a very heavy CSV.
    return 25;
} );

After adding the snippet, run a test import on a small sample. If processing becomes more stable, you can use that setting for the final file. If nothing changes, disable the snippet and look for the cause in the CSV, server limits, third-party plugins, or a specific row. Rolling back is simple: remove the snippet or disable it in Code Snippets.

What Not to Automate Without a Developer

Do not add code that automatically cancels subscriptions, changes roles, deletes meta data, or rewrites levels on every import. The plugin hooks offer a lot of power for developers, but membership data is too sensitive for a "quick fix from a forum thread." If you need a more complex workflow, for example sending imported data to a CRM or generating a custom report, it is better to use documented action hooks and start by logging the process instead of modifying payments.

How to Respect the Limits and Avoid Damaging Your Data

This plugin gives you powerful access to user and membership data. That makes its limitations part of your safety model, not just a technical footnote. The main rule is simple: the CSV should describe only the changes you actually want to make. If the goal is to update membership access, do not bring passwords, roles, and dozens of old meta fields into the file. If the goal is to add one meta field, do not include membership_id unless it is truly needed.

Repeat Imports

The official documentation warns that repeat imports can create extra data or accidentally affect subscriptions. That does not mean repeat imports are always forbidden. It means they should be narrow and targeted. If you are re-importing membership levels, remove unnecessary custom fields. If you are updating names, remove the billing fields. If you are fixing subscriptions, do not touch roles or passwords.

Expiration Dates

Expiration dates are not just profile notes, they are active access logic. If you set membership_enddate for a member with a recurring subscription, you may cut off access incorrectly. If you leave the date blank for a member who should expire, they may keep access longer than intended. That is why date-related changes are best checked in a separate sample set.

Third-Party Plugins and Cache

The import itself runs in the admin area, but its effects show up on the public site through protected content, the account page, menus, or blocks. If a member still sees the old status after the import, check not only PMPro but also page caching, object caching, membership dashboard plugins, and custom templates. For validation, it is better to use a private browser window and a regular test user account, not the administrator's current session.

Common Import Problems and How to Diagnose Them

Import failures almost always come down to one of five layers: the CSV was prepared poorly, field mapping was chosen incorrectly, the PMPro level does not exist, the user already exists and is being updated differently than expected, or the payment subscription cannot be linked to PMPro. Below is a practical troubleshooting guide without risky actions.

Members Did Not Receive the Correct Level

Symptom: users were created, but Memberships > Members does not show the expected level, or everyone received a different level.

Likely cause: the CSV contains a level name instead of a numeric membership_id, an old ID from another system, or the wrong ID from a staging site. Another common cause is that the column was skipped on the mapping screen or matched to the wrong field.

What to check: open Memberships > Settings > Levels and compare the level IDs with the CSV. Then retry the import for a single test row with Update Existing Users enabled if the user already exists.

How to fix it: correct the CSV, remove unnecessary fields, and rerun a narrow import for membership data only. If the wrong levels were assigned to a large number of users, create a rollback plan first instead of running another full import on top of the previous one.

Duplicate Users Appeared

Symptom: instead of updating an existing user, the import created a new account with a similar email or login.

Likely cause: Update Existing Users was not enabled, the CSV contains a different email address, there are stray spaces, the encoding is wrong, or the import relied on a field that does not actually match the existing user.

What to check: compare the exact user_email and user_login values in the CSV and in WordPress. Look carefully for leading and trailing spaces, especially after exporting from spreadsheets.

How to fix it: clean the CSV, choose one reliable identifier, and test 2-3 rows. Do not mass-delete users without a backup, because removing a user can also remove orders, content, or relationships used by other plugins.

The CSV Imports, but Custom Fields Are Not Visible

Symptom: the user is created and the level is assigned, but a company, phone, or internal ID field does not appear in the profile.

Likely cause: the CSV header uses the field label instead of the real meta_key, the field was never created in PMPro User Fields, or the value is stored in a complex format that does not match what the field expects.

What to check: find the exact field meta key. If the field was added through PMPro User Fields, review its settings. If it is a third-party field, check the documentation for the related plugin.

How to fix it: rename the CSV column to the exact meta_key and run a one-row test import. For complex fields with multiple values, do not run the full import until the format is confirmed.

The Subscription Does Not Continue Working After Migration

Symptom: the member appears active, but future payment events are not linked to the account, or the administrator cannot see the expected connection to the order.

Likely cause: membership_subscription_transaction_id and membership_gateway were not imported, the wrong gateway code was used, the old system does not provide a real subscription ID, or the payment gateway webhooks/IPN are not configured for the new site.

What to check: compare the subscription ID in the CSV with the payment gateway. For Stripe, look for values like sub_; for PayPal, values beginning with I-. Review the PMPro gateway settings and test a payment event if that can be done safely.

How to fix it: do not guess the subscription ID. If the data is missing, use an end-date-based migration and have members renew through PMPro. If the data exists, correct the CSV and test with a single subscription.

The Import Stalls or Runs Too Slowly

Symptom: the process stops, the screen never finishes, or the server returns an error.

Likely cause: a large CSV, weak hosting, heavy custom fields, third-party plugins, low PHP limits, or an AJAX batch size that is too large.

What to check: reduce the file to a small sample and run it again. If the small file works, the problem is not the mapping but the file size or server-side processing. If the small file also fails, look for a specific row or field.

How to fix it: reduce the batch size through the documented filter, temporarily disable unnecessary integrations on the staging site, and split the import into logical parts. Do not rerun one massive file without understanding where the process stopped.

How Paid Memberships Pro Import Members From CSV Fits into the Broader PMPro Ecosystem

Importing members is only one part of a much larger system. After the import, the member needs to land in the right level, get access to protected content, see the correct account page, receive emails, and, if a subscription exists, be linked to the payment gateway. That is why this plugin should be viewed not as a "spreadsheet uploader," but as a migration bridge between your data and PMPro.

Levels and Level Groups

PMPro allows a member to hold multiple levels if the Level Groups structure permits it. Your import needs to respect that architecture. If the old site used several separate products, decide first whether they should become separate levels, level groups, or add-on sales. Only after that should you build the CSV rows.

Orders and Billing History

When membership data is imported, PMPro may create an order representation for the imported member. But that is not a replacement for the full historical record from the old system. If you need accounting reports for past payments, keep the old exports separately. In PMPro, import only what is required for current access, future renewals, and a clear member account experience.

Profile Fields and Future Forms

A custom field imported as meta data should have a future purpose. If the field will be used in profiles, filters, CRM integrations, or email segmentation, create it in PMPro User Fields or the target system before the import. If it is only needed as archived reference data, it may be better stored in a separate migration CSV rather than in the live user profile.

When Paid Memberships Pro Import Members From CSV Is the Right Choice

This plugin is a strong choice if you already use Paid Memberships Pro, have a clear level structure, and can prepare a solid CSV, especially when the task is member-related rather than a generic WordPress user import. It is particularly useful for PMPro migrations, bulk membership updates, and transferring custom fields when you are ready to follow the sequence of "test sample - verify results - final import."

If you are just getting started, do not rush into the full file. Create the levels first, write down the IDs, prepare the column map, test 5-10 rows, and confirm that the result appears correctly in the profile, member list, orders, and public account page. After that, you can download Paid Memberships Pro Import Members From CSV and use it as a real working tool, not as an experiment on a live database.

For complex migrations involving active payments, treat the CSV as one part of the project, not the entire solution. Where a subscription can be preserved, the import can help connect the necessary data. Where the old system does not expose real gateway subscriptions, it is better to plan renewals honestly through PMPro and explain that to members in advance.