HubSpot CMS to Webflow
Migrate from HubSpot CMS to Webflow
Your website moves to Webflow. HubSpot keeps what it is strongest at: the CRM records, the forms behind them, the automation and the attribution. The two stay connected, and the work is the seam between them.
A migration like this usually takes 3–4 weeks
What the migration covers
What moves, and what we figure out first.
What moves
- Website pages and blog content into Webflow pages and CMS collections
- HubDB-powered content modeled and moved wherever it actually belongs
- HubSpot forms embedded or rebuilt with submissions sent back to HubSpot
- Tracking code, attribution and campaign parameters
What we figure out first
- The page count decides the quote. Marketers create landing pages in HubSpot without adding them to anything, so the real inventory comes from HubSpot's own content list rather than from the navigation. It is routinely several times what the team expects, and it gets established before a number is given.
- HubL templates are rebuilt. HubL is HubSpot-specific and does not translate into Webflow.
- Attribution depends on setup after the move. The HubSpot tracking code needs to run on the Webflow domain, and the domain needs to be configured in HubSpot.
Most teams should not leave HubSpot just because they want a different website. The CRM, the forms, the workflows and the reporting can stay exactly where they are. The migration changes who owns the pages, while preserving the handoffs that connect those pages back to HubSpot.
Why people move
What changes when you move from HubSpot CMS to Webflow.
| What is being compared | HubSpot CMS | Webflow |
|---|---|---|
| Content and CRM | HubSpot CMS One platform, genuinely joined up | Webflow Two systems, separated deliberately HubSpot's real advantage, and the thing to weigh hardest. |
| Design control | HubSpot CMS HubL templates and modules | Webflow Components built directly in the site |
| Personalization | HubSpot CMS Smart content, native | Webflow Another implementation, in the browser or in front of it HubSpot wins this. If smart content is load-bearing for you, think carefully before moving. |
| Which one fits | HubSpot CMS When the website and the CRM benefit from staying one system | Webflow When marketing wants the website without replacing HubSpot |
What actually changes
Move the website. Keep HubSpot.
Now
HubSpot
- Website
- CMS
- Forms
- CRM
- Marketing automation
After
Webflow
- Website
- CMS
HubSpot
- Forms
- CRM
- Marketing automation
Once you have decided
What actually migrates.
| What you have | What happens | Why |
|---|---|---|
| Pages and landing pages | Rebuild Made again in Webflow. The old version is a reference rather than something that can be imported. | HubSpot exports the rendered HTML and the template files, which is useful to build against. HubL templates and modules are HubSpot-specific and get rebuilt, so the source is exportable and the implementation is not portable. |
| Blog content | Move Comes across as it is. The content survives the move and the work is transporting it, not remaking it. | Exportable, and mapped into a collection with the dates, authors and addresses carried rather than reset. |
| Forms | Reconfigure The same thing, set up again. Nothing is recreated, but it has to be pointed at the new site by hand. | HubSpot stays the system that receives the lead. Per form it is an iframe embed, a developer embed styled inside Webflow, or a native Webflow form connected back to HubSpot, and the fields and the tracking decide which rather than the design. |
| Smart content and HubDB | Rebuild Made again in Webflow. The old version is a reference rather than something that can be imported. | Neither is only content. A HubDB table, its relationships and the routes it generates get mapped before anybody decides where they land, and personalization needs a decision rather than a translation. Usually the largest single piece of the job. |
| URLs and tracking | Reconfigure The same thing, set up again. Nothing is recreated, but it has to be pointed at the new site by hand. | Public routes are mapped, including the HubSpot-hosted ones, and the tracking code is reinstalled on the new domain and then verified rather than assumed. |
Before you budget it
Where this migration gets complicated.
- 01
Smart content and HubDB are not just content
A HubSpot template can carry conditionals, loops and module logic that looks like static content in the browser, and a HubDB table generates routes as well as holding rows. Each one needs a new implementation decided on purpose rather than a translation, and finding them is the first task.
- 02
A form that submits is not the thing being checked
After the move the contact, the attribution and the workflow all have to arrive correctly in HubSpot. A form creating a contact does not prove the source, the campaign and the browsing context came with it, so what gets checked is the record in HubSpot rather than the button turning green.
The part quotes leave out
How I move it without losing the search footprint.
-
The search footprint is inventoried before anything moves
A crawl shows what the current HubSpot CMS site links to now. Analytics and Search Console show which addresses people and search engines are still reaching, including ones nothing on the site points at any more, so the list is the union of all three. The traffic, the top pages and the queries earning impressions get written down at the same time: without a baseline, a change in how you count and a change in what you get are the same graph.
-
What can stay where it is, stays
Addresses first, then the titles and descriptions attached to them, then the canonicals. Metadata is the easiest thing to lose in a rebuild, because the new site will happily generate something plausible for every page and nothing will report a problem.
-
Everything that changes gets one rule, not a chain
A redirect pointing at a redirect still arrives, so nothing looks broken. Each address gets an intentional destination rather than an inherited one: individual rules where the destinations differ, a pattern where a whole route family changes predictably. The new sitemap goes in at cutover carrying the canonical addresses and nothing else.
-
Every old address is requested after launch and the response recorded
The whole list, not a sample. Looking for anything returning 404 that should not, anything returning 200 that should have moved, and anything taking more than one hop. Then indexing and traffic by landing page for the week after cutover, which is the window included, and longer by arrangement where the site is large enough to warrant it.
None of this guarantees a ranking, and search results can move during a migration for reasons nobody controls. The goal is to change platforms without unnecessarily changing what search engines already understand about the site, and to notice quickly when something did change. Afterwards I watch indexing, what the old addresses return and traffic by landing page, so normal recrawling can be told apart from an implementation problem.
How it runs
Four stages, and what each one looks like.
- Website and CMS Webflow, published without a ticket
- HubL templates and modules Webflow components, rebuilt
- Forms Webflow, still delivering to HubSpot
- CRM, workflows and reporting HubSpot, untouched
- Smart content and HubDB A decision, not a translation
One row moves, one row stays, and the middle three are the seam between them. That seam is the whole project.
-
/blog/post-title/blog/post-title -
/-temporary-slug-abc123/demo-lp/demo -
/hubfs/2021/Guide.pdf/resources/guide -
/blog/topic/pricing/topics/pricing -
/pricing/pricing
Every changed address gets an intentional destination: a direct rule where the mapping is particular, a pattern where a whole route shape moves predictably. These paths are an example of the shape.
- Every form checked at the record, not at the button
- Every template at 1280, 1000 and 390
- Structured data still present on the pages that had it
- Every old URL requested, and what came back recorded
- The analytics baseline written down before cutover
The step most often cut when a quote is being squeezed, and the one that decides whether the failures are found before launch or by somebody using the site afterwards.
Coming from somewhere else?
-
HTML to Webflow
Typically 2–3 weeks
Learn more → -
WordPress to Webflow
Typically 3–4 weeks
Learn more → -
Squarespace to Webflow
Typically 2–3 weeks
Learn more → -
Wix to Webflow
Typically 2–3 weeks
Learn more → -
Next.js to Webflow
Typically 3–4 weeks
Learn more → -
Framer to Webflow
Typically 2–3 weeks
Learn more →
Reach out and see if we are a good fit.
Currently booking two to four weeks out.