How to Move a Membership Site to a New Host Without Breaking Payments or Logins

Moving a membership site to a new host is a normal WordPress migration plus four things a blog doesn’t have: payment webhooks, scheduled renewals, member logins and course or community data. Most of the risk sits in the hours when both the old and new copies of your site exist. If both can talk to your payment gateway, you can get duplicate charges or cancelled subscriptions. If the move drags on, renewals and reminder emails can be missed.

Paid Memberships Pro’s own migration guide puts the stakes plainly: “On a membership site, the worst case is canceled subscriptions at the gateway, duplicate charges, missing uploads, and members locked out of paid content they paid for” (Paid Memberships Pro).

The generic steps (copy files, export the database, point DNS) are covered well elsewhere, including WordPress’s own migration handbook.

Sources are each vendor’s own documentation, checked on 19 September 2026. Citing a company’s documentation doesn’t mean it endorses this article, and product names are trademarks of their owners.

Why a membership site is harder to move

MemberMouse’s migration doc lists what tends to go wrong: “Migrations can be problematic, such as unexpected billing times, out-of-sync emails, missing members, missing files, and file permission issues” (MemberMouse). Most of those come from the same cause. Your site isn’t only answering visitors. It also receives messages from Stripe or PayPal, runs scheduled jobs that expire members and send reminders, and holds per-member data that has to line up exactly with your courses and content.

1. Payment gateways: the part that breaks first

Know where your webhooks point

Your payment gateway tells your site about renewals, failed payments and cancellations through webhooks: messages sent to a URL on your site. Each plugin uses its own address. MemberPress’s look like https://yoursite.com/mepr/notify/xxxxxx-xxx/whk (MemberPress). Paid Memberships Pro’s Stripe webhook is “http://www.YOURDOMAIN.com/wp-admin/admin-ajax.php?action=stripe_webhook” (Paid Memberships Pro). WooCommerce’s Stripe extension uses https://www.example.com/?wc-api=wc_stripe (WooCommerce). LifterLMS creates its Stripe webhook automatically when you add your API keys (LifterLMS).

If you keep the same domain, those URLs don’t change, and once DNS points at the new server the webhooks arrive there. If the domain changes, the gateway has to be told. MemberPress’s instruction after a domain change is to “reconnect your Stripe gateway. This will update your webhooks to use the new domain” (MemberPress). MemberPress also notes that with Authorize.net “you’ll need to update the Silent Post and Webhook URLs” by hand (MemberPress).

Before you touch anything, write down every webhook your gateways have registered for the site. You’ll check them against the new site afterwards.

Never run two live copies against one gateway

Paid Memberships Pro’s guide puts the rule directly: “do not have two sites connected to the same gateway in live mode at the same time” (Paid Memberships Pro). Two copies that can both charge, renew or cancel will drift apart: one records a renewal the other doesn’t know about, or both act on the same subscription.

The copy on the new server is a clone of your live site, gateway keys included. Some plugins try to catch this:

WooCommerce Subscriptions “disables automatic payments and subscription-related emails when it detects that the current site’s URL differs from the URL of the site where you first activated the extension.” But if you move the database and keep the same domain, “the new site will not trigger staging mode. This means Subscriptions will process renewal payments in live mode” (WooCommerce). On a host move, that’s usually your situation.
Paid Memberships Pro (2.10 and later) detects when the site URL changes and disables its scheduled jobs, including membership expirations and expiry warnings, until you confirm the change (Paid Memberships Pro).
LifterLMS says both it and WooCommerce Subscriptions “attempt to detect when your site is cloned, but a recurring payment could slip through if the detection methods fail for some reason” (LifterLMS).

Treat these as a safety net, not a plan. Most of them key off a URL change, and a same-domain host move doesn’t change the URL. Decide which copy is live at each moment, and make sure the other one can’t take payments.

MemberPress: don’t disconnect Stripe on the copy

MemberPress’s Stripe doc warns: “Disconnecting Stripe, deleting the Stripe payment method, or disconnecting from MemberPress.com on a staging site (cloned from live) will delete the live webhook!” (MemberPress). The copy shares the live site’s connection, so “cleaning up” the gateway on the copy breaks the live one. MemberPress’s staging guide describes the fix if it happens: “try disconnecting and reconnecting the Stripe connection on your live site” (MemberPress).

PayPal gives you a little slack

PayPal’s older IPN system retries: “The IPN service automatically resends messages until the listener acknowledges them. The service resends messages for up to 4 days” (PayPal). That softens a short outage, but only if the messages reach a site that will record them. MemberMouse singles PayPal out: “Special attention needs to be paid to PayPal if you use it as a payment processor” (MemberMouse).

2. Renewals and scheduled jobs: move fast, and freeze what you can

WordPress runs scheduled jobs through WP-Cron, which “does not run constantly as the system cron does; it is only triggered on page load” (WordPress). During a move, the old site may still be getting visits and running jobs, while the new one gets none until DNS switches over.

That’s why vendors push for a short, quiet cutover. MemberMouse warns: “If the migration process takes more than a short time, recurring billing cycles can be missed, so be sure to migrate swiftly and check on any recurring billing that should be occurring for that day” (MemberMouse). Paid Memberships Pro suggests pausing everything optional: “Postpone scheduled email sends and broadcasts. Disable any new product launches, promotional discounts, or sales sequences during the move” (Paid Memberships Pro).

The order that keeps payments and member data safe:

Stop the new copy from acting on its own. As soon as the copy exists on the new server, and again after every import (a database import can overwrite these settings), make sure it can’t take payments or run scheduled jobs: gateways in test mode or disconnected there (except on MemberPress, see above: never disconnect on a copy), and its WP-Cron and any job queue such as WooCommerce’s Action Scheduler switched off.
Pick your quietest window, away from a billing run or a cohort start.
Freeze the old site. Put it in maintenance mode so members can’t sign up, buy, post or complete lessons, and pause its scheduled jobs and broadcasts. Let any payment already in progress finish, and make sure the old site has recorded its result (the order or renewal shows as paid or failed) before you go on. If a renewal’s state is unclear, settle it before the new site’s payment jobs are switched on. Anything that happens on the old site after this point would be missing from the new one.
Take the final copy of the database and uploads after the freeze has started, not before. Keep the new server closed to all web requests at the server level while you import (your host can do this), since a setting inside WordPress is exactly what the import overwrites. Then repeat step 1, and only then open it to your own testing through the hosts file.
Switch over, then turn payments and scheduled jobs on for the new site only. Leave the old site in maintenance mode while DNS spreads, so nobody writes to it by accident.
Recreate any server scheduler. If your old host ran WP-Cron from a server cron job (with DISABLE_WP_CRON set in wp-config.php), the new server needs the same job, or renewals and expirations stop even though the site looks fine (WordPress). Then check that due jobs actually run.
Catch up on missed messages. Stripe retries: it “attempts to deliver events to your destination for up to three days with an exponential back off in live mode”, and you can resend a specific event from the dashboard (Stripe). Check your gateway’s event log for anything delivered to the old site after the final copy, and resend it to the new one.

WooCommerce Subscriptions is blunt about the old copy: “Without completing one of these steps, your old site will continue to process real recurring payments” (WooCommerce). If a plugin paused its own jobs because it saw a URL change, confirm the move in its settings on the new site so expirations and reminders resume.

3. DNS: switch quickly and test before you switch

Lower your DNS TTL a day ahead so the switch spreads fast. Paid Memberships Pro suggests “something like 300 seconds at least 24 hours before the move” (Paid Memberships Pro). If your DNS is on Cloudflare with the orange cloud on, “proxied records have a TTL of Auto, which is set to 300 seconds” already (Cloudflare).

Before switching, test the new server with the real domain by pointing your own computer at it through your hosts file. You see the new site under its real address while every member still reaches the old one. Log in, open a course, check a protected page, then switch DNS.

Leave email records alone during the move. If your mail provider’s records (MX, SPF) are in the same DNS zone, make sure they come across unchanged, and keep them “DNS only” on Cloudflare: proxying is for web traffic.

4. Logins: copy the keys, and replace URLs safely

wp-config.php holds a set of keys and salts (AUTH_KEY, LOGGED_IN_KEY and the rest) that WordPress uses when it signs login cookies. Copy the file’s keys to the new server unchanged. If they change, every member is logged out and has to sign in again. Their passwords still work, but on a busy site a mass logout means a wave of “I can’t get in” emails.

If the domain changes too, the old address is stored all over the database, some of it inside serialized data that breaks if you edit it as plain text. WordPress warns that a raw find and replace “can cause issues with data serialization.” Use a tool that understands it: WP-CLI’s search-replace “intelligently handles PHP serialized data” (WP-CLI), and WordPress’s own example skips the post GUID column: wp search-replace 'example.dev' 'example.com' --skip-columns=guid (WordPress).

Also match the PHP version on the new server to the old one for the move itself. Upgrade PHP afterwards as a separate, tested change, so that if something breaks you know which change caused it.

5. Email: make sure receipts and resets still arrive

Members notice broken email fast: no receipt, no password reset, no course access email. If your site sends mail from the server itself, the new server has to be allowed to send for your domain. Google’s advice for its Workspace customers applies to anyone: “If you start using a new mail server or third-party sender, make sure to update your SPF record.” Otherwise, “messages sent by the new senders could be marked as spam” (Google).

Sending through a transactional email service with an SMTP plugin, rather than from the web server, makes this simpler: the sending service doesn’t change when the host does. Either way, send a real test (a password reset to an outside address) as soon as the new site is live.

6. Course and community data

If you move the whole database in one piece, member progress comes with it. Moving courses or members separately can break progress if the IDs change and the progress records aren’t remapped to match. LearnDash explains why: “The course progress LearnDash stores as part of the user_meta must match the post ID number for the related Course, Lesson, Topic and Quiz” (LearnDash). Paid Memberships Pro makes the same point for course and community plugins generally: completions, quiz scores, forum posts and messages are “tied to one or more ID” (Paid Memberships Pro).

For a host move, copy the full database, not selected courses or users. For BuddyBoss’s app, BuddyBoss says that if “the domain name stays the same, no updates to your BuddyBoss App configuration are required” (BuddyBoss).

Large community sites have big activity and notification tables, which make the database export and import slower. Time a trial run on staging so you know how long the freeze window needs to be.

The migration day checklist

Before

Back up files and database, and confirm you can restore them.
List every webhook your payment gateways have registered, and every gateway setting that references your domain.
Check what your membership plugin does when it’s cloned (see section 1), and never disconnect a gateway on the copy.
Lower DNS TTL to about 300 seconds a day ahead.
Match PHP versions between old and new servers.
Do a full trial migration to staging and time it.
Pick a quiet window away from billing runs and launches, and tell your team about the content freeze.

During

Make sure the new copy can’t take payments or run scheduled jobs yet.
Put the old site in maintenance mode, pause its scheduled jobs and broadcasts, and let any payment in progress finish and check its result.
Take the final copy of files and the full database after the freeze starts. Copy the keys and salts in wp-config.php unchanged.
If the domain changes, run a serialization-safe search and replace, skipping the GUID column.
Test the new server through your hosts file before touching DNS.
Switch DNS, then turn payments and scheduled jobs on for the new site only. Keep the old site in maintenance mode.

After

Log in as a real member (not an admin) and open protected content, a course lesson and the account page.
Browse logged out and confirm protected content stays protected.
Send a test webhook from your gateway and check the site records it, then make a low-value test purchase and refund it.
Send a password reset to an outside email address.
Recreate any server cron job the old host ran, and confirm plugins that paused their scheduled jobs have resumed them. Check that due jobs actually run.
Check your gateway’s event log for messages the old site received after the final copy, and resend them to the new site.
Keep the old copy offline but backed up for a while in case you need something from it.
Watch the first renewal run and your gateway’s webhook log for a few days.

Doing it yourself or handing it off

A small site with one gateway and a quiet week can follow the list above. The risk grows with the number of gateways, active subscriptions and moving parts: a MemberPress site selling LearnDash courses with a BuddyBoss community has three sets of rules to respect at once.

If you’re moving to MemberHost, we handle the move as part of onboarding, and we load test with tools like loader.io and k6. If you’d rather have a developer run the migration wherever you’re going, our sister agency MemberFix offers membership site migrations. Either way, the free site speed audit is a good first step if speed is part of why you’re moving.

Frequently Asked Questions

Will my members’ subscriptions break when I change hosts?

It depends on who runs the billing schedule. Where the gateway manages the subscription, it keeps charging on its own and your site hears about each renewal by webhook, so the job is keeping those messages arriving at one live copy. Where your site manages renewals, as WooCommerce Subscriptions can, the renewals depend on your subscription records, stored payment details and scheduled jobs all arriving intact on the new server and running there, and only there. If the domain changes, reconnect or update the gateway so it knows the new address.

Will members have to log in again after a migration?

On a same-domain move, existing logins usually carry over when you copy the full database (which holds members’ sessions) and keep the keys and salts in wp-config.php unchanged. If the keys and salts change, or the domain does, everyone is logged out and signs in again. Their passwords still work.

How long should a membership site migration take?

As short as you can make it. MemberMouse warns that if a migration “takes more than a short time, recurring billing cycles can be missed” (MemberMouse). Do a timed trial run on staging first, then schedule the real move for a quiet window with a content freeze.

Can I use a migration plugin for a membership site?

Many sites move fine with one, as long as it copies the full database and handles serialized data. MemberMouse is more cautious and says a membership migration “should be done manually and not reliably completed using a migration plugin” (MemberMouse). Whatever the tool, the payment, renewal and login checks in this guide still apply.

Do I need to change anything in Stripe when I move hosts?

If your domain stays the same, the webhook addresses don’t change and Stripe keeps sending to them. If the domain changes, reconnect or update the gateway in your membership plugin so the webhooks point at the new address, and check Stripe’s webhook log after the move.