Migrating from Hubspot CMS to  WordPress

Step-by-step guide for moving a website from HubSpot CMS to WordPress without losing data or design integrity.

/

HubSpot CMS is an option for certain situations, but in many cases it’s less than ideal.

Working with a closed system eventually limits what businesses can achieve, and it tends to be expensive for what it offers. If you’re migrating a site from HubSpot to WordPress, there are many ways to go about it. WordPress is a tremendously flexible system, and this can be a major benefit, or it can lead to problems.

With the right approach you can rebuild your HubSpot website with WordPress in a very professional way that is easy to work with and highly stable over the long term. It involves building a custom theme with the right approach, and in this guide I’ll walk through the methods I’ve found to be highly effective based on my own experiences.

The goal is translating what you have in HubSpot into the most effective WordPress publishing system. WordPress’s flexibility is its greatest strength and biggest risk—powerful in the right hands, chaotic in the wrong ones.

Table of Contents

WordPress Theming Concepts

It goes without saying, but you’ll need to know how custom themes are built in WordPress. This includes all aspects of building a good one. This is a detailed topic I won’t go into here, but I have a very comprehensive article covering all aspects for reference: Building Custom WordPress Themes with ACF.

Handling Fields with ACF

Fields in HubSpot CMS define the editable parts of a module, such as text, images, colors, or buttons.

Developers create these fields in the module editor or in the module’s JSON configuration. Each field is tied to a specific element in the module’s layout, like a headline field for a title or an image field for a background photo. Fields let marketers customize the content of each module instance while keeping the design and structure consistent.

ACF Pro (Advanced Custom Fields Pro) is a WordPress plugin that lets developers add custom fields to posts, pages, and custom post types. These fields define the editable content areas inside WordPress templates, such as headlines, images, buttons, colors, or repeatable sections. It’s the reason WordPress is the #1 CMS in the world today.

It works similarly to HubSpot CMS fields, and in fact HubSpot developers used it for inspiration when building their fields UI. Developers create field groups and assign them to specific pages or content types. Each field connects to a spot in the template, allowing non-technical editors to change that content without modifying the code. This approach separates design from content, making WordPress templates flexible and easier to maintain while preserving a consistent structure.

Replicating Modules in a Custom WordPress Theme

Modules in HubSpot CMS are reusable blocks that make up a page’s layout. Each module handles a specific part of the page, such as a banner, form, or image gallery.

Developers build a module once and store it in a central library, but each time it’s placed on a page it can be configured differently. Marketers can adjust fields such as text, images, colors, or buttons for each instance without touching the code. The design and structure stay consistent across the site, while the content in each module can vary page by page. If the module’s code is updated in the library, every page using it inherits the change to its layout or styling without affecting the unique content set for each instance.

The bulk of a HubSpot CMS powered website is made up of modules, it’s probably the most important aspect to get right when migrating. I’ve found the following two approaches to be best for certain scenarios. Of the two I prefer the ACF Pro flexible content approach because it separates content from design in a clean way.

Creating Gutenberg blocks is good too, but it can be overly difficult to maintain consistency in terms of how sections of a page flow from one to the other. With Gutenberg you’re also building page by page, even if those pages are made up of blocks the way WordPress stores those blocks is, in my opinion, poorly thought out and can lead to issues when block APIs change in core updates.

Flexible Content Fields (ACF)

HubSpot modules can be directly translated to WordPress using ACF Pro flexible content fields. They let you build reusable page sections called layouts. Each layout has its own fields (text, images, buttons, etc.) that editors can add, reorder, and customize per page.

To replicate HubSpot modules, define layouts for each section type—hero, gallery, testimonials—and loop through them in your theme template. Editors drag layouts into any order, fill in the fields, and publish. Updating a layout’s code or style updates every page that uses it while keeping each page’s unique content intact.

Registered Gutenberg Blocks (ACF)

Another option for replicating modules in WordPress is to use ACF Gutenberg blocks. Each block acts as its own reusable section — like a hero, testimonial, or call-to-action — with custom fields for text, images, and other content.

Editors can insert these blocks anywhere on a page, reorder them, and configure the fields for each instance. The design stays consistent across the site, while content remains unique to each page. Updating the block’s template or styling updates every instance automatically, much like updating a module in HubSpot.

Using Page Builders (Not Recommended)

Several page builders attempt to offer a modular workflow similar to HubSpot. The most popular options are Bricks, Elementor, and Divi. While they can speed up early development, they add an extra layer of complexity on top of WordPress itself.

Bricks

In Bricks, you visually build reusable sections and templates inside its proprietary theme builder. You drag elements like text, images, and sliders into a canvas and save them as reusable templates or components. While flexible, the content and structure live inside Bricks’ own system, which locks you into its framework.

Elementor

In Elementor, you create templates or “sections” by dragging widgets into a front-end editor. These sections can be reused across pages, with settings to adjust content and style per instance. However, the layout and logic are tied to Elementor’s proprietary interface and stored outside of native WordPress templating.

Divi

In Divi, you build layouts with a visual editor that uses Divi-specific modules. Templates and global elements are managed through Divi’s interface, separate from WordPress’s core theme system. Like the others, Divi saves data in its own way, which makes migrating or debugging more difficult later.

Page Builders

All three tools create a tool within a tool problem. Instead of extending WordPress’s native system, they replace it with their own editors, storage methods, and APIs. This leads to heavier sites, slower performance, and long-term maintenance headaches when APIs or the builder itself changes.

ACF is different. While technically a plugin, it integrates directly with WordPress core and stores data in standard ways. It’s widely adopted and considered a core part of modern WordPress development. This makes ACF the most reliable choice for replicating HubSpot-style modules without adding unnecessary layers or risking lock-in.

Content Migration

The best approach for migrating content depends on the size of the site you’re migrating. There are really two approaches I typically take.

Manual Migrations for Smaller Sites

Manually copy content over after you’ve created a system for handling modules in WordPress. For a smaller site, this is often the simplest approach.

HTML Exports to Custom Page Templates

HubSpot provides a way to export web content and data as HTML. This includes pages, blog posts, template files and knowledge base articles.

Let’s be honest, a lot of sites don’t need content management. Sometimes pages go years without ever changing, and in other cases developers are asked to make updates to content with CMS tools they built. The HTML export tool isn’t ideal for exporting structured content, which is really what you’d need to truly migrate content from one CMS to another.

But… if the website you are migrating is mostly static, this approach is an excellent option:

  1. Export all your HubSpot content as HTML
  2. Create WordPress partial templates for the global elements that are shared globally (header, menu, footer, etc.)
  3. Create WordPress custom theme templates using the HTML specific to a certain page
  4. Move your JS and CSS that powers HubSpot pages into your theme and load it with wp_enqueue_script

This is a crude approach, there are definitely downsides, but in a situation where speed is preferred and a site will likely remain static, it’s by far the most effective way to go.

The downside is that your modules aren’t really modular anymore, you lose the ability to modify a single module template and cascade those changes across all uses of it. If you’re working on a corporate website with strict requirements like accessibility, security, or brand guidelines this may be a bad approach to take.

Moving Lots of Content

The CMS API can return HubSpot content as structured JSON, which makes it easier to move large volumes of posts, pages, and media into WordPress. Developers often pair the API with WP-CLI to automate imports, preserving fields like titles, authors, dates, slugs, taxonomies, and custom fields. Media files can be downloaded and remapped so links and alt text stay intact.

This approach works well when there’s a clear one-to-one mapping between HubSpot’s content types and WordPress post types or ACF fields. It tends to be worth the effort for sites with hundreds of items or complex relationships because the process can be repeated, logged, and rolled back.

Web Scraping + AI

For some sites, it’s simpler to crawl the live pages and capture the rendered HTML. A scraper can collect titles, headings, metadata, links, and images, while AI can help separate the content into reusable fields or sections. This method captures what visitors actually see — including SEO tags, Open Graph data, and visible sections — even when no API access is available.

It’s often better suited for smaller sites or those with inconsistent structures. While it can pull everything in one pass, it usually requires extra cleanup and validation since the scraped data isn’t as neatly structured as API output.

If you’re using the search in HubSpot you’ll definitely find that it’s better than the standard WordPress search. But WordPress can in fact be much better. I typically recommend and use the Relevanssi plugin, which provides a framework for creating a weighted search index for a WP site. It can be set up quickly, especially if you have existing templates to work with, but also has advanced capabilities like PDF content indexing to replicate and customize search in any way needed.