Use this checklist before moving a website to HubSpot so you protect SEO, preserve lead capture, and avoid launch surprises.
Guide
A migration checklist is useful only if it catches the work that teams usually remember too late. The goal is not to produce a longer spreadsheet. The goal is to make sure pages, SEO signals, forms, analytics, and post-launch ownership are all accounted for before the move begins. If the source site is WordPress, use the dedicated WordPress to HubSpot migration checklist as the next layer.
Before migration
Start with the current site, not the future design. A clear inventory prevents underquoting, missing templates, and last-minute surprises during launch week.
List core pages, product or service pages, landing pages, blog templates, legal pages, utility pages, navigation, footer, and reusable sections. Mark what should be migrated exactly, what should be rebuilt, and what can be retired.
Document copy, images, downloadable files, videos, embeds, authors, categories, tags, and any gated assets. If content cleanup is needed, decide whether it happens before migration or inside the project scope.
Record forms, CTAs, meeting links, chat widgets, thank-you pages, routing rules, notifications, workflows, and CRM dependencies. These are often more business-critical than the visible page layout.
SEO inventory
Most migration damage comes from losing existing signals by accident. Build the SEO inventory before URLs change, not after rankings move.
HubSpot build
A website migration is not only a content move. Someone has to decide what the new CMS needs in order to be usable after launch.
Plan templates, reusable modules, global sections, navigation, footer, blog structure, editing permissions, and the page-building patterns your team will use after go-live.
List analytics, consent tooling, pixels, CRM routing, marketing automation, meeting tools, chat, scripts, and third-party embeds that must survive the move.
Separate must-keep brand elements from improvements worth making during migration: spacing, CTA hierarchy, mobile behavior, accessibility, and performance cleanup.
Launch readiness
Launch QA should be explicit enough that another person could run it. If the project depends on memory, it is not ready.
Test responsive layouts, forms, thank-you flows, internal links, metadata, redirects, tracking, cookies, page speed, accessibility basics, and indexability on staging.
Publish with redirects ready, verify DNS and HTTPS, crawl priority URLs, submit the sitemap, inspect major templates, and retest the highest-value conversion paths on production.
Watch Search Console, analytics, form submissions, 404s, redirect chains, and ranking-sensitive pages during the first days after release.
Decision table
Common mistakes
Blogs, author pages, legal pages, thank-you pages, search pages, and hidden landing pages often appear late because nobody inventoried them at the start.
A pretty page is not enough. If routing, notifications, or workflows fail after launch, the migration has broken revenue operations even if the site looks correct.
The first post-launch crawl usually reveals the edge cases. Reserve time for redirect fixes, analytics validation, and Search Console monitoring.
Ownership
A migration slows down when nobody knows who can approve copy, who owns analytics, or who decides whether an old page survives. Name the owners before the build begins.
Approves page priorities, messaging, CTAs, blog structure, and whether low-value content should be kept, merged, or removed.
Confirms domains, integrations, tracking, consent tooling, redirect implementation, analytics access, and launch-day responsibilities.
Breaks ties when a migration choice affects scope, timeline, SEO risk, or cost. Without this role, small decisions pile up into real delay.
Ready to migrate?
Why it matters
Without a checklist, teams tend to review the most visible work first: homepage, navigation, colors, and obvious templates. The failures usually happen elsewhere. An old campaign page stops redirecting. A thank-you page is forgotten. A tracking script does not survive the move. A legal page is missing from the sitemap. A checklist forces the project to include the boring but valuable work that protects acquisition and operations after launch.
It also makes tradeoffs explicit. If the team wants to simplify navigation, merge weak pages, or improve conversion paths during the migration, those choices should be recorded before launch. That way the project is not judged against an unstated expectation that every old URL, block, and workflow would magically remain unchanged.
Related guides
Use the source-specific checklist for WordPress pages, blog content, plugins, redirects, and launch QA.
Understand which decisions inside the checklist are likely to change scope and pricing.
Go deeper on redirects, canonicals, metadata, crawling, and post-launch monitoring.
FAQ
At minimum: page inventory, template scope, SEO metadata, redirect mapping, forms, analytics, integrations, QA, and post-launch checks.
Before the build starts. The checklist is most useful when it shapes scope instead of being used only as a final review.
Yes. Redirect mapping is one of the most important tasks in any website migration because URL changes can otherwise create avoidable SEO loss.
Next step
Start with the HubSpot website migration guide, continue to our HubSpot website migration service, or review platform-specific pages for WordPress, Webflow, Wix, and Squarespace.
