How to migrate a membership site in WordPress

First decide whether you are moving the whole site or changing the membership system. A host, server or domain move can usually use a complete copy of the WordPress files and database. Changing from one membership plugin to another is different: users, membership levels, access rules, orders, custom fields and payment subscriptions may use unrelated data structures.

Write down every active membership level, price, renewal interval, cancellation rule, protected content type, email, integration and payment gateway. This list becomes your acceptance checklist after the move.

Take a database backup and a separate copy of all WordPress files, including wp-content/uploads, themes, plugins and configuration files. WordPress treats the database and files as separate parts of a restorable site, so copying only the files is not enough.

For a busy site, schedule a short content freeze or maintenance window. Record new sign-ups, renewals, cancellations and posts made after the backup. The Friday failure to avoid is restoring an old database over a live site and silently losing recent memberships or payments.

Restore the backup to a staging site before touching the live site. If the domain or path changes, update the database URLs with a migration method that understands serialized data; a blind search-and-replace can corrupt stored settings. Check the site URL, home URL, database credentials and permalink settings after the restore.

Keep payment gateways in test mode or disable live billing on staging. Never let a staging copy send real renewal, cancellation or refund requests to your payment provider.

For a small site, the manual route is workable. Recreate the membership levels first, then recreate the access rules and protected-content settings. Export and import WordPress users where your plugins support it, and import or manually create membership records, orders and custom fields using the source and destination plugin’s documented tools. WordPress’s built-in export contains posts, pages, custom post types, users and related content, but it does not automatically translate one membership plugin’s rules into another’s.

Do not assume recurring payments moved with the users. Match each active subscription to the correct customer and gateway record, confirm whether the destination supports preserving the existing subscription ID, and configure webhooks before switching traffic. If the destination cannot safely take over active subscriptions, keep the old system handling renewals or ask the payment provider about an approved migration.

This route is fine for a small site with one gateway and mostly one-time memberships. It becomes slow and risky when you have thousands of members, several levels, historical orders, drip content, custom restrictions or active recurring billing.

Repeat the migration from a fresh backup if your staging test exposed problems. Import or convert the data in dependency order: users, membership levels, memberships or orders, then content restrictions and emails. Keep the old site available until you have verified the new one.

Before changing DNS, test registration, login, password reset, checkout, account pages, upgrades, downgrades, cancellations, renewals, failed payments, refunds and access to protected posts. Confirm that existing members keep their correct start and expiry dates. Once the checks pass, place the old site in maintenance mode, take a final database backup, switch DNS or hosting, and repeat the tests on the live domain.

Compare member counts, active memberships, cancelled accounts, upcoming renewals and recent orders between the old and new systems. Test at least one member from every important level and inspect content that is protected by individual posts, pages, categories, tags, custom post types and parent-child page rules.

Watch gateway logs, webhooks, scheduled tasks, email delivery and server errors for several renewal cycles. Keep the old backup and site untouched until you have confirmed that renewals, cancellations and refunds are reaching the correct system.

The fast route is a migration tool when you are moving from MemberPress to Paid Memberships Pro. Paid Memberships Pro’s MemberPress Migration Toolkit provides a guided wizard for membership levels, users, orders, content restrictions, compatible settings and a post-migration checklist. It processes larger migrations in the background and can optionally preserve active Stripe subscriptions, but you should still back up the site and test on staging first.

Install Paid Memberships Pro alongside MemberPress on the existing site, review the wizard’s migration summaries, map levels carefully, process the data, then test checkout, account pages, restrictions and payment events before switching off the old system. This is faster than hand-building a large migration, but it is not a substitute for checking integrations and records that the wizard does not cover.