HubSpot Rejected Your Website Migration Request. Three paths forward

You submitted your website to HubSpot's migration service, waited, and got a response that wasn't the one you wanted: they can't take it on.
It can be a frustrating situation, particularly if you've already bought a Content Hub subscription and worked towards a launch date. But a rejection isn't a verdict on your website, and it most certainly doesn't mean that your site can't move to HubSpot. It means your site falls outside the boundaries of one specific, standardised service.
We've delivered more than 15,000 migrations to HubSpot since 2011, and a bug chunk of them came to us exactly this way: rejected by the standard service, then delivered without difficulty by a team that works outside those constraints. Since we have teams that work both inside and outside these constraints, we are in possibly the best position to help you.

What HubSpot's migration service is - and what it's built for

HubSpot's website migration service moves an existing website onto Content Hub. It's efficient, well-priced, and for a large number of sites it's a great choice. If your site is a marketing site with a modest page count (up to 150) and no unusual functionality, the official  migration service is a great fit  .
The service achieves that efficiency through standardisation. Your site gets rebuilt onto either a marketplace theme or a template built on HubSpot's default framework. This approach keeps the cost and timeline very predictable but also creates these boundaries.
A standardized process like this can accommodate sites that fit the standard very well . When yours doesn't, the honest answer is a rejection rather than a project that overruns and disappoints. Viewed that way, the rejection is a reasonable call, not a brush-off.

Why website migrations actually get rejected by HubSpot

In our experience since 2011,  the website migration rejections by HubSpot cluster around a handful of specific causes. Identifying the reason that applies to your website is useful because it tells you what your migration actually requires to be successful.

Page count beyond the service threshold

Standardized migrations are scoped around a defined number of pages. Sites with large content libraries, extensive resource sections, or years of accumulated landing pages exceed what the fixed scope can handle.

Large scale Database-driven or dynamic content

Product catalogues, location directories, team listings, event calendars, searchable resource libraries - anything generated from a data source rather than built page by page. These need to be rebuilt on HubDB with proper templates, filtering, and URL structures. This typically becomes a design and development exercise and is not usually a content transfer. However, the HubSpot migrations team does take up cases where the dynamic content is within their page coun threshold.

Custom code and interactive functionality

Complex calculators, custom configurators, quizzes, interactive maps, custom search, gated portals - these are some typical components that need to be rebuilt as a custom HubSpot module or reimplemented against HubSpot's APIs. Standard migrations don't include custom development.

Third-party plugins and integrations

These are especially common on WordPress. Booking systems, membership platforms, review widgets, learning management, custom form logic. Some have clean HubSpot equivalents while some need integration work, and some need rethinking entirely. It involves solution design to work out before it becomes development work.

Design complexity beyond template capability

Custom or unique UI components like unusual navigation patterns, heavy animation, or a design system that simply doesn't map onto a standard web component. Such components usually require a lot of custom code best done outside the scope of such standard service.

Non-standard or unusual source platforms

Standard migration processes assume a recognizable source. Bespoke CMSs, older enterprise platforms, headless setups, and increasing instances of AI-generated codebases don't offer the clean export path those processes rely on.

Multi-language, multi-brand, or multi-domain structures

Sites running several language variants or multiple brands under one estate carry structural complexity that a single-site migration process isn't scoped for.

So what does the rejection actually mean:

A rejection isn't a sign that something's wrong with your website. It usually means the opposite. It could mean that you have a dynamic product catalogue because you sell a lot of products or you built a calculator because it brings in leads.

It could mean your site has two hundred landing pages because a dedicated team has been running campaigns for years. It just can't be copied across on a template —and possibly has to be rebuilt.

So the main thing that changes is how you think about the work. This isn't a fixed-price service you buy off a page. It's a project that needs scoping. Better to know that now than to find out three weeks in.

Your three options from here

Option 1 — Work with a HubSpot partner specializing in non-standard migrations
This is the route most rejected sites take, and there is a  good reason. It removes the constraint that caused the rejection in the first place.
A partner-led migration is scoped to your current  live site rather than to a template. Page count is no longer a limitation. Dynamic content is rebuilt properly on HubDB with search and filtering that's usually better than what you had. All custom functionality gets rebuilt as HubSpot custom modules & sections. Integrations get assessed individually and are either replaced with native equivalents, connected via API, or are rearchitected.
What you're buying here is the judgement & solution as much as development.
It costs more than the standardised service. It should: it's a different kind of work. What you get for that difference is a site that arrives on HubSpot intact, plus a theme and module library your marketing team can actually operate afterwards.
It's worth asking any partner you're considering: how they handle the specific thing that got you rejected. A partner who has migrated your source platform and your kind of complexity before will answer that in specifics and with possible solution paths

Option 2 — Migrate it yourself with a marketplace theme

HubSpot's Template Marketplace has a large selection of themes, and self-migrating is a legitimate path for some websites.
It works well when your site is genuinely simple, you have someone with HubSpot or front-end capability, and your timeline has some room for a learning curve. Buy a theme close to your target design, configure it, rebuild your pages, set up your redirects, and you're live.
Be honest with yourself about the conditions, though. Self-migration means owning the URL mapping and redirect strategy, the metadata transfer, the schema markup, the form rebuilds and CRM mapping, and the launch-day cutover. The build is usually the easy part; the SEO preservation is where self-migrations can go wrong, and the damage tends to be invisible until rankings drop weeks later.
One useful middle path: handle the build yourself and bring in help for the technical SEO and launch steps specifically. It's a much smaller engagement than a full migration and it protects the part that's hardest to recover.

Another path - Have a partner build out the building blocks like theme, templates, modules and possible one unique page of each kind. With the basics in place, your team can effectively clone the base assets to scale up the content

Option 3 — Treat it as the trigger for a rebuild

If you asked for a migration, you have already indicated that your current site is worth keeping. A rejection may be a reasonable moment to re-examine that assumption particularly if the complexity that caused the rejection is a complexity you've been meaning to retire anyway.
Discuss these questions in your team : When was the site last redesigned? Are the pages HubSpot couldn't move pages you'd genuinely miss? Is the plugin stack solving problems you still have? Does the current design reflect where the business is now, or where it was three years ago?
If several answers point the same way, rebuilding on Content Hub may cost less than migrating faithfully. You stop paying to preserve things you no longer want. A rebuild also lets you design around HubSpot's strengths from the start: CRM-connected forms, personalisation, topic clusters, and a module library built for how your team actually publishes.
However, if the answers point the other way i.e. your site works, it converts, you just need it on a better platform, then migrate it properly and don't let anyone talk you into a redesign you don't need.