There’s no plugin called “BuddyPress Export Members” or “BuddyPress Member Export/Import” on WordPress.org, we checked, and neither exists under those names. If an older version of this post sent you looking for one, that’s why you came up empty.
BuddyPress member data, usernames, XProfile fields, avatars, is stored as standard WordPress users and user meta under the hood, which means general-purpose WordPress user import/export tools can handle it. You don’t need a BuddyPress-specific plugin.
The Real Way to Do This
Import and Export Users and Customers, free, WordPress.org, actively maintained, updated within days of this writing, does exactly this: bulk export WordPress users, including their custom meta fields, to CSV, and bulk import them on another site.
- Install and activate the plugin on the site you’re exporting from.
- Go to Users > Export Users, choose which roles and fields to include, this is where your BuddyPress XProfile fields show up, since they’re stored as user meta.
- Download the CSV.
- On the target site, install the same plugin, go to Users > Import Users, upload the CSV, and map the fields.
Before You Import Anything
- Make sure BuddyPress and any XProfile field groups you’re relying on already exist on the target site. Importing user meta for fields that don’t exist yet won’t recreate the fields themselves.
- Back up the target site’s database first. A bad import is much easier to undo with a backup on hand than without one.
- Test with a small batch before running a full import, especially if you’re moving thousands of members at once.
Why This Confusion Keeps Coming Up
BuddyPress presents member data in a way that feels distinct from ordinary WordPress users, a full profile with custom fields, an activity history, group memberships, friend connections. It’s easy to assume something that feels this specialized needs an equally specialized export tool. Under the hood, though, BuddyPress builds almost entirely on top of core WordPress structures rather than inventing its own separate data layer. XProfile fields are user meta. Activity items live in their own custom table, but member identity itself is still a standard WordPress user account. That’s actually good news for anyone trying to move data between sites, it means the broad, well-tested ecosystem of general WordPress import/export tools applies here too, not just BuddyPress-specific plugins.
What Doesn’t Travel With a Basic CSV Export
Worth being precise about the limits of the CSV approach described above. It handles user accounts and their meta fields, which covers usernames, emails, and XProfile data cleanly. It does not, by default, carry over activity stream history, group memberships, friend connections, or private message threads. Those live in BuddyPress’s own custom database tables (bp_activity, bp_groups, bp_friends, and others), structured very differently from a flat user-meta CSV export and not something a general WordPress user-export plugin touches at all.
If your migration genuinely needs that deeper history, activity posts, group rosters, friend graphs, moved intact, a CSV-based user export alone won’t get you there. That’s a database-level migration involving BuddyPress’s specific custom tables, typically handled by exporting and importing the relevant tables directly via phpMyAdmin or WP-CLI’s database commands, with careful attention to how WordPress user IDs map between the source and target sites. Get that ID mapping wrong and activity items end up attributed to the wrong member, or to no member at all, on the target site.
A Full-Site Migration Plugin Might Be the Better Answer
If what you actually need is “move this entire BuddyPress community, activity history and all, to a new host or a new domain,” a general WordPress site-migration plugin (something like All-in-One WP Migration, Duplicator, or a similar full-database-and-files tool) is very likely a better fit than assembling a CSV-based member export plus a separate custom-table migration by hand. These tools move the entire database, including every BuddyPress-specific table, along with your media files, in one operation, without you needing to understand BuddyPress’s internal table structure at all.
The CSV export approach earns its keep for a narrower, more common scenario: pulling a subset of member data out for reporting, cleaning, or reuse elsewhere, not necessarily moving an entire live community from one server to another. Match the tool to the actual scope of what you’re trying to accomplish rather than defaulting to whichever approach you found first, since the wrong tool for the job tends to reveal itself only after you’re already partway through.
GDPR and Data Portability Requests
If a member specifically asks for a copy of their own data, a GDPR-style data portability request rather than a bulk admin export, this same CSV export tool can technically pull it, but check that your process only exports that one member’s row rather than exposing the entire user table in the process. Building a clean, repeatable “export one member’s data on request” workflow, rather than improvising it each time a request comes in, is worth setting up in advance if your community operates in a jurisdiction where this kind of request is a real, recurring obligation rather than a hypothetical.
Keep in mind this export still won’t include activity history, group memberships, or message threads for the reasons described above, if your data portability obligations extend to that kind of content as well, you’ll need the deeper, database-table-level export to fully satisfy the request rather than relying on the CSV tool alone.
Testing the Import on a Realistic Sample First
Beyond the general advice to test with a small batch, it’s worth being specific about what “small batch” should actually contain. Include at least one member with every XProfile field type your community uses filled in, a text field, a dropdown, a multi-select if you have one, an image or file upload field if applicable. A test batch of five blank or mostly-empty test accounts won’t surface field-mapping problems the way a handful of genuinely filled-out real profiles will.
Check the imported result field by field against the source, not just “did the import complete without an error message.” A silent field-mapping mismatch, where a value lands in the wrong XProfile field or fails to map at all, often doesn’t throw an error, it just produces subtly wrong data that goes unnoticed until a member complains their profile looks incomplete weeks later.
Duplicate Member Handling
If you’re importing into a target site that already has some overlapping members, the same person registered independently on both sites before the migration, decide up front how duplicates should be handled: merge, skip, or create a second account. Most import tools have a setting for this, usually matching against email address or username, but the default behavior varies by plugin and isn’t always the behavior you’d actually want for your specific migration. Confirm this setting explicitly rather than trusting whatever the tool defaults to, since the wrong choice here can silently overwrite an existing member’s data with an older, stale version from the export file.
A Realistic Timeline for a Member Data Migration
For a straightforward CSV export and import covering user accounts and XProfile data, budget an afternoon for a few hundred members, most of that time going into testing the field mapping and running the small-batch verification described above rather than the mechanics of the export and import itself, which are each a matter of minutes. For a deeper migration involving activity history and group data through direct database table handling, budget considerably more, a full day at minimum for a developer comfortable with WordPress’s database structure, more if the source and target sites have meaningfully different BuddyPress configurations or plugin sets that could affect how the custom tables are structured.
Password Handling During Import
One detail that trips up nearly everyone doing this for the first time: passwords generally do not export and import cleanly through a CSV-based tool, and shouldn’t, given how WordPress stores password hashes. Plan on either sending imported members a password reset link as part of the migration, or setting temporary random passwords and communicating that reset step clearly in your migration announcement. Assuming imported accounts will simply work with members’ existing passwords is a common and avoidable mistake that turns migration day into a wave of confused login-support tickets that could have been headed off with one clear line in the announcement email.
If you’re moving between two WordPress installs that use the same password hashing scheme, a more advanced database-level migration (rather than a CSV export/import) can sometimes preserve password hashes intact, but this is squarely in the territory of the deeper database-table migration discussed above, not something the simple CSV tool handles.
Email Deliverability After a Bulk Import
A bulk import that triggers password-reset emails or welcome emails to hundreds or thousands of members at once can look like a spam blast to your email provider, and to the receiving mail servers on the other end. Check whether your import tool sends these notifications in a controlled, throttled way, or all at once, and check your transactional email provider’s rate limits before running a large import. A sudden burst of outbound email from a domain that doesn’t normally send at that volume is exactly the pattern that gets flagged by spam filters, which can tank deliverability for your regular site emails in the following days, not just the migration batch itself.
For migrations in the thousands-of-members range, consider staggering the import in smaller batches over a few days rather than running it all in one pass, specifically to avoid this email-reputation risk. A staged rollout also gives you a natural checkpoint to catch data problems in the first batch before they’ve propagated across your entire member base, which is far cheaper to fix than untangling the same mistake after it’s already touched every account.
What to Tell Members Before and After
A migration that changes login credentials, moves the site to a new domain, or temporarily takes activity history offline deserves a heads-up before it happens, not just a post-migration announcement. A short email or pinned notice a few days ahead, explaining what’s changing, what members need to do (reset a password, bookmark a new URL), and roughly when to expect it, prevents a wave of “is the site broken” messages hitting your support inbox the moment the migration goes live.
After the migration, a brief confirmation post helps too, especially if anything visibly changed, a new domain, a slightly different profile layout, missing content that’s still being restored. Members are far more forgiving of a bumpy migration they were told about in advance than one that simply happened to them with no explanation.
Verifying Data Integrity After the Fact
Once an import completes, don’t just spot-check a couple of profiles and call it done. Pull a count of total imported users and compare it against your source export’s row count, a mismatch here is the fastest signal that something silently failed partway through. Spot-check across a range of the alphabet or account creation dates rather than just the first few rows in your CSV, since some import failures cluster around specific data patterns, a particular special character in a name field, an unusually long bio, that might only show up partway through the file rather than at the very start.
WP-CLI as a Faster Alternative for Large Migrations
For migrations involving thousands of members rather than a few hundred, the browser-based CSV upload and import flow can become genuinely slow, or time out entirely on hosting with tight execution limits. WP-CLI’s wp user import-csv command (available via the same underlying plugin ecosystem, or through a similar dedicated CLI tool) runs the import from the command line without the web server’s request timeout constraints getting in the way. If you have shell access to your hosting and are comfortable with basic command-line work, this is worth using for anything beyond a few hundred rows, it’s meaningfully faster and won’t silently fail partway through the way a browser upload sometimes does on a slow connection or a server with a tight PHP execution time limit.
Staging Environment Is Not Optional Here
It bears repeating beyond the general “back up first” advice: run the entire import process on a staging copy of your target site before touching production, especially for anything beyond a trivial handful of test accounts. A staging run surfaces field-mapping issues, duplicate-handling surprises, and password-reset email volume concerns while the stakes are still zero. Finding these problems on staging costs you an afternoon. Finding them on a live community mid-migration costs you member trust, and sometimes actual data, if a bad import needs to be rolled back after members have already started logging in and making changes to their freshly imported profiles.
Common Field-Mapping Mistakes
Beyond the general advice to check field mapping carefully, a few specific mistakes show up often enough to call out directly. Date fields, a join date, a birthday field, frequently import as plain text strings rather than properly formatted dates unless the mapping step explicitly handles the format conversion, which can quietly break any feature relying on that field being a real date, sorting by join date, a birthday widget pulling upcoming dates. Multi-select or checkbox-style XProfile fields sometimes import as a single flattened string instead of the multiple discrete values the field type expects, which displays oddly or fails to display at all on the target site.
Check any field that isn’t a simple single-line text value with extra scrutiny during your test-batch verification, since these are exactly the fields that pass a superficial glance and fail on closer inspection. These aren’t hypothetical edge cases, they’re the specific spots where CSV-based imports most commonly produce data that looks fine in the spreadsheet but breaks once BuddyPress tries to actually use it.
Multisite-Specific Considerations
If either the source or target site is part of a WordPress multisite network, user accounts work a little differently than on a standalone install, a single WordPress user can belong to multiple sites within the network, and BuddyPress’s own multisite handling adds another layer on top of that. A CSV export/import built for a standalone site doesn’t automatically understand network-wide user membership the same way, and importing into a multisite network without accounting for this can leave members created on the wrong sub-site, or missing the network-level user record entirely even though a per-site profile appears to exist.
If multisite is part of your setup, test this specific scenario on staging before assuming a standard single-site import process transfers cleanly. It’s a genuinely different data model, not just a bigger version of the same import, and treating it as a simple scale-up of the standalone process is exactly where multisite migrations tend to go wrong.
The Short Version
For member accounts and profile fields: a general WordPress CSV import/export plugin handles it, no BuddyPress-specific tool needed. For a full community migration including activity, groups, and messages: that’s either a full-site migration plugin or a direct database-table export, not a simple CSV job. Know which one you actually need before starting, since picking the wrong tool for the scope of the job is the single most common way these migrations go sideways.
Whichever path fits, the pattern that separates a clean migration from a messy one is the same: test on staging with realistic data, verify field by field rather than trusting a success message, and tell members what’s changing before they discover it on their own. The tooling matters less than the discipline around using it.