Migrating from HubSpot to WordPress: a practical playbook

MigrateSpot started as a specialist in exactly this kind of project: moving company websites from HubSpot's CMS to WordPress without losing content, search visibility or the marketing processes behind them. Today it is usually one part of a broader website transformation, but the discipline has not changed.

What follows is the sequence we use. It applies whether the goal is a like-for-like move or a complete rethink of the site.

1. Agree on the goal

Start by writing down why you are migrating. Common reasons include wanting more design or structural freedom, consolidating onto a platform the organisation already uses, reducing dependence on a single vendor, or a broader redesign that the current setup makes difficult.

The goal shapes every later decision. A straight platform move keeps URLs, templates and content as close to the original as possible. A transformation uses the move as an opportunity to rethink structure and story. Both are valid, but mixing them without saying so is how scope grows quietly and deadlines slip.

2. Inventory the site and its content

List every page, blog post, landing page, file and redirect currently managed in HubSpot. Include URLs that are no longer linked but still receive traffic or links, which you can find through Search Console, analytics and a backlink tool. Remember HubSpot-specific content types too, such as HubDB tables, knowledge base articles and system pages.

Then decide what happens to each item: keep, improve, merge or retire. A migration is a natural moment to remove outdated pages, but only once the data confirms they carry no value.

3. Analyse marketing automation, forms and CRM

This is the phase most often underestimated. Moving the website off HubSpot's CMS does not mean leaving HubSpot. Many companies keep the CRM and Marketing Hub and simply change where the website lives. Work out what you actually use and how each part will function afterwards.

• Forms: which forms exist, where they appear, which workflows or lists they trigger, and whether they will be embedded HubSpot forms or native forms that send data to HubSpot.
• Tracking: the HubSpot tracking code must be installed on the new site if you want page views and analytics attributed to contacts.
• Workflows and emails: workflows that depend on form submissions, page visits or list membership need to be tested against the new site. Marketing emails continue to be sent from HubSpot.
• Smart content and CTAs: personalised modules and HubSpot CTAs do not carry over automatically and need a replacement or a deliberate decision to drop them.
• Consent: cookie and privacy consent must keep working with HubSpot tracking on the new platform.

4. Build on staging

Build the new WordPress site in a protected staging environment that search engines cannot index. Work in short, reviewable iterations so the people who will edit the site see it early and can say what they need from the editor.

Content can be moved by export, by API or by hand, depending on volume and how much it will change. Be careful with embedded media and files hosted on HubSpot's file manager: decide whether they move to the new site or stay where they are, and check that every image and download still loads once the new site is live.

5. Migrate URLs and redirects

Wherever possible, keep existing URLs. HubSpot blogs often use URL patterns that WordPress can reproduce with the right permalink settings. Where a URL must change, add a permanent server-side redirect to its closest equivalent, and carry over the redirects already configured in HubSpot so older links keep working.

Test the full list of old URLs against the staging site before launch. Every one should resolve in a single hop to a live page.

6. Launch

1. Freeze content changes in HubSpot shortly before launch, so nothing published at the last minute is lost.
2. Lower DNS time-to-live in advance so the switch propagates quickly.
3. Point the domain to the new host, confirm SSL, and remove any staging noindex rules.
4. Test forms end to end: submission, contact creation in HubSpot, workflow enrolment and notification emails.
5. Submit the new XML sitemap in Search Console and annotate the launch in your analytics.
6. Only then disconnect the domain from HubSpot's CMS, after confirming nothing still depends on it.

7. Support after launch

The weeks after launch decide whether a migration is remembered as smooth. Monitor indexing, crawl errors and search impressions for the pages that mattered most. Watch for 404s in server logs and add redirects where something was missed. Check that leads still arrive in the CRM with the right source information.

Ownership needs to be explicit as well. WordPress needs updates, backups and security monitoring, and someone has to be responsible for them. Editors need training on the new environment, ideally on their own content rather than a generic demo.

Sources

• Google Search Central — Site moves with URL changes: developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
• Google Search Central — Redirects and Google Search: developers.google.com/search/docs/crawling-indexing/301-redirects
• WordPress.org — HubSpot plugin directory listing: wordpress.org/plugins/leadin