WordPress to HubSpot Migration

Whichever of the three import routes you choose, all of them stop at the blog: website pages, landing pages and anything else beyond posts have to be rebuilt by hand inside HubSpot's templates and modules. A 200-page site does not shrink to an import with tidying at the end; it is a 200-page rebuild, and the proposal should say so plainly rather than let 'import' carry an assumption it cannot support.

Workaround: Scope the rebuild by template, not by counting pages: work out the distinct page types first, build one reusable template and module set for each, then populate. Rebuilding page by page is the costliest way to run this project, and it is usually the way a first-time quote defaults to without meaning to.

There is nothing in HubSpot standing in for functions.php, because there is no hooks or filters system underneath it at all. Whatever a plugin was doing has to reappear as a native HubSpot feature, a marketplace app, a custom module, a serverless function or a third-party service, one decision per plugin, and HubSpot's own developer documentation says outright that it will not cover a theme built around complex plugins.

Workaround: Start with a full inventory of active plugins and sort each one into native equivalent, marketplace app, custom build, third-party service or drop, before a single quote goes out. That audit predicts the real cost of the project better than anything else available at scoping stage, and it usually surfaces the WhatsApp, local telephony or payment-gateway plugin that a page count would never flag.

Team members, case studies, locations and product directories are usually built in WordPress as custom post types, and HubSpot simply has no matching concept. HubDB tables can reproduce the outcome, generating one page per row with its own URL and analytics, but that route needs Content Hub Professional and is capped at 10 dynamic pages per table; CRM custom objects are the alternative and sit behind an Enterprise tier instead.

Workaround: Decide early, per custom post type, whether it becomes a HubDB table or a custom object, because that single decision sets the subscription tier the whole project needs. Several custom post types running alongside Advanced Custom Fields data is often, on its own, a Content Hub Professional project, and that is worth putting in front of whoever holds the budget before the quote is finalised, not after.

A WordPress theme is written in PHP; a HubSpot theme is written in HubL, with its own template inheritance through extends, its own drag-and-drop areas built from widget_container blocks, and its own asset loading through require_css, require_js and get_asset_url rather than wp_enqueue_style and get_template_directory_uri. A PHP developer does not carry straight across into that, and HubSpot developers are both scarcer and, on the whole, more expensive to bring on for the rebuild.

Workaround: Settle who is actually doing the build before the quote is written, not after. An existing WordPress team needs ramp-up time on HubL, and that time belongs in the estimate from the start rather than being absorbed quietly once the project is already under way.

A HubSpot rebuild rarely keeps every URL exactly where it was, and every URL that moves needs its own 301 redirect in place before go-live. Skipping or rushing this is the single most common cause of a ranking drop after launch, and the damage tends to surface weeks later, once it is expensive to trace back to the missing redirect that caused it.

Workaround: Crawl the live site for a complete URL inventory before the rebuild starts, and treat redirect mapping as part of the build itself rather than a task left for launch day. Keep the WordPress site reachable in a staging environment for reference throughout, and expect performance to settle two to four weeks after a correctly executed cutover.

The fastest of the three import routes only works if the public WordPress REST API is reachable and unmodified, and security plugins, headless setups, custom permalinks or general enterprise hardening routinely restrict or disable exactly that. When it fails, it tends to fail without telling you why, which is the moment a scoping call turns into a diagnosis.

Workaround: Test WordPress connect against the live blog during discovery, well before it becomes a build-week surprise. Falling back to smart copy, and then to XML export, is a real path forward, but each step down is progressively less accurate and needs more cleanup, which belongs in the estimate as soon as the first route is ruled out.

A 404 page, a 500 error page, search results, a password prompt and the subscription preferences page all need building fresh in HubSpot, and none of them show up in a sitemap-driven page count. That is exactly why they go missing from both the estimate and the launch checklist, and why the gap is only noticed once the site is already live.

Workaround: Name every system page explicitly in the template inventory at scoping time rather than assuming the sitemap already accounts for them. Each one is little effort on its own, and the whole set is an easy thing to be embarrassed by if it is missing on launch day.

Content Hub was never built as an ecommerce platform, and Revenue Hub covers payments, quotes, invoices and subscriptions without ever taking on a product catalogue, a cart, checkout, shipping, tax or inventory. A WooCommerce store simply has nowhere to be rebuilt inside HubSpot: that part of the site is not migrating, whatever the rest of the plan says.

Workaround: Leave the store on a dedicated ecommerce platform and integrate that platform with HubSpot rather than attempting to rebuild it there, or say plainly that the migration is not right for an ecommerce-led site. Product content and pricing pages can move across; the storefront itself cannot, and that distinction is worth stating before any commitment is made.

Advanced Custom Fields sits behind nearly every WordPress build worth the name, holding structured field data against posts, pages and custom post types alike. HubSpot has module fields for content that belongs to a single template and HubDB for tabular data, but nothing that plays the role ACF plays: arbitrary custom fields attached to any content record at all.

Workaround: Sort each ACF field group into module fields, where the data belongs to a single page, or HubDB columns, where it repeats across records. Repeater and flexible-content fields are the genuinely hard case here and usually need restructuring rather than a one-to-one mapping, so budget them separately from the simpler fields.

Content Hub Free stops at 25 pages, and HubDB, smart content, A/B testing, SEO recommendations and custom reporting all sit behind Professional; memberships, multi-site support, extra root domains and partitioning sit behind Enterprise again above that. A site that cost next to nothing to host on WordPress can need a Professional or an Enterprise subscription simply to do again what it was already doing, and that gap is worth naming to whoever approves the budget well before it is discovered mid-build.

Workaround: Work out the required tier from the feature and content-structure audit, then put it in the proposal in plain terms. Finding out about the HubDB requirement halfway through the build is a commercial problem for the committee approving spend, not a technical one for whoever is building the site.

Admin-ajax handlers and arbitrary server-side PHP have no direct equivalent on the HubSpot side. WP-Cron is the one exception worth knowing: Data Hub Professional runs schedule-triggered workflows using JavaScript or Python custom code actions, a pattern HubSpot's own documentation describes as writing cron jobs, and serverless functions cover a further slice of it within their own execution limits. What is left over needs an external service found for it.

Workaround: Surface every piece of server-side behaviour during the plugin and theme audit rather than during the build itself. This is where a migration finds work that simply cannot be done inside HubSpot at all and needs an external service, and that is a far cheaper discovery to make at scoping than midway through.

WPML and Polylang each store translations in their own data structure and their own URL scheme, and HubSpot's answer, a linked group of language variants on a page or post, has no import path from either plugin. A bilingual Arabic and English site built on either one is not migrating its translations; it is rebuilding them, and the URL structure underneath will usually change in the process.

Workaround: Rebuild each language variant by hand and map redirects separately for each language rather than assuming one redirect map covers both. Confirm the required language count sits inside the tier you intend to commit to before the timeline is agreed, since a bilingual Arabic and English pairing is the common case here but is not free at every tier.

HubSpot itself advises against carrying WordPress-specific code across, anything under wp-includes or wp-content included, and recommends re-exporting third-party tracking codes from the vendor rather than lifting them out of WordPress. Media has to be re-uploaded to the HubSpot Files tool separately, with every in-content image reference pointed at the new location.

Workaround: Treat the media migration as a task of its own, with a dedicated URL rewrite pass over every imported post body. A post still pointing at an old wp-content image URL keeps working right up until WordPress hosting is switched off, at which point it breaks all at once and without warning.

The highest-risk discovery item. Surface these during scoping rather than during build.

Confirm the target tier before promising equivalent separation.

Only blog posts import through any of the three routes; pages, which make up the larger share of most sites, are a manual rebuild in full

WordPress connect fails silently wherever the REST API is disabled or restricted, which is common on a hardened site and rarely obvious until the import is already attempted

There is no plugin ecosystem and no hooks system on the HubSpot side at all, so whatever functions.php was doing has nowhere left to go without a rebuild

Custom post types have no equivalent in HubSpot, and the HubDB-versus-custom-object decision made for each one sets the subscription tier the whole build needs

HubDB sits behind Content Hub Professional; memberships, multi-site support and extra root domains sit behind Enterprise again above that

System pages are invisible to a sitemap-driven page count and are routinely missing from both the estimate and the launch checklist as a result

An imported post still pointing at a wp-content image URL keeps rendering fine right up until WordPress hosting is switched off, then breaks all at once

Redirects are entirely manual and are the whole of the SEO risk in this migration; rushing them is the single biggest cause of a post-launch ranking loss

WooCommerce cannot be rebuilt inside HubSpot in any form, full stop

ACF repeater and flexible-content fields need genuine restructuring, not a straight mapping across, and that work is easy to underestimate at scoping

A PHP developer cannot move straight into HubL without ramp-up time, and that time belongs in the estimate rather than being discovered as a delay once the build has started

How quickly your side of the business can actually make decisions, not the technical complexity of the build, is consistently the biggest single factor in how long these projects take, and a decision cycle that slows around Ramadan, Eid or the deep summer is worth planning the calendar around rather than treating as a surprise