Migrating a Membership Site Without Locking Members Out

The morning after a badly planned membership site migration, the same three emails arrive in bulk: "I cannot log in", "I was charged twice" and "my courses are gone". Each one traces back to a piece of data that was moved without being understood: a password hash, a payment token, an access record.

This is the sequence we follow to move members, subscriptions and content, with a rehearsal before the real thing. It applies when you change membership plugins, leave a hosted course platform or rebuild the site on a new stack.

List what a member is made of

A "member" is at least six kinds of data, kept in different places and moved in different ways. Write this table out for your own site before anyone exports anything.

Data	Where it lives	How it moves
Login: email, username, password hash	Users table	Export and import. The hash is reusable only if the new system can verify it
Access: level, start date, expiry, status	Membership plugin tables	Mapped level by level, with the original dates
Billing schedule: plan, amount, next payment date	The plugin or the gateway	Recreated with the same next payment date
Saved payment method	At the payment gateway, as a token	Stays with the gateway account. It is never in your export
History: orders, completed lessons, drip position	Plugin tables	Migrated, or dropped by an explicit decision
Addresses: content, login, account, downloads	Permalinks and old emails	A redirect map

Move the password hash or plan the reset

You do not have your members' passwords. You have hashes, and whether people keep their password depends on whether the new system can check the old hash format.

WordPress to WordPress. Copy the user_pass column as it is. Current WordPress stores passwords with bcrypt and still verifies the older phpass hashes, upgrading each one the next time its owner logs in. The developer note on the bcrypt change confirms the hashes stay portable between sites. The keys and salts in wp-config.php sign login cookies, not passwords, so if they differ on the new site everyone is simply asked to log in once.

From another application. WordPress checks hashes it does not recognize with PHP's password_verify(), so standard bcrypt hashes from a PHP framework can usually be imported directly. For an older home-grown format, store the legacy hash in user meta, verify it yourself on the check_password filter, and on the first successful login call wp_set_password() so a modern hash replaces it.

From a hosted platform. Most do not export password hashes at all. Import the accounts without passwords and send each member a link to set one. Announce it in advance so nobody discovers it at the login form. Never email passwords, and never set one shared temporary password for everybody.

Payment tokens stay at the gateway

Your site does not hold card numbers. It holds references to a customer and a payment method stored by the gateway, and what happens to them depends on which of three situations you are in.

Same gateway account, new site

The tokens stay valid. Carry the gateway's customer and payment method identifiers across with each member and recreate the billing schedule against them. Then settle who triggers renewals. If the old platform created subscriptions inside the gateway, they keep charging no matter what your website does. Either keep them and point the gateway's webhooks at the new site, or cancel them and let the new platform bill. Doing both is how members get charged twice.

A different gateway

Card data moves from processor to processor and never passes through your hands. You ask the old processor to send an export to the new one. Stripe documents this as a payments data import and returns a mapping file of old identifiers to new ones. The old processor can take days or weeks to act, so start this before anything else. Some hosted platforms process payments under their own account and may not release tokens. Members then have to enter a card again, and the move becomes a re-subscription campaign with a deadline.

PayPal and other wallet agreements

These belong to the PayPal account that created them and generally cannot be transferred to a card processor. Leave them running on the old integration until they lapse, or ask those members to subscribe again.

One WooCommerce detail catches many site moves. WooCommerce Subscriptions records the site address, and when the address changes it treats the site as a staging copy, switching off automatic payments and subscription emails. After a deliberate move, choose "Enable automatic payments" in the notice on the new site, and make sure the old copy can no longer process renewals.

Map access levels and keep the original dates

Build a mapping sheet from every old level to a new one, and include the awkward rows: grandfathered prices, lifetime members, complimentary accounts, people with two levels, paused accounts. The row most often missed is "canceled but paid until a date". Those members must keep access until that date and must not be billed again.

Carry start dates and expiry dates across unchanged. Drip schedules are calculated from the start date, so a member imported with today's date is sent back to lesson one.

Switch off outgoing email for the duration of the import. Otherwise every imported member triggers a welcome message and a receipt. On WordPress, a filter on pre_wp_mail that returns false while the import runs is enough.

Keep every old address working

Members arrive from bookmarks and from old emails. List the old addresses for content, the login page, the account area, checkout links and file downloads, and redirect each one permanently to its new home. A member who lands on a lesson while logged out should be returned to that lesson after login. Search traffic depends on the same map, which we cover in the website migration SEO checklist.

Rehearse the membership site migration on staging

1. Prepare test members on the old site before you export: one per level and per state (active, paused, canceled with time left, expired, lifetime), with passwords you know.
2. Copy production data to staging. Put the gateway integration in test mode and block outgoing mail.
3. Run the import as scripts, start to finish, and time it. Hand edits cannot be repeated on the day.
4. Reconcile the counts on both sides: members by level and status, active subscriptions, renewals due in the next thirty days. wp user list --role=subscriber --format=count gives a quick total on WordPress.
5. Log in as each test member with the old password and open content they should and should not see.
6. Trigger a renewal in test mode. Expect one charge, one receipt and no gap in access.
7. Click through the redirect map.

Fix the scripts and repeat until one full run is clean.

Cut over in a quiet window and tell members first

Choose a time when no renewal batch is due. Lower the DNS time-to-live a few days ahead. On the day, freeze sign-ups and account changes on the old site, import the members who joined since the rehearsal, switch the domain, turn payments on in the new system and off in the old one, and watch the first real renewals go through. Keep the old site intact but unable to bill for a few weeks. It is your rollback, and your reference when someone questions their history.

Members need three messages. A week before: what is changing, when, and what they need to do, which should be nothing or one click. On the day: the new login link, and the set-password link if they need one. A week later: a reminder to anyone who has not logged in. Tell them if the name on their card statement will change, because an unfamiliar name can prompt a dispute.

What you can do yourself

Moving the same WordPress site to a new host under the same domain is a file and database copy. If the address changes too, the Subscriptions staging notice is the main thing to watch. It becomes a project when the plugin or platform changes, when the gateway changes, or when the site has thousands of active subscriptions and no margin for a second attempt. That is the kind of membership and subscription site work we take on, either as a WordPress migration or as a wider platform migration, and the rehearsal is always part of the plan.

Frequently asked questions

Will members have to reset their passwords after the move?

Not if the old system lets you export password hashes and the new one can verify them, which is the normal case between two WordPress sites. Hosted platforms rarely export hashes, so expect a set-password email there and announce it beforehand.

Can saved cards be moved to a new payment gateway?

Often, yes, but not by you. The old processor sends the card data straight to the new one after the account owner requests it, and the new processor gives you a file that maps old identifiers to new ones. Wallet agreements such as PayPal subscriptions usually cannot be moved.

Should canceled and expired members be migrated too?

Usually yes, as inactive accounts. Returning members keep their login and history, and you can still reach them with an offer. Check your privacy policy and retention rules first, and leave out anyone who asked for their data to be deleted.

How long should the old site stay online?

Keep it for a few weeks, closed to the public and with billing disabled. It is the way back if something serious appears, and the place to look up a member's old record.