A membership website on WordPress is rarely just WordPress. There’s a membership plugin, usually MemberPress or WooCommerce Memberships, handling the logins and payments, plus a forms plugin, an events plugin, an SEO plugin and a few more that were installed for a reason someone has since forgotten.
Each one keeps its own copy of the member. Moving the site to HubSpot means the website and the CRM share one record for each person.
The move is also where things break. Links stop working and members can’t log in, and if the redirects are wrong the search rankings go with them.
Start with what the plugins were doing
I list every active plugin and write down the job it does. Each job then gets a new home in HubSpot or an integration, and now and then the answer is nothing at all, because the job stopped mattering years ago.
On most membership sites the list looks familiar: MemberPress or WooCommerce Memberships for access and payments, Gravity Forms or Contact Form 7 for forms, The Events Calendar for events, Yoast for SEO, and the Redirection plugin holding years of redirects that somebody added one at a time.
The membership plugin is the big one. It usually decides who can see what and takes the payments, and on a lot of sites it sends the renewal reminders too.
In HubSpot those jobs split up. Access moves to HubSpot’s memberships feature. The money goes through Stripe or GoCardless, and renewals run from workflows, which I’ve written up in How I set up HubSpot to run membership renewals.
Forms move across without much fuss, though events plugins are harder, which is partly why I built EventEngine.
Getting the data out of WordPress
The members come out of the membership plugin as a CSV. MemberPress and WooCommerce Memberships will both export one, and the columns I care about are email, plan, status, start date and expiry date.
WordPress users are a separate export, and they rarely match the members list. Old accounts, admins, the original developer’s test logins and people who once registered for an event all live there too, so I compare the two before anything gets imported.
Blog posts come out through WordPress’s own XML export, which HubSpot’s blog import can read. Pages I rebuild in the HubSpot theme, because an imported WordPress page drags years of shortcodes and page-builder markup along with it.
Getting it into HubSpot
The member CSV goes in as a contact import, with each column mapped to a property: membership status, join date, renewal date and tier, the same ones I use in How I set up HubSpot to run membership renewals. Email address is the matching key, so I sort the duplicates out first.
Organisation memberships also need each contact associated with their company, which is easy to miss when the CSV only has the company name sitting in a text column.
Consent comes across with the members. Each imported contact needs its email subscription status and lawful basis set, or the first newsletter goes to people who never agreed to get it.
Images and PDFs go into HubSpot’s file manager, and the internal links in the imported posts get updated so they stop pointing at old /wp-content/ paths.
Member-only PDFs need a second look. A file a membership plugin “protected” can often still be opened by anyone with its /wp-content/uploads/ link, and in HubSpot’s file manager a file is public unless it’s set to private.
Subscriptions that are already running
This is the one I check twice. When MemberPress or WooCommerce sets up a recurring payment in Stripe or PayPal, it’s usually WordPress that receives the webhooks saying the payment went through.
If WordPress goes read-only before those subscriptions are moved, renewals either stop being collected or get collected with nowhere to record them. So the webhooks get repointed and the subscriptions connected to HubSpot while the old site is still running.
Member logins
HubSpot’s memberships feature puts pages or a whole knowledge base behind a login, and works out who gets in from a list in the CRM. I’ve used it for IIGCC’s member area, and for AUMA, where UK water companies log in to a private knowledge base.
The catch is passwords. WordPress stores them in a form HubSpot can’t import, so every member has to set a new one.
That email needs as much care as anything else in the move. I write it early and try it on a handful of friendly members first. The rest go out in batches, so the support inbox doesn’t fill up in a single morning.
Before it goes out, I check SPF and DKIM are set up for HubSpot on the organisation’s domain. A password email that lands in spam fills the support inbox just as quickly.
The redirect map
Every URL on the old site needs somewhere to go on the new one. Pages and posts are the obvious ones. The ones that get missed are PDFs sitting in /wp-content/uploads/ and old category and tag pages.
Links from other sites matter as well, because a partner organisation may have been pointing at the same page for years. I build the map from a crawl of the old site plus the pages Search Console and analytics say people land on (I’ve got a soft spot for a good redirect map, which probably says a lot about me).
HubSpot takes redirects in bulk from a CSV, and a pattern-based rule can cover a whole /category/ folder in one line.
Some files aren’t pages at all. On Onefile’s move, the security.txt file their ISO 27001 auditors look for had to be put back at exactly the right path, and that kind of thing tends to get noticed only when an audit asks for it.
Keeping the search rankings
Rankings survive a move when as little changes as possible. I keep URLs the same wherever HubSpot allows and carry the titles and meta descriptions across as they are.
Rewriting them can wait until a few weeks after launch, when there’s data to compare against.
For the first fortnight I check Search Console for 404s every day, and there are usually a few to tidy up.
The weeks between export and launch
A build takes weeks, and the WordPress site carries on while it happens. Someone publishes a news story on the old site. Members join and lapse.
So I agree a content freeze date with the team. Anything published on WordPress after it gets logged, so it can be added to HubSpot by hand before launch.
Members can’t be frozen. On launch day I take a fresh export from the membership plugin and compare it with HubSpot, looking for anyone who joined or changed status since the first import.
I run both files through Claude for that comparison. It lists who’s new and whose status has changed, and I import the difference.
Launch day
The switch itself is a DNS change, which is the old webmaster part of the job. I drop the TTL the day before so the change goes through quickly, and HubSpot issues the SSL certificate once the domain points at it.
Once it’s live, I work down a short list before telling anyone:
- the final member import from the launch-day comparison
- a login as a test member, and a test payment
- every form submitted once
- the redirect list run through a checker, so every old URL lands somewhere
- the staging site’s noindex setting switched off, and the sitemap submitted to Search Console
- the analytics tag and cookie banner checked, so launch week doesn’t show a traffic dip that isn’t real
The WordPress site stays up somewhere private and read-only for a month or so. Someone always asks for something from it.
If your membership site is still on WordPress and the plugin list keeps growing, book a call and talk me through what’s driving you mad.
