WordPress to HubSpot CMS migration.
Same URLs. New CMS. A website migration is judged on traffic three months later, not on how the new site looks at launch. We plan it backwards from the redirect map, carry the metadata and structured data across, and rebuild templates as modules a marketer can actually use.
The rebuild is fine. The redirects are the risk.
Every WordPress site carries a decade of URL decisions: category archives, tag pages, paginated blog indexes, attachment pages, and whatever the last SEO consultant set up. Miss them and the rankings you paid years to earn go to a 404. This is the part nobody quotes for and everybody regrets.
A 404 is a ranking you paid for.
WordPress — the redirect mapThe parts that are not a theme.
Plugins with no equivalent
Every WordPress site runs plugins doing things HubSpot does differently or not at all — membership gates, calculators, custom post types, event calendars. Each one gets named on day one as rebuild, replace or drop, before the design work starts.
Custom fields become HubDB
Advanced Custom Fields and custom post types map to HubDB tables and dynamic pages. That is a genuine architecture decision, not an import, and it sets whether the marketing team can add a new entry later without a developer.
Forms and everything behind them
Gravity Forms and Contact Form 7 carry notification logic, conditional fields and integrations. Rebuilt as HubSpot forms, they get better tracking and worse flexibility, so the conditional logic has to be checked case by case.
SEO metadata and schema
Yoast or RankMath hold titles, descriptions, canonicals and structured data per page. All of it carries, but only if it is extracted before the site is decommissioned rather than after.
The blog is its own migration
Posts, authors, tags, categories, featured images and comment history each map somewhere different, and the paginated archive URLs need their own redirect rules.
The domain cutover
DNS, SSL, the CDN in front of it and the email sending domain all move on a schedule. Done carelessly this is the one step that takes the site down in the middle of a working day.
The sequence, start to cutover.
Discovery
Object counts, custom fields, automation and the integrations that will break on the way out, read from the source system rather than from a questionnaire.
Mapping
Field by field, including what will not carry across, agreed and signed before anyone exports anything.
Dry run
A complete rehearsal into a sandbox portal, reconciled against source counts so the gaps surface a month early rather than on cutover night.
Automation rebuild
Workflows, sequences and routing rebuilt to the new model rather than transliterated from the old one, which is how a migration inherits a decade of workarounds nobody remembers writing.
Cutover
A dated switch with the legacy system read-only for a defined window, and a rollback that was tested rather than assumed.
Post-migration support
A named engineer through the first full reporting cycle, which is when the questions actually arrive.
Launch is when the measurement starts.
The week after a CMS migration is when you find the redirect you missed, the template that breaks on a phone, and the form that stopped notifying sales. We crawl the old site before cutover, crawl the new one after, and diff the two. Anything that lost a URL, a title or a canonical shows up on a list rather than in a traffic report a month later.
What people ask before they commit.
Will we lose our search rankings?
Not if the redirect map is complete and the on-page metadata carries. We crawl the existing site, build a one-to-one redirect map including archives and paginated URLs, and diff the crawls after launch. Some ranking movement in the first weeks is normal; a cliff is not, and it is almost always a redirect problem.
Can our marketing team still edit pages afterwards?
That is the point of doing it properly. We build modules with real fields rather than one rich text box, so a marketer can build a new page from existing pieces without a developer and without breaking the design system.
How long does a WordPress to HubSpot migration take?
Four to ten weeks depending on page count, how much of the site is templated versus bespoke, and how many plugins need replacing. The blog archive and the redirect map usually take longer than the design.
What happens to our blog posts?
They move with authors, tags, categories, featured images and publish dates intact, into the HubSpot blog. Internal links get rewritten to the new URLs rather than left pointing at redirects, which compounds badly across a few hundred posts.
Do we have to redesign at the same time?
No, and often you should not. Migrating the existing design first isolates the variables, so if traffic moves you know it was the platform and not the new hero. A redesign afterwards is a cleaner project with a known baseline.
Can we keep WordPress for the blog?
You can, and some teams should. That becomes an integration rather than a migration — the HubSpot tracking code, forms and CRM sync running on a WordPress front end. We build it either way.
Where people go from here.
Move the site without moving the traffic.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.