WordPress to HubSpot Migration

All three HubSpot import methods handle blog content exclusively. Website pages, landing pages, and any structured content beyond posts must be rebuilt by hand in HubSpot templates and modules. A 200-page WordPress site is a 200-page rebuild, not an import with cleanup.

Workaround: Scope by template rather than by page. Identify the distinct page types, build a reusable template and module set for each, then populate. Rebuilding page by page is the single most expensive way to run this project.

HubSpot has no equivalent of functions.php because it has no concept of hooks or filters. Every plugin-provided capability must be replaced with a native HubSpot feature, a marketplace app, a custom module, a serverless function, or a third-party service. HubSpot's own developer documentation explicitly declines to cover themes that rely on complex plugins.

Workaround: Inventory active plugins first and classify each as native equivalent, marketplace app, custom build, third-party service, or drop. The plugin audit is the single best predictor of true project cost, and it should happen before any quote is issued.

Custom post types are the standard WordPress pattern for structured content such as team members, case studies, locations, and product directories. HubSpot has no post type concept, but HubDB tables driving dynamic pages reproduce the outcome, generating a page per row with its own URL and analytics; that requires Content Hub Professional, and is capped at 10 dynamic pages per table. CRM custom objects are the other route and require an Enterprise tier.

Workaround: Map each custom post type to HubDB or a custom object early, because the answer determines the required subscription tier. A site with several custom post types and Advanced Custom Fields data is often a Content Hub Professional project minimum, which frequently exceeds what the client expected to pay.

WordPress themes are PHP. HubSpot themes are HubL, with template inheritance via extends, drag-and-drop areas built from widget_container blocks, and asset loading through require_css, require_js, and get_asset_url rather than wp_enqueue_style and get_template_directory_uri. Existing PHP developers cannot transfer straight across, and HubSpot developers are fewer and typically cost more.

Workaround: Confirm who is building before quoting. An agency's existing WordPress team will need ramp-up time, and that time belongs in the estimate rather than being absorbed silently.

URL structures rarely match one to one after a HubSpot rebuild. Every changed URL needs a 301 redirect mapped before go-live. Skipping or rushing this is the most common cause of post-launch ranking loss, and the damage surfaces weeks later when it is expensive to diagnose.

Workaround: Crawl the live WordPress site and build a complete URL inventory before any rebuild starts. Map redirects as part of the build, not as a launch-day task, and keep the WordPress site crawlable in a staging environment for reference. Expect performance to stabilise two to four weeks after a correctly executed migration.

The fastest import route depends on the public WordPress REST API being reachable and standard. Security plugins, headless setups, custom permalinks, and enterprise hardening routinely disable or restrict it, and the tool then fails without a clear diagnosis.

Workaround: Test WordPress connect against the live blog early, during discovery, rather than discovering the failure during the build. Fall back to smart copy, then to XML export. Each fallback is progressively less accurate and needs more cleanup, which is an estimating input.

404 pages, 500 error pages, search results pages, password prompt pages, and email subscription preference pages all need building in HubSpot. They are invisible in a sitemap-driven page count, so they are routinely missing from both the estimate and the launch checklist.

Workaround: Add system pages to the template inventory explicitly at scoping time. They are low effort individually and embarrassing collectively when missed at launch.

HubSpot Content Hub is not an ecommerce platform. Revenue Hub covers payments, quotes, invoices, and subscriptions, but not a product catalogue, cart, checkout, shipping, tax, or inventory. A WooCommerce store cannot be rebuilt in HubSpot.

Workaround: Keep the store on a dedicated ecommerce platform and integrate it with HubSpot, or advise against the migration for ecommerce-led sites. Product content and pricing pages can move; the store itself cannot.

ACF is near-universal on serious WordPress builds and stores structured field data against posts, pages, and custom post types. HubSpot has module fields for template-level content and HubDB for tabular data, but no equivalent concept of arbitrary custom fields attached to any content record.

Workaround: Model ACF field groups as either module fields, where the data belongs to one page, or HubDB columns, where the data is a repeating set. Repeater and flexible-content fields are the hard cases and often need restructuring rather than mapping.

Content Hub Free caps at 25 pages. HubDB, smart content, A/B testing, SEO recommendations, and custom reporting require Professional. Memberships, multi-site, additional root domains, and partitioning require Enterprise. A WordPress site that was effectively free to host can require a Professional or Enterprise subscription purely to reproduce what it already did.

Workaround: Derive the required tier from the feature and content-structure audit and put it in the proposal explicitly. Discovering the HubDB requirement mid-build is a commercial problem, not a technical one.

WordPress patterns such as admin-ajax handlers and arbitrary server-side PHP have no direct HubSpot equivalent. WP-Cron is the exception: Data Hub Professional runs schedule-triggered workflows with JavaScript or Python custom code actions, a pattern HubSpot itself documents as writing cron jobs. Serverless functions cover some of the rest, with their own execution limits, and other cases require an external service.

Workaround: Identify server-side behaviour during the plugin and theme audit. This is where migrations discover work that cannot be done at all in HubSpot and needs an external service, which is far better learned during scoping than during build.

WPML and Polylang store translations with their own data structures and URL schemes. HubSpot supports multi-language variants of a page or post as a linked group. There is no import path from either plugin, and the URL structure will usually change.

Workaround: Rebuild language variants manually and map redirects per language. Confirm that the required language count is supported at the client's intended tier before committing.

HubSpot's own guidance is that WordPress-specific code, including anything from wp-includes or wp-content, should not be carried over, and that third-party tracking codes should be re-exported from the vendor rather than copied out of WordPress. Media must be re-uploaded to the HubSpot Files tool, and every in-content image reference updated.

Workaround: Treat the media migration as its own task with a URL rewrite pass over imported post bodies. Imported posts that still reference the old wp-content image URLs will break the moment WordPress hosting is switched off.

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. Pages, by far the larger share of most sites, are a manual rebuild

WordPress connect fails silently on installs with a disabled or restricted REST API, which is common on hardened sites

There is no plugin ecosystem and no hooks system, so functions.php logic has nowhere to go

Custom post types do not exist in HubSpot, and the HubDB versus custom-object decision sets the required tier

HubDB needs Content Hub Professional; memberships, multi-site, and extra root domains need Enterprise

System pages are invisible in a page count and routinely missing from both estimate and launch checklist

Imported posts still referencing wp-content image URLs break the moment WordPress hosting is switched off

Redirects are manual and are the entire SEO risk; rushing them is the top cause of post-launch ranking loss

WooCommerce cannot be rebuilt in HubSpot at all

ACF repeater and flexible-content fields need restructuring, not mapping

PHP developers cannot move straight to HubL, and that ramp-up time belongs in the estimate

Client decision-making speed, not build complexity, is the biggest single timeline factor on these projects