HubSpot website migration: move the site, keep the CRM
Can you move your website off HubSpot and keep using HubSpot? Yes. A HubSpot website migration moves the pages, not the customer records. The CRM, contacts, deals, email and most forms stay where they are, and the new site talks to HubSpot through the tracking code and form embeds. What doesn't travel is anything built inside Content Hub: templates and modules built for HubSpot, smart content, HubDB tables, member-only pages and HubSpot's own redirects. Those get rebuilt on the new platform or dropped.
Plan the move feature by feature, keep every URL or redirect it, and check which HubSpot subscriptions you still need before you cancel any. And if the site is modest and marketers run it alone, staying on Content Hub is often the better call.
Checked against HubSpot's help and developer documentation and Alkali's first-hand experience, November 2026.
- A 31-item checklist you can tick off here
- Google Sheets, Word and PDF to hand to your team
- Sourced to HubSpot's docs and our own migration work
What happens to each part of HubSpot
- CRM and contacts
- Unchanged
- Email and workflows
- Unchanged
- Sales pipeline
- Unchanged
- Form submissions
- Unchanged
Stays: nothing to move
The CRM, email, workflows and pipeline keep running as they do today.
- Tracking code
- Install
- HubSpot forms
- Embed or API
- Live chat and meetings
- Embed
- Custom form cookie
- Easy to miss
Connects: set up on day one
The tracking code and form embeds carry visitors and leads from the new site back to HubSpot.
- Pages, blog and files
- New CMS
- Redirects
- Recreate
- HubDB and modules
- Rebuild or drop
- Landing pages
- Stay or move
Moves: rebuilt on the new platform
Anything built inside Content Hub is rebuilt on the new platform or dropped.
What actually changes when the website leaves Content Hub?
HubSpot is several products sold together, and a website migration only touches one of them. Content Hub is the part that hosts and renders pages. The CRM, Marketing Hub and Sales Hub are the parts that hold contacts, run email and track deals. Cancel or downgrade the first and the others carry on.
So the useful question isn't "are we leaving HubSpot?" It's "which HubSpot features does our website use, and which of those live in the page rather than in the CRM?" A form is mostly CRM: the definition, the submissions and the follow-up all live in HubSpot, and the page only displays it. A smart module is all page: it only exists on a page HubSpot hosts. Whether this move is worth making at all is a separate decision, covered in HubSpot vs. WordPress. This guide assumes you've made it and want to know what you're signing up for.
Which HubSpot features keep working on WordPress or another CMS?
Go through the site and list every HubSpot feature it uses. Then check each one against this list.
Tracking code
Works on any site, but only once someone installs it. Add it to every page template on day one. The HubSpot WordPress plugin installs it for you. Without it, page views, form analytics and chat stop.
HubSpot forms
They keep working as embeds. Embed the same forms, or post your own form to HubSpot with the visitor's tracking cookie. Either way submissions still land as contacts.
Live chat
Works on external pages, as long as the tracking code is on them. Check the chat widget appears on staging. If it doesn't, the tracking code is missing from that template.
Meetings scheduler
The scheduling widget embeds on any page. Paste the widget's embed code into the new contact or demo page, or link to the scheduling page.
CTAs
It depends on which CTA tool you use. Current CTAs (pop-ups, banners, slide-ins) show on external pages through the tracking code from Starter up. Legacy CTAs embedded in pages need Marketing Hub or Content Hub at Professional or above, and accounts created after 17 March 2025 don't have the legacy tool. Legacy CTA links on your domain break at cutover. Find every CTA, re-embed or replace it, and redirect or repoint the old click-tracking links.
Blog
Moves as content, not as a working blog. Pull the posts through HubSpot's blog posts API or a migration tool, re-host the images inside each post, and keep the same post URLs.
Landing pages
Can stay on HubSpot if your plan still includes them, usually on a subdomain. Keep campaign pages on HubSpot or rebuild them on the new site. Don't leave the choice to launch week.
Smart content
Smart forms and smart modules stop. Smart CTAs from the legacy tool can still work while you keep Marketing Hub or Content Hub at Professional or above. Decide whether the personalization earned its keep. Most sites can drop it.
HubDB
Tables export, but the dynamic pages built on them don't. Rebuild directories and listings as content types in the new CMS.
Memberships (private pages)
Rebuild the login on the new platform, or move the gated material into a portal.
Templates and modules
They don't run anywhere else. Treat the export as a reference for the rebuild, not something you can install.
HubSpot redirects
They stop working once the domain points elsewhere. Recreate every one on the new host before switching DNS, from the export described below.
The two decisions that need more thought
Forms: embed, or your own form?
Embedding the existing HubSpot forms is the fastest path and nothing in the CRM changes. The cost is a third-party script rendering your most important conversion point, styled by HubSpot rather than by you.
The alternative is your own form posting to HubSpot's form submission API, which keeps the page yours. It only matches what the embed gave you if each submission also sends the visitor's hubspotutk cookie and the page URL. Leave those out and the contact still arrives, but without the page history and source that tell sales where they came from. Don't lean on HubSpot's automatic capture of non-HubSpot forms to cover it either: it only fills single-line text properties and can't be mapped by hand.
Either way, keep the field names mapped to the same HubSpot properties, or workflows that read those fields will quietly stop firing. The broader tradeoff is in CRM website integration.
The blog: move it with the site
It's usually the part of the site with the most search history, and the part with the most URLs. Move it with the rest of the site and keep each post's address the same.
HubSpot offers its HTML export as a way to move content, but most CMSs won't take it directly, so the posts are better moved through HubSpot's API or a migration tool, and the images inside them have to be moved too.
Leaving the blog on HubSpot while the main site moves usually means giving it a new hostname, such as a blog subdomain, which changes every post URL and puts them all on the redirect list.
What breaks quietly when you move off HubSpot CMS?
The obvious things get caught in testing. These usually don't.
Old CTA links
HubSpot's legacy CTAs don't link straight to their destination. They send the click through a tracking URL carrying a cta_guid, and if your primary website domain is connected to HubSpot, that tracking URL sits on your own domain. Those links get copied into emails, PDFs, other pages and sometimes other websites. Once the domain points at the new host, every one of them lands on a page that doesn't exist.
Search the old content and recent emails for cta_guid before launch, and redirect the patterns you can't edit.
File links on your own domain
HubSpot can serve files from any domain you've connected to it, so images and PDFs on a HubSpot site often live at addresses like yourdomain.com/hubfs/ or /hs-fs/hubfs/. Blog post images usually point there too.
At DNS cutover those paths hit the new host and 404, and HubSpot can't redirect file URLs, so the fix is on your side: move the files and add the old paths to the new host's redirect map, or rewrite the links. A datasheet linked from a distributor's site or a quote email is exactly the kind of link hardly anyone checks.
Workflows that depended on a page
Lists and workflows keyed to a page view, a smart content rule or a specific form on a specific page may reference something that no longer exists. Open each active workflow and check what triggers it.
Analytics continuity
HubSpot reports by page. If the tracking code goes in late, or not on every template, there's a gap that looks like a traffic drop and isn't one. Have it on the staging site before launch so you can see it firing.
How do you keep the URL structure intact?
The rule is the same as any platform move: every address that has traffic, rankings or inbound links either survives as-is or redirects to its closest equivalent. The website migration checklist covers that work in order, from inventory to 90 days of monitoring. HubSpot adds four things to that list.
Blog listing pages
HubSpot's blog creates listing pages, such as tag pages and author pages, that a new CMS may not create in the same form. Map them like any other URL.
Redirects built inside HubSpot
Redirects you've built inside HubSpot over the years stop working the moment the domain points elsewhere, so they go on the new host's list too. The export is covered below.
File paths and legacy CTA links
The /hubfs/ file paths and legacy CTA links described above need redirect entries of their own.
Hostnames
If landing pages stay on HubSpot, they need their own hostname, usually a subdomain HubSpot can keep serving. That doesn't happen by itself. Before you disconnect the main domain in HubSpot's Settings > Content > Domains & URLs, move its primary content types, such as website pages and landing pages, to the subdomain that stays. HubSpot's own documentation says that if you don't, a system domain will be used instead.
What do you keep paying HubSpot for?
Whatever the business still uses: the CRM, plus whichever Marketing Hub or Sales Hub tier runs your email, workflows and pipeline. What can change is Content Hub. If the website was its only job, the move may let you drop it or reduce its seats.
Timing matters more than most teams expect. HubSpot doesn't allow downgrades in the middle of a contract term, so plan the cutover against the renewal date, not the other way round.
Export everything
FirstHubSpot recommends exporting page content and redirects before downgrading, and it's much easier while everything is still switched on.
Fix the launch date
Before the notice deadlineHave the new site live, or its launch date certain, before you give notice, so you don't renew Content Hub for another year by accident or downgrade a site that is still live on it.
Give notice
5 business days before renewalHubSpot asks for at least five business days' notice before the renewal date: a support ticket on Starter, your HubSpot Contract Manager on Professional and Enterprise. Give it once the launch date is firm.
The downgrade takes effect
Renewal dateDropping Content Hub to the free tools, or Marketing Hub from Professional or Enterprise to Starter or the free tools, removes access to the URL redirects table. The Marketing Hub downgrade also stops HubSpot CTAs working.
Some pages are unpublished
90 days laterDropping Content Hub Professional or Enterprise to Starter or the free tools unpublishes dynamic, private, password-protected and HubDB-driven pages after 90 days.
Before the downgrade lands, check which of your remaining features came from Content Hub. Blog, landing pages, HubDB and memberships can sit in different products depending on your plan and when you bought it, so check your own subscription rather than a pricing page.
How do I export everything from HubSpot?
Five separate exports. Run them all before you switch DNS or downgrade anything.
| What | Where | What you get |
|---|---|---|
Website pages, landing pages and blog postsHTML | The Actions menu on each dashboard: bulk HTML export | An emailed link to one package of every page or post, with template files in a Styles folder |
Blog post dataSpreadsheet | The Blog dashboard | A spreadsheet (CSV, XLS or XLSX) |
HubDB tablesCSV | Each table's Actions menu | A CSV per table |
URL redirectsCSV | The Export button on the redirects table | A CSV. Recreate every row on the new host before cutover: HubSpot's redirects only run on domains it hosts, and some downgrades remove access to the table |
FilesZIP | Content > Files, then Export (ZIP). Super admin only | An emailed ZIP of the files, but not a map of where each one lived. Match old /hubfs/ paths with HubSpot's Files API, which returns each file's URL, or a crawl of the old site |
What you get is a snapshot to rebuild from. The HTML shows exactly what each page said and how it was structured, which makes the content migration far less guesswork. Most CMSs won't import it directly, though, so to load posts into a new CMS, HubSpot's blog posts API or a migration tool is the better route. The templates are HubL (or HubSpot's React modules) and won't run anywhere else. Keep the full export somewhere safe after launch. It's the only complete record of the old site once Content Hub is gone.
The HubSpot cutover checklist
Tick items off as you go. Your progress saves in this browser. For the team, copy the same list into your own Google Sheet, or download it as Word or PDF.
The HubSpot cutover checklistbyalkali.com/resources/hubspot-website-migration/- 0/7
Before the build
Decide what moves, what stays and what gets dropped.
- 0/7
Export, while everything is switched on
- 0/13
Before cutover
- 0/4
After cutover
When is staying on Content Hub the better call?
More often than the people selling rebuilds say. Two reasons are specific to the move itself:
The site leans on smart content, HubDB or memberships
Every one of those is a rebuild, not a migration. If the site depends on all three, the move costs far more than the page count suggests.
The real problem is the message, not the platform
A site that doesn't say clearly what the company makes won't say it any better on WordPress. If the headline, the capability pages and the quote path are what's failing, rewrite them where they are, which costs a fraction of a migration and carries none of its risk.
The broader platform fit, such as who runs the site, whether a developer is available and what's on the roadmap, is set out in HubSpot vs. WordPress. If that comparison points to moving, the CRM your sales team relies on doesn't have to change at all.
We build marketing websites on both HubSpot Content Hub and WordPress, so either answer can be the right one. What matters is knowing which features you'd be rebuilding before anyone quotes the rebuild.
Sources
- Export web content and dataknowledge.hubspot.com
- Create and manage URL redirectsknowledge.hubspot.com
- Downgrade a paid subscriptionknowledge.hubspot.com
- Cancel or downgrade (contract terms)knowledge.hubspot.com
- Delete a subdomain in the domain managerknowledge.hubspot.com
- Connect a domain to HubSpot (email content type)knowledge.hubspot.com
- Install the HubSpot tracking codeknowledge.hubspot.com
- Use non-HubSpot formsknowledge.hubspot.com
- Resolve unsafe CTA link errors (legacy CTAs)knowledge.hubspot.com
- Smart content FAQknowledge.hubspot.com
- Organize files with folders (file export)knowledge.hubspot.com
- Form submission API (hutk, pageUri)developers.hubspot.com
- Add CTAs to your pages (current CTA tool)knowledge.hubspot.com
- Create and manage HubDB tablesknowledge.hubspot.com
- Require member registration (private content)knowledge.hubspot.com
- Create a live chatknowledge.hubspot.com
- Embed the meetings widgetknowledge.hubspot.com
- Blog posts APIdevelopers.hubspot.com
- Files APIdevelopers.hubspot.com