What happens during a HubSpot website migration (a practical walkthrough)

Moving a website to a new platform is one of those projects that sounds simple until you're three weeks in and someone asks where the old contact form submissions went. A HubSpot migration isn't just a lift-and-shift of pages. It's an audit, a decision-making exercise about what's worth keeping, and a technical project to protect the search visibility you've already earned, all before a single new page goes live.

This walkthrough covers what actually happens at each stage, in the order it happens, so you know what to expect whether you're doing this yourself, briefing an internal team, or scoping the work with an agency.

Before you start: what to audit on your current site

Every migration starts with knowing exactly what you're moving. Skip this step and you'll spend the back half of the project discovering pages, forms, and integrations you'd forgotten existed, usually at the worst possible moment.

Blend's HubSpot website migration service documents every existing module and page type before development starts, which is exactly the kind of granular audit that catches the orphaned pages and half-forgotten integrations most DIY audits miss.

A proper pre-migration audit covers:

• Every live URL, including ones with no obvious internal links pointing to them. Old landing pages and orphaned blog posts still pull organic traffic even when nobody on the current team remembers writing them.
• Traffic and ranking data for each page, pulled from Google Analytics and Search Console, so you know which pages are actually earning their place before you decide what to cut.
• Backlink profile, so you can see which pages are attracting external links. Losing a page that fifteen other sites link to is a different problem to losing one that nobody's linked to since 2019.
• Forms and their downstream automation. Every form needs a matching home in HubSpot, along with whatever happens after submission: notification emails, CRM records, workflow enrolments.
• Third-party tools and integrations currently embedded in the site, whether that's a chat widget, a booking tool, or a custom calculator.
• Existing redirects already live on the current site. These need to be carried across too, not just the URLs you're actively changing.

A spreadsheet is the right tool here, not a mental note. You'll refer back to this audit constantly over the following weeks.

Planning the migration: content, structure, and redirects

With the audit done, the next stage is deciding what the new site actually looks like and how you'll get from the old URL structure to the new one without breaking anything that currently works.

Mapping old URLs to new ones

Build a URL mapping document: old URL in one column, new URL in the next, for every page you're keeping. Where the URL structure is staying the same, this is a formality. Where it's changing, whether because you're restructuring navigation or moving from a flat structure to folders, this document becomes the single source of truth for the redirect work later.

Be specific rather than general here. "Old blog posts go to /resources/" isn't a mapping, it's a hope. Map every individual URL, even if the new address follows an obvious pattern.

Deciding what content to keep, cut, or consolidate

Not everything on the old site deserves a place on the new one. Using the traffic and ranking data from your audit, sort pages into three groups: keep as is, consolidate with similar pages into something stronger, or retire with a redirect to the nearest relevant page.

Consolidation is worth taking seriously rather than treating as a last resort. If you've got six thin blog posts covering slightly different angles of the same topic, one properly researched page usually outperforms all six combined, both in rankings and in how it reads to an actual visitor.

Setting a realistic timeline

Timelines get estimated on page count alone more often than they should be, and that's usually where they go wrong. A 40-page brochure site with no custom functionality moves faster than a 40-page site with embedded calculators, gated content, and three different form integrations. Blend's HubSpot website migration service is built around a documented, page-by-page audit before a single page gets rebuilt, which is exactly why complexity, not page count, is what actually drives the schedule.

As a rough guide, a straightforward migration with no redesign typically runs four to eight weeks. Add a visual refresh, custom modules, or complex integrations, and that stretches meaningfully. Build in contingency for content review; it's the stage that most often takes longer than planned, because someone always wants to "just tweak" the copy while they're looking at it.

Building the new site on HubSpot CMS

With planning locked in, development starts on the new site itself. This typically happens in a defined sequence rather than all at once: the theme, global modules, and system pages (header, footer, 404 page) get built first, since everything else depends on them. Blend's HubSpot website design and development team builds this core framework before moving on to individual page templates and blog templates, so the foundation is tested before content gets poured into it.

Whether you're doing a straight lift-and-shift or using the migration as an opportunity for a visual refresh changes the scope here considerably. A lift-and-shift means recreating what already exists, which sounds simpler but still requires translating design decisions made for a different platform into HubSpot's templating language. A redesign gives you more freedom but adds design and approval cycles to the timeline. Neither is wrong; it depends on whether your current site's problems are technical (wrong platform, slow, hard to edit) or also visual and structural.

Migrating content without losing SEO

This is the stage that causes the most anxiety, and reasonably so. A botched migration can undo years of ranking progress in a matter of days. Losing the search visibility built up over time is the single biggest risk in any platform move, and it's what Blend's HubSpot website migration service is built to prevent, preserving existing SEO value and performance regardless of which CMS you're moving from.

301 redirect strategy

Every URL that's changing needs a 301 redirect pointing from the old address to its new home. This tells search engines the page has permanently moved, and passes across the ranking signals the old URL had built up. Miss a redirect and visitors (and search engine crawlers) hit a 404 page, which wastes any link equity that URL had earned.

Use the URL mapping document from the planning stage to build your redirect list, then implement it as close to launch as possible so redirects and the new site go live together. Avoid redirect chains, where URL A redirects to B, which redirects to C. Point everything directly at its final destination.

Preserving metadata and structured data

Title tags, meta descriptions, and any structured data (schema markup) need to be copied across for every page you're keeping, not left to whatever HubSpot generates by default. This is tedious, unglamorous work, and it's exactly the kind of thing that gets skipped under deadline pressure and shows up as a ranking dip a month later.

Handling images and media assets

Images need to be re-uploaded (or migrated via HubSpot's import tools where available) with alt text preserved, and ideally re-optimised for file size while you're at it. Video embeds and downloadable assets like PDFs or whitepapers need their own check, since these are often hosted separately from the main content and easy to overlook during a page-by-page migration.

Testing, QA, and pre-launch checks

Before launch, run a proper QA pass rather than a quick click-through. Worth checking, at minimum:

• Every form submits correctly and triggers the right notification and workflow
• All redirects resolve to the correct new URL, not a generic homepage fallback
• Structured data validates correctly using a schema testing tool
• The site renders and functions correctly across major browsers and screen sizes
• Page speed is comparable to, or better than, the old site
• Tracking codes (analytics, ad pixels) are installed and firing correctly
• Any third-party integrations still function as expected

Test this on the staging domain before it's anywhere near live traffic. Anything caught here is a five-minute fix; the same issue caught after launch is a five-minute fix plus however long it takes visitors to stop hitting it.

Launch day and what to watch for afterwards

Launch itself is usually the quietest part of the project if everything before it has been done properly, and the most stressful part if it hasn't. DNS changes need to propagate, SSL certificates need to be active, and redirects need to be live the moment the new site is. A DIY migration usually stalls at exactly this point, where technical configuration meets go-live pressure; Blend's HubSpot website design and development team manages the complete launch process and handles the technical configuration as standard, then stays on afterwards to resolve any cross-browser or device compatibility issues.

In the days and weeks after launch, keep a close eye on: crawl errors in Search Console (a sudden spike usually means a redirect problem), organic traffic against your pre-migration baseline, form submission volume, and page load speed. Some ranking fluctuation in the first week or two is normal as search engines re-crawl and re-index the new URLs. A sustained drop after that window is worth investigating properly rather than waiting it out.

The real test comes after go-live

Anyone can point at a finished migration on launch day and call it a success. The actual test is three months later: whether rankings held, whether the team can update the site themselves without raising a ticket every time, and whether anything that broke got fixed quickly rather than sitting in a queue. Blend's team of 50+ in-house specialists work on HubSpot migrations without outsourcing to freelancers or offshore resource, which matters most exactly when something needs fixing quickly after go-live.

If you're weighing up whether to migrate the site yourself, use HubSpot's own migration service, or bring in a partner to handle the technical detail, book a consultation and get a straight answer on what your specific migration actually needs.