How to Switch Website Hosts in AccessAlly

Read this before you start

Make a complete backup of your site before you change anything. The backup must include both your files and your database, and you should confirm that it can actually be restored. Keep it until you are certain the new site is working correctly, which may be weeks after the move.

We strongly recommend that a professional, or someone experienced with WordPress migrations, carries out the move. While migrations are not covered by AccessAlly support and we are unable to provide in-depth troubleshooting, we are happy to answer any questions you may have. Any problems caused by a migration would need to be resolved by the site owner or the person who performed it.

A membership site never stands still. Members sign up, renew, upgrade and cancel, your CRM sends updates, and your plugins store new information every day, including while the move is happening. That makes a membership site much harder to move than a brochure site, and a migration can cause problems that nobody expects. Some of the problems we see are:

• Damaged sales records. Many migration and search-and-replace tools change your site address or file paths inside the database. If a tool does this incorrectly, it can damage the stored details of subscriptions, orders and payments. A damaged subscription stops renewing without any warning, and the problem only shows when someone opens that record, so it can go unnoticed for weeks or months.
• Duplicate or missed payments. While two copies of the site exist, both can try to charge your members. A renewal charged on the old site after the copy is made is also never recorded on the new one.
• Lost sign-ups and orders. Anything that happens on the old site after the copy is made does not reach the new one.
• Renewals that quietly stop. AccessAlly charges renewals from a WordPress scheduled task that runs every hour. Some hosts disable or replace WordPress scheduled tasks, and if they are not running on the new host, no renewals are charged.
• Plugin conflicts on the new server. Caching, security and firewall plugins, or the new host’s own security rules, can block payments, logins or the webhooks your CRM sends.
• Access problems. If tags stop syncing between your CRM and the site, members can lose access to content they have paid for.

The steps below reduce these risks. Please read the whole article, including the checks at the end, before you begin.

Plan the move

Choose a quiet time for the move, never during a launch or a busy sales period. While the site is in maintenance mode it will not take new orders or charge renewals, so keep the pause as short as you can while still allowing time to check the results without rushing.

This process assumes you are keeping the same domain name. If you are also changing your domain, read the section on switching domain names at the end of this article as well.

Step 1: Turn on maintenance mode in AccessAlly

During a migration you briefly have two copies of the same site, one on the old host and one on the new host. If both are running, both can charge your members’ recurring payments. Maintenance mode stops AccessAlly from processing payments while you move.

Go to AccessAlly > Settings > General Setup > Migration Tools.

1. Under To Avoid Duplicate Subscription Charges on Staging or Testing sites, tick Only process subscription and recurring payments on the specified site and enter your live site address in Production Site URL, for example https://members.yourdomain.com. A copy of the site running at any other address, such as your new host’s temporary address, will not charge recurring payments.
2. Under Turn On Maintenance Mode – Pause New and Recurring Orders, tick Enable. No new orders can be placed and no recurring payments are charged until you turn it off again. AccessAlly’s scheduled automations also wait until maintenance mode is off.

Turn these on before you make the backup and the copy, so that both copies of the site carry these settings.

Step 2: Make a full backup

Back up your entire site, including the theme, plugins, uploads and the complete database. Your current host may provide a backup tool, or you can use a WordPress backup plugin. Whichever you use, download a copy and keep it somewhere safe outside your hosting account.

This backup is your way back if anything goes wrong, so do not skip it and do not delete it once the move is done.

Step 3: Copy the site to the new host

Use the migration method your new host provides, or the one your migration professional recommends. Many hosts offer a migration plugin or will move the site for you.

Whatever method is used, it must handle WordPress serialized data correctly. AccessAlly stores subscriptions, orders and payments as serialized data, and a plain search and replace on the database can damage those records. If you are unsure whether a tool handles this, ask the tool’s developer or your host before you use it.

This applies even if you are keeping your domain. Some migration tools change your site address to the new host’s temporary address while you test, and then change it back again when you go live. Each of those changes rewrites the site address throughout the database, with the same risk as changing your domain.

Step 4: Check the new copy before you switch

At this point your domain still points to the old host, and the new site will be reachable on a temporary address provided by your new host. On that temporary address:

• Log in as an administrator with your usual username and password.
• Click through your pages and check that the theme and content look right.
• Confirm that maintenance mode from Step 1 is still enabled.
• Run the checks under Before you point your domain to the new host at the end of this article, and compare what you see with the old site.

Then add your domain to the new host’s domain settings so it is ready for the next step.

Step 5: Point your domain to the new host

Log in to your domain registrar and update the DNS settings to point to the new host. Each registrar has its own process, and your new host can tell you which settings to use. DNS changes can take up to 48 hours to reach everyone.

Before going further, make sure you are really looking at the new site. One way that works on any host:

1. Before you change your DNS, log in to the new site on its temporary address and publish a new, empty page with an address such as new-host-check. Do not create this page on the old site.
2. After changing your DNS, visit yourdomain.com/new-host-check. If your site sends logged-out visitors to a login page, log in first.
3. If the page loads, your domain is reaching the new host. If you get a page not found error, you are still reaching the old host, so wait and try again later.
4. Once you have confirmed it, delete the page.

A caching or CDN service in front of your site can keep showing the old site for a while after the change. If the check still fails after 48 hours, ask your new host to confirm the DNS settings.

Step 6: Turn off maintenance mode on the new site

Once you are satisfied that the new site is working on your domain, go to AccessAlly > Settings > General Setup > Migration Tools on the new site. Leave your live site address in place, and under Turn On Maintenance Mode – Pause New and Recurring Orders, untick Enable.

New orders are now accepted and recurring payments resume. Renewals that fell due while maintenance mode was on are not skipped. AccessAlly charges them on its next hourly run, so those members are charged late rather than missed. If maintenance mode was on for longer than a member’s billing period, that member can be charged for each missed period, one after another, as billing catches up. Keeping the pause short avoids this.

Step 7: Shut down the old copy

On the old host, do one of the following:

• Delete the old WordPress installation.
• Cancel the old hosting and ask the host to delete your files.
• Deactivate AccessAlly on the old site.

Maintenance mode should already stop the old copy from charging anyone, but it is safest not to leave a second copy of the site running. Keep your backup from Step 2 even after the old site is gone.

Step 8: Test your CRM webhooks

Make sure your email marketing platform can still reach your site on the new host. Add a test contact to your CRM and put them through an automation with a webhook that runs straight away.

Then go to AccessAlly > Settings > Developer Tools > Detailed Log, choose Show Webhook logs from the list, and check that the webhook arrived. If it does not appear, the call is not reaching your site. A security plugin or a firewall rule on the new host is a common cause.

Switching domain names or site address

If you are changing your domain, for example from members.oldsite.com to members.newsite.com, follow the same steps as above, and also check each of the following:

• Your domain registrar points the new domain to your host.
• The WordPress Address and Site Address in Settings > General use the new domain.
• The Production Site URL in AccessAlly > Settings > General Setup > Migration Tools uses the new domain. If it still holds the old domain, the site will not charge recurring payments.
• A redirect sends visitors from the old domain to the new one.
• Every webhook in your CRM automations uses the new domain.

Changing a domain means changing the site address stored throughout the database, which is where the damage to sales records described at the top of this article comes from. The warning about serialized data in Step 3 applies here as well.

If you are changing your host and your domain at the same time, treat them as two separate moves and check the site fully after each one.

How to check for problems after a migration

Some checks can be done on the new host’s temporary address while maintenance mode is still on. Others only work once the site is live, so they are split into two groups.

Before you point your domain to the new host

1. Compare totals with the old site. Compare the number of members, orders, subscriptions and payments on the old site and the new copy. Any difference needs explaining.
2. Open subscription records. Go to AccessAlly > Sales and open the Subscriptions tab. Open a range of subscriptions: old and new ones, active and cancelled ones, and especially any that were upgraded, downgraded or replaced. Each should open without an error and show the correct Recurring Charge, Next Billing Date and Total Amount Paid.
3. Open orders and payments. Do the same on the Orders and Payments tabs.
4. Check member access. Log in as a test member and confirm they can reach the content they have paid for.

Do not place test orders on the temporary address. Maintenance mode will refuse them, and if it were off, a copy of your site connected to your live payment account could take a real payment.

After the site is live and maintenance mode is off

1. Check that scheduled tasks are running. Go to Tools > Site Health in WordPress. A warning that a scheduled event is late or has failed means WordPress scheduled tasks are not running properly, and renewals will not be charged until that is fixed. If your host has replaced the WordPress scheduler with its own, ask your host to confirm it runs at least once an hour.
2. Watch the first renewals. Over the following days, check in your payment processor that renewals due after the move are actually being charged. A subscription that stays overdue without being charged is a warning sign.
3. Place a test order. Buy something through one of your order forms using a new email address, and confirm the member, the payment and the access are all created. A low-priced product works well. Afterwards, refund the test payment in your payment processor and check the test member’s access.
4. Check webhooks. Confirm in the Detailed Log that your CRM’s webhooks are arriving, as described in Step 8.

These checks will catch many problems, but they are not a guarantee. They can only find problems in the records you look at, and a damaged record can sit unnoticed among many healthy ones. The only reliable way to confirm that nothing was lost or damaged is for a professional to compare the old and new databases directly, including checking that every stored subscription, order and payment record can still be read. If anything in these checks looks wrong, contact us with what you found and we will help you understand what it means.