/handbook/hubspot-to-wordpress-migration/frontend-migration/
What We Do
Digital Platform MigrationsKey SolutionsManaged ServicesStaffing SolutionsIndustriesProducts
Discovery
Strategic consultancy & project roadmap
Growth Services
On demand development & consultation
Site Maintenance
Annual maintenance. Done for you
QE Services
Testing across SDLC for assured quality
Hosting Migration
Move to a performant hosting with zero downtime
WooCommerce
Enterprise commerce delivered without lock-in
AI
Unlock real use cases and integrations
All Services
A suite of services for any need
Technology STACK
eCommerce
Scale your e-commerce with WooCommerce, integrations, and custom extensions for growth.
EasyEngine
Server management tool that makes using WordPress on Nginx easy.
Web Auditor
Performance Audit & Insights for your Website.
rtMedia
A complete media management plugin for WordPress.
Resources
About Us
CLEAR
Resources HubSpot to WordPress migration guide Frontend migration
Topics
On this page
- HubSpot to WordPress migration guide
- Planning the migration
- Pre-migration & discovery
- Frontend migration
- Content migration
- Backend migration
- Quality assurance
- Launch & post-migration
- How can rtCamp help
Audit your existing frontend and documenting your design
Mapping design elements for frontend migration
Choosing among a custom theme, a block-based FSE setup, or a page builder
A custom theme
Block-based Full Site Editing (FSE)
Page builder
The best approach? Generally… it’s hybrid.
Planning for multisite? Consider a shared design system
Wrapping it up…
Last updated on Apr 1, 2026
Migrating the Frontend
When you move from HubSpot to WordPress, migrating the frontend isn’t just about recreating what your site looks like today. It’s about building a system that empowers your marketing team, designers, and developers to run with it for years to come.
At rtCamp, frontend and backend work always move in parallel in CMS migration projects. Our frontend engineers focus on recreating the frontend while our backend engineers work simultaneously on rebuilding the systems that power it. We plan and build both layers together.
So on the frontend side, when migrating from HubSpot to WordPress, we start with a thorough audit of your existing site. We sit with spreadsheets, screenshots, and real device tests, because there’s no solution to do this “automagically.”
Once the audit is complete, our team turns that spreadsheet into a practical spec: reusable blocks, locked design patterns, global styles, and theme structures that balance creative freedom with governance. Whether the final build is a handcrafted custom theme, a Full Site Editing setup, or a carefully gated page builder hybrid, the same principle holds: every piece must be deliberate, maintainable, and consistent, not just on launch day but six months later when your marketing team needs to spin up a last-minute campaign.
In the sections that follow, we’ll break down exactly how we approach each stage of our HubSpot to WordPress frontend migration process, from manual audit to design system mapping, to building reusable blocks and ensuring your final WordPress frontend performs as well as it looks.
Audit your existing frontend and documenting your design
If there’s one lesson we’ve learned building WordPress frontends for enterprises moving off platforms like HubSpot, it’s this: the biggest surprises aren’t in the backend, but hidden in plain sight, in your design and frontend logic:
- Most marketing teams underestimate how much “custom” actually lives in their HubSpot theme.
- It’s easy to think “We just have a few landing pages and a blog.”
- But under that, you’ll find hundreds of design elements: hero banners, testimonial sliders, pricing tables, custom forms, dynamic CTAs, and more, each with its own design quirks (interactions, breakpoints, etc.).
And even after 300+ migrations (across every CMS you can name), we’re yet to find a magic solution that automatically audits your existing CMS’s frontend, here, your HubSpot theme, and get it to give you a ready-made blueprint to migrate it to WordPress.
This part is MANUAL.
You need to return to the good old spreadsheet.
At rtCamp, when we kick off a HubSpot to WordPress migration (or any frontend migration for that matter), our frontend migration team doesn’t dive straight into plugins or page builders. We open your site, page by page, and map exactly what makes your design: everything from the layouts and hero elements to the smallest elements that live on it and need to make it to the new build. Of course, we document your styling as well (brand colors, typography, etc.).
Here’s what we always capture when conducting a frontend audit:
- Page templates & layouts: We map every unique page type (from your homepage hero to your deepest gated resource). It’s surprising how many hidden templates live behind form redirects or nurturing workflows.
- Reusable modules & partials: HubSpot’s module system often creates reusable design blocks: team cards, event listings, CTAs, etc. These must be rebuilt as WordPress blocks, patterns, or shortcodes. You also need to know the ones that are global.
- Design tokens & brand system: Colors, typography, iconography, spacing. Many organizations discover, mid-migration, that they never codified these properly. Migrating to WordPress is the perfect opportunity to define a true design system – one that can scale to multisite, if needed.
- Scripts, libraries, and interactive bits: That slick slider in your hero? The sticky nav? That parallax effect on the blog page? These details live in your frontend’s JavaScript and CSS. All these details also need to be documented.
- Responsive behavior: We always test layouts across breakpoints and devices. How does the nav collapse? Do buttons resize? Are there hidden mobile-only tweaks that content teams rely on? All these notes make it to the frontend documentation.
- Performance & accessibility baseline: Before you rebuild, run a Lighthouse audit on your key pages. Note where you stand today: page weight, render-blocking scripts, Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and other core vitals. This gives you a clear benchmark, and your new WordPress frontend should aim to be leaner, faster, and more stable. Likewise, audit your current site’s accessibility and document how well it supports keyboard navigation, screen readers, color contrast, WCAG criteria, and other other regulations/laws that might apply to you. This exercise helps ensure your rebuild can improve or at least maintain your current accessibility.
⚠️ Too many CMS migrations get stuck in a dangerous gap when it comes to migrating the frontend: They have a design file says what the new build should look like, but not how it will actually be built or maintained (so it’s actually usable and futureproof). This spreadsheet bridges that gap.
So yes, this process is manual. But it’s worth every effort. Because this is where your HubSpot site stops being a black box and translates a well-documented, modern WordPress frontend that your teams can actually own.
Mapping design elements for frontend migration
So the spreadsheet you just built is your frontend’s source of truth and directs the entire frontend migration for your HubSpot to WordPress rebuild.
And it’s not just about copying a design pixel by pixel. You’re translating how every piece of your current frontend works into something WordPress can handle in a way that’s cleaner, more sustainable, and more flexible for the people who’ll use it daily.
So here we take that audit and expand it. Every design element (a testimonial carousel, a pricing table, an icon grid) gets mapped to how it will be rebuilt:
- Will it be a custom block in Gutenberg?
- Does it become a reusable block pattern your content team can drop in anywhere?
- Should it be locked down so only a developer can touch it?
If you go with the Full Site Editing approach (which we’ll discuss in just a bit), this spreadsheet you’re building will power your theme.json and block.json files that will set your new WordPress site’s global and block level styling. It will decide how your design tokens (colors, typography, spacing) live in a single source so no one’s guessing what shade of blue is “on brand.”
If instead of Full Site Editing, you decide to go with a custom theme, the spec becomes your theme brief.
And if you go with the page builder approach, this spreadsheet will tell you where it makes sense to allow drag-and-drop freedom and where it absolutely does not. Maybe your brand homepage could be hard-coded (locked in your theme or your FSE template parts) while your landing pages live in a builder sandbox. The audit ensures everyone knows which is which.
Choosing among a custom theme, a block-based FSE setup, or a page builder
Once you know what you have, the next step is deciding how to rebuild it in WordPress. You’re usually choosing from three broad approaches:
- A fully custom theme
- A block-based Full Site Editing (FSE) setup
- Or a page builder solution
Each has its place. Each has trade-offs. And each shapes how your marketing and dev teams work after launch, which is where the real cost or savings emerge.
Let’s unpack each.
A custom theme
A custom WordPress theme is exactly what it sounds like: a new built-from-scratch theme, designed and coded specifically for your brand, UX, and content needs.
What this means:
Your developers build every template, layout, block, and style from the ground up. You have full control over HTML structure, CSS frameworks, JavaScript, and how content editors interact with blocks in the Gutenberg editor.
When this makes sense:
- You have unique design requirements like layouts, components, or branding that off-the-shelf blocks or page builders can’t replicate well.
- You need tight control over performance and accessibility. A hand-coded theme removes bloat, avoids redundant scripts, and ensures your markup meets accessibility standards.
- You want a lean, maintainable codebase, something your dev team can fully own, extend, and keep stable for years, without depending on proprietary plugins or vendor lock-in.
We see enterprise clients benefit most when they treat their theme as a design system, pairing reusable custom blocks with a clear pattern library so the marketing team still gets flexibility without needing constant dev support for every change. At rtCamp, this is exactly how we approach our visual design.
Block-based Full Site Editing (FSE)
Full Site Editing (FSE) is WordPress’s modern approach that expands the Gutenberg block editor beyond page content and almost makes it double up as a website builder, letting you build headers, footers, sidebars, and templates using blocks.
What this means:
Instead of hard-coded PHP templates, your theme is made up of blocks and patterns. Non-developers can adjust layouts and global elements visually, inside WordPress itself.
When this makes sense:
- Your content or marketing teams want true self-serve flexibility to spin up new layouts or sections without developer bottlenecks.
- Your site design is consistent and modular enough that blocks and patterns cover most use cases.
- You’re building on modern WordPress and want to future-proof your frontend for Gutenberg’s evolution.
FSE works best when paired with strong design governance. We help clients build a locked-down pattern library inside FSE, giving marketers the freedom to compose pages safely without risking brand drift or messy code. If you don’t put guardrails in place, it’s easy for an FSE-driven site to turn chaotic as different editors tweak layouts in conflicting ways.
Page builder
Finally, you’ve page builders (like Elementor, Beaver Builder, or WP Bakery) that give you drag-and-drop visual editing. They add proprietary blocks, style controls, and UI layers on top of WordPress’s core editor and empower you to recreate your HubSpot design on WordPress and do a lot of the heavy lifting too.
What this means:
With page builders, your marketing team can build complex page layouts fast, with minimal coding. Many SaaS businesses use page builders for landing pages and rapid A/B testing.
When this makes sense:
- You need to launch quickly with minimal developer involvement.
- Your site structure changes often (new pages, short-lived campaigns).
- Your editors want “what you see is what you get” drag-and-drop design, even if it trades some performance.
Page builders solve real speed and resource constraints but can come with technical debt. Many produce bloated markup that can hurt performance if you’re not careful. Generally, for high-scale sites, page builders are best used for specific marketing campaign sections, not for the entire site’s core templates.
The best approach? Generally… it’s hybrid.
Many enterprise migrations use a hybrid approach. For example:
- A core custom theme with reusable Gutenberg blocks for brand consistency.
- A curated pattern library using FSE for marketers to mix and match sections.
- A lightweight page builder for only landing pages or tests, not core site templates.
This way, you get the best of all worlds (performance, governance, and speed to launch) without locking your whole frontend into one rigid paradigm.
Planning for multisite? Consider a shared design system
If you’re migrating to WordPress and you know a multisite setup is part of your roadmap (or you even suspect it might be), you’ll want to think bigger than just recreating a single site’s frontend.
Why?
A multisite network lets you manage multiple sites (brands, regions, products, or divisions) all under one WordPress installation or through a network of connected sites. It’s a huge operational advantage for enterprises with regional microsites, franchise portals, or brand families.
But here’s the reality: if you rebuild your frontend for such a migration as a one-off theme without thinking about reuse, you’ll end up repeating design work multiple times over, often resulting in inconsistent branding.
Here’s how we solve this problem through design system centralization:
Wrapping it up…
At rtCamp, we believe that your frontend migration isn’t just about your site pixel-for-pixel.
Instead, it’s your chance to build a design system that’s modern, modular, and genuinely empowering… for your developers who maintain it, your designers who evolve it, and your marketers who run campaigns on top of it.
When you get this balance right, your new WordPress frontend doesn’t just match your old HubSpot site, it beats it, day after day.
And because it’s built on open standards, with your team in control, it keeps getting better, on your terms, not your vendor’s.
Pre-migration & discovery
PREVIOUS
Credits
Disha Sharma
Author
Disha Sharma
Author
Disha Sharma is a Content Writer at rtCamp with over a decade of experience at the intersection of technology, digital marketing, and enterprise content strategy. Her WordPress roots run deep, her …
Good Work. Good People.
Industry partnerships
Compliance certifications
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Company
Solutions
Subscribe to our newsletter and get a few email updates every month.
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Cookie Consent
We value your privacy
We use cookies to give you the best possible experience. By clicking “Accept,” you consent to our use of cookies to improve site functionality, analyze usage, and personalize content and communications. Your privacy matters to us, and we are committed to handling your data responsibly and transparently. Please check our Privacy Policy for more details.
Manage PreferencesDon’t AllowAllow All
Why do we use cookies?
×
By clicking "Accept" or "Decline All" at the bottom, you consent to the use of cookies and other tools as described in our Cookie Policy in accordance with your settings and accept our Terms of Service.
Toggle EssentialEssential
Essential cookies enable basic functions and are necessary for the proper function of the website.
Name
Description
Duration
Geolocation Config
This cookie is used to store the consent settings based on the visitor's location.
30 days
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
Toggle CloudFlareCloudFlare
CloudFlare provides web performance and security solutions, enhancing site speed and protecting against threats.
Service URL: developers.cloudflare.com (opens in a new window)
Name
Description
Duration
cf_clearance
Whether a CAPTCHA or Javascript challenge has been solved.
session
Toggle CommentsComments
These cookies are needed for adding comments on this website.
Name
Description
Duration
comment_author
Used to track the user across multiple sessions.
Session
comment_author_email
Used to track the user across multiple sessions.
Session
comment_author_url
Used to track the user across multiple sessions.
Session
Toggle GodamGodam
GoDAM" is primarily a specialized WordPress plugin and media management service designed to enhance video hosting, marketing, and asset management directly within the WordPress dashboard.
Service URL: godam.io (opens in a new window)
Name
Description
Duration
user_image
Temporarily stores the path to the user's avatar or profile picture for quick rendering in the website header.
session
user_id
Stores the numerical ID of the logged-in user to maintain session continuity and basic site operations.
session
full_name
Stores the logged-in user's display name to personalize the site interface without needing database queries.
session
system_user
First-party cookie used to store basic application state identifying the current system user role.
session
sid
A generic session ID cookie used to maintain user state and functionality as the visitor navigates through the site.
session
Toggle Google reCAPTCHAGoogle reCAPTCHA
Google reCAPTCHA helps protect websites from spam and abuse by verifying user interactions through challenges.
Name
Description
Duration
_GRECAPTCHA
Google reCAPTCHA sets a necessary cookie (_GRECAPTCHA) when executed for the purpose of providing its risk analysis.
179 days
Toggle Google Tag ManagerGoogle Tag Manager
Google Tag Manager simplifies the management of marketing tags on your website without code changes.
Name
Description
Duration
cookiePreferences
Registers cookie preferences of a user
2 years
td
Registers statistical data on users' behaviour on the website. Used for internal analytics by the website operator.
session
Toggle StatisticsStatistics
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Toggle Factors AIFactors AI
Factors.ai is a B2B account intelligence and marketing analytics platform that helps Go-To-Market (GTM) teams identify anonymous website visitors, track buyer journeys, and measure the ROI of marketing campaigns.
Service URL: www.factors.ai (opens in a new window)
Name
Description
Duration
_fuid
It is sent to capture session details and track user behavior across your website to provide behavioral data and intent signals.
1 Year
Toggle Google AnalyticsGoogle Analytics
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Service URL: policies.google.com (opens in a new window)
Name
Description
Duration
FPGSID
Stores a session or user identifier to track how visitors interact with a website. This helps Google Analytics measure website performance, user engagement, and usage patterns.
Session
FPLC
Used by Google Analytics to link visitor interactions and sessions across multiple related domains.
20 hours
FPID
A server-side Google Analytics cookie used as an alternative user identifier when third-party cookies are restricted.
2 years
_ga
ID used to identify users
2 years
_ga_
ID used to identify users
2 years
Toggle Jetpack StatsJetpack Stats
Jetpack's built-in visitor analytics. It records page views, referring sites, search terms, and outbound link clicks, and also carries the shared visitor-tracking library used by Jetpack Instant Search and WooCommerce Analytics.
Service URL: automattic.com (opens in a new window)
Name
Description
Duration
tk_aip
Stores a list of anonymous visitor IDs so they can be merged into one identity once a visitor is recognized.
Up to 5 years
tk_tc
Used once per page load to work out which cookie domain the Tracks library should use, then removed as soon as it's read back.
Session (deleted immediately after use)
tk_qs
Queues analytics events for Jetpack's Tracks library so none are lost if the page closes before they can be sent.
30 minutes
tk_ai
Stores a randomly-generated anonymous visitor ID so Jetpack's Tracks analytics library can link tracking events to the same visitor.
Session in wp-admin; up to 5 years on the frontend
Toggle Microsoft ClarityMicrosoft Clarity
Clarity is a web analytics service that tracks and reports website traffic.
Service URL: clarity.microsoft.com (opens in a new window)
Name
Description
Duration
CLID
Identifies the first-time Clarity saw this user on any site using Clarity.
12 months
ANONCHK
Indicates whether MUID is transferred to ANID, a cookie used for advertising. Clarity doesn't use ANID and so this is always set to 0.
Session
_clck
Persists the Clarity User ID and preferences, unique to that site is attributed to the same user ID.
12 months
_clsk
Connects multiple page views by a user into a single Clarity session recording.
12 months
Toggle Parse.lyParse.ly
Parse.ly is a content analytics platform that helps publishers optimize audience engagement and content performance.
Name
Description
Duration
cookies.js_dtest
This cookie determines whether the browser accepts cookies.
session
_parsely_session
JSON document storing information identifying a browsing session according to Parsely’s proprietary definition
30 minutes
_parsely_visitor
JSON document uniquely identifying a browser and counting its sessions
13 months
Toggle SalespanelSalespanel
Salespanel is a B2B marketing and sales software that identifies, tracks, and qualifies website visitors and leads in real-time using first-party data. It helps businesses monitor customer journeys, score leads based on behavior, and syncs this data with CRMs (like Pipedrive or HubSpot) to improve conversion rates.
Service URL: salespanel.io (opens in a new window)
Name
Description
Duration
track_uid
Identify and tracking a lead
12 moths
Toggle MarketingMarketing
Marketing cookies are used to follow visitors to websites. The intention is to show ads that are relevant and engaging to the individual user.
Toggle Bing / MicrosoftBing / Microsoft
Bing, powered by Microsoft, is a search engine providing web, image, video, and map search capabilities.
Name
Description
Duration
MR
Used to collect information for analytics purposes.
6 months
ANONCHK
Used to store session ID for a users session to ensure that clicks from adverts on the Bing search engine are verified for reporting purposes and for personalisation
10 minutes
SM
Used by Microsoft in synchronizing the MUID across multiple Microsoft domains to track users for advertising.
session
MUID
Identifies unique web browsers visiting Microsoft sites. These cookies are used for advertising, site analytics, and other operational purposes.
1 year
Toggle DoubleClick/Google MarketingDoubleClick/Google Marketing
A comprehensive digital advertising platform for managing campaigns, optimizing performance, and analyzing audience data.
Name
Description
Duration
IDE
This cookie is used for targeting, analyzing and optimisation of ad campaigns in DoubleClick/Google Marketing Suite
2 years
ar_debug
Store and track conversions
Persistent
Toggle LinkedInLinkedIn
LinkedIn is a professional networking platform for job seekers, employers, and industry connections.
Name
Description
Duration
bscookie
Used by LinkedIn to track the use of embedded services.
1 year
AnalyticsSyncHistory
Used to store information about the time a sync with the lms_analytics cookie took place for users in the Designated Countries
30 days
bcookie
Used by LinkedIn to track the use of embedded services.
1 year
li_sugr
Used to make a probabilistic match of a user's identity outside the Designated Countries
90 days
lidc
Used by the social networking service, LinkedIn, for tracking the use of embedded services.
1 day
UserMatchHistory
Used by LinkedIn Ads to synchronize and match user IDs across different ad networks and data providers.
30 days
Toggle LinkedIn InsightLinkedIn Insight
LinkedIn Insight is a web analytics service that tracks and reports website traffic.
Service URL: www.linkedin.com (opens in a new window)
Name
Description
Duration
li_sugr
Used to make a probabilistic match of a user's identity.
90 days
lidc
Used for routing and session management.
24 hours
Toggle LiveIntentLiveIntent
LiveIntent provides a platform for email advertising and identity-driven marketing solutions.
Name
Description
Duration
_lc2_fpi_js
Companion cookie to _lc2_fpi used by JavaScript to facilitate cross-domain ad tracking and user identification.
1 year
_lc2_fpi
First-party tracking cookie usually associated with LiveRamp to identify users across devices for targeted advertising.
1 Year
_li_ss
Sets a unique ID for the visitor, that allows third party advertisers to target the visitor with relevant advertisement. This pairing service is provided by third party advertisement hubs, which facilitates real-time bidding for advertisers.
1 month
lidid
Collects data on visitors' behaviour and interaction - This is used to make advertisement on the website more relevant. The cookie also allows the website to detect any referrals from other websites.
2 years
Toggle Cookie PolicyCookie Policy
You can find more information in our Privacy Policy.
Allow AllDecline All
Accept