Migrate a site from WordPress to HubSpot: what is left out?

The fear is legitimate, and worth saying plainly: yes, you can lose organic traffic when you migrate WordPress to HubSpot. Not because the platform ranks worse, but because every switch rewrites the address of pages Google spent years indexing, and an address that changes without telling the search engine means starting over.

The good news is that this is an execution problem, not a platform problem. The loss mechanism is known, documented and avoidable. What is not avoidable is the gap between what HubSpot's official migration service does and what an educational institution's site actually contains.

Student portal, applicant portal, tuition calculator, program search by campus: none of that falls inside the standard scope. Whoever discovers that list mid-project rebuilds the budget.

Is it worth leaving WordPress and migrating to HubSpot?

It is worth it when the gain is operational, not aesthetic. Moving the site to Content Hub makes sense if you need content that changes according to the contact in the CRM, publishing that does not depend on a chain of plugins, and a single place to measure the applicant's journey. It is not worth it if the motivation is fatigue with WordPress.

Caption: to migrate WordPress to HubSpot is to rebuild the pages on the platform and redirect the old addresses, not to copy files

That distinction saves an entire project. A well-maintained WordPress site ranks well; what it does not deliver easily is the native link between what the visitor sees and what the CRM already knows about them.

Three gains support the switch. Publishing stops depending on a chain of plugins, which broadens the scope of what gets solved when you move the site to Content Hub.

Content starts responding to data, and personalization by visitor profile only exists when page and CRM live on the same platform. Measurement also stops being reassembled: page, form, email and deal in the same report.

Against that, there is a cost nobody puts in the spreadsheet: everything solved today by a plugin needs another answer. That is where the decisive part of the assessment begins.

What are the routes to migrate WordPress to HubSpot?

There are three. HubSpot's official migration service, which rebuilds the pages with a dedicated Replatforming Specialist. A migration run by your own web team or by a partner, with full freedom of scope. And the hybrid model, where the official service handles the standard volume of pages and someone else handles separately what it does not cover.

The hybrid is the most common at an educational institution, and it is rarely planned as such.

The official service works on a logic of scale: rebuilding pages using HubSpot's Migrations Base theme or a Template Marketplace theme, with a child theme for customizations. It is predictable, has a stated timeline and an assigned specialist. In exchange for that predictability, it draws a firm line around what it accepts.

The partner or internal team route inverts the equation. It accepts any scope, including rebuilding a student portal or a calculator, and for that reason has no standard timeline or list price.

Before any route, one dependency has to be resolved. No migration finishes without the domain connected to the platform, and the decision about which subdomain hosts each content type comes first, because it determines the URL structure you will be redirecting.

What does the official migration service include and exclude?

The service includes the visual and structural rebuild of the pages in a HubSpot theme, with a child theme, editable templates and support from a Replatforming Specialist. It excludes everything involving application logic: login, gated areas, ecommerce, advanced forms, database-driven content and third-party integrations.

That list is the heart of the decision, and it breaks down like this:

Table: Scope as stated in the official migration process documentation and on the service page; the right-hand column is not an exception, it is a published rule.

Now translate the right-hand column to an educational institution's site.

Student portal and applicant portal are gated content. Tuition calculators and financing calculators are advanced forms. Program search by campus, hub or modality is database-driven content. A multi-stage admissions application is a multi-step form. A support chat bought from another vendor is a third-party integration.

At many education portals, that describes more than half of what exists beyond the institutional pages.

It does not mean the migration is unfeasible. It means the project has two fronts, and every system outside the scope has three ways out: stay where it is and be reached by a link, be rebuilt in HubSpot with custom development, or be replaced by a native feature.

In migration projects, the most common mistake is not picking the wrong way out. It is not realizing the choice exists until someone asks where the student portal went.

How long does migrating a site to HubSpot take and how many pages fit?

The official migration process documentation states that most migrations are completed within two to four weeks after materials are received, with larger projects potentially taking longer. The service covers up to 150 pages, and pages in alternate languages can count toward that total when hosted on the same subdomain.

The clock starts when materials are submitted, not when the contract is signed. The gap between signing and submitting explains much of the schedules that blow up. The process has six phases: request and assessment, agreement and payment, materials collection, queue, execution trackable in the Migrations tab under Account & Billing, and review with a report.

The two to four weeks cover execution, and materials collection is the phase that delays most, because it requires the complete page inventory.

Three constraints deserve to be in the plan from day one:

1. The current site has to stay live throughout the migration. It is a stated condition. The work is done from the production site, so taking WordPress down before the end interrupts the process.
2. Changes made after approval are not reflected in the migrated content. If the team publishes or rewrites a page after approving the material, the change stays in WordPress. Freezing editorial production during execution avoids the surprise at go-live.
3. The design review window is 60 days. It pays to review page by page in the first weeks, not on day fifty-nine.

On cost, a caveat is necessary: the official page presents the charge as a setup fee plus a per-page amount, but in the version consulted the figures appeared in Canadian dollars.

Any converted number circulating is an unofficial estimate, and the amount applicable in your country has to be confirmed directly with HubSpot or with a partner.

How do you avoid losing SEO when migrating CMS to HubSpot?

By preserving the address or telling the search engine it changed. Every URL that existed and stops existing has to point to the equivalent page on the new site, with a 301 code. Without that map, each old page returns a 404, the external link that pointed to it stops passing authority and the position you earned dissolves.

The work starts with an inventory, not with the platform. Before any configuration, you need the complete list of the site's URLs, cross-referenced with organic traffic and inbound external links.

It answers three questions: which pages take priority for rebuilding, which can be consolidated and which can be retired with a redirect to the corresponding section.

Pages with a traffic history and external links are untouchable: keep the URL identical whenever possible, because a preserved URL needs no redirect.

The tool sits in Settings, under Content, in Domains & URLs, on the URL Redirects tab, and is available in Marketing Hub and Service Hub Professional or Enterprise, and in Content Hub from Starter up. The 301 code, permanent, is the default applied to new redirects, and it is what you want in a migration.

For volume, there is bulk upload via CSV file, with export available too. A 150-page site generates well over 150 mapping lines once you add old variations, URLs with parameters and addresses from closed campaigns.

Here is the limitation that causes the most broken links in a migration. HubSpot redirects only work on domains connected to and hosted by HubSpot. If part of the site stays hosted elsewhere, the redirects for that stretch have to be configured at the origin hosting provider, because the platform has no reach over an address it does not serve.

That is what turns the hybrid scenario into a trap. You migrate the institutional pages, keep the student portal on the old server, create the redirects in HubSpot and assume you covered everything. The URLs under external hosting never pass through the platform.

After go-live, monitoring is worth as much as the map. The platform surfaces SEO recommendations in the tool itself, and combining that with a routine of content optimization for search is what sustains the gain.

Monitoring crawl errors in the first weeks reveals the forgotten URL before the search engine treats it as a dead page.

Standard or flexible pattern redirect: which one should you use?

HubSpot offers two types. Standard is one-to-one: one old URL points to one new URL. Flexible pattern updates URLs by structure, applying a rule that covers a set of addresses at once. The first is precise, the second is economical.

The choice depends on whether the old pattern is genuinely regular:

Table: Types and codes as described in the redirect tool's documentation.

The classic mistake with flexible pattern is trusting the regularity without testing. A rule written for /courses/ also captures /short-courses/ if it is not well bounded, and the result is pages redirected to the wrong place with no visible error. Nobody sees a 404, because the page exists, it just is not the one the visitor asked for.

Anyone who has done this several times uses flexible for volume and standard for anything with meaningful traffic: a broad rule for what is homogeneous, manual mapping for what is valuable.

One last warning about the 302: used by mistake in a permanent migration, it instructs the search engine to keep the old address as canonical. The authority signal does not transfer, and the drop appears weeks later, when nobody is looking at the configuration anymore.

What is HubSpot's go-live checklist before switching DNS?

The documentation defines a nine-step sequence, and the order is part of the instruction. Forms and blog first, then system templates, favicon, analytics and the SEO review, next the bulk upload of redirects and, only at the end, connecting the domain and updating DNS.

DNS is the switch: anything wrong when it flips is wrong in public. In the official order:

1. Review and customize the migrated forms. A migrated form usually arrives with a missing field, the wrong notification destination or no consent fields. Testing each one with a real submission avoids discovering the problem through the absence of new contacts in the CRM.
2. Configure the blog settings. Title, description, authors, URL structure and listing and post templates. Done before DNS, this defines the addresses where the archive will live.
3. Apply the system templates. The pages nobody remembers until they need them: 404 error, 500 error, password page, search and email preferences. Without them, the platform's generic default appears.
4. Upload the favicon. Quick to do and visible when missing.
5. Integrate Google Analytics. Keeping the historical series across the migration lets you compare before and after.
6. Exclude internal traffic from analytics. Without it, the first weeks record your own team reviewing pages, exactly when you need a clean reading.
7. Review the SEO recommendations. The platform flags missing titles, empty meta descriptions and structural problems.
8. Bulk upload the URL redirects. The documentation is explicit: upload redirects for any URL change to avoid broken links, and this comes before DNS.
9. Connect the domain and update the DNS records. The SSL certificate is provisioned after the connection, with a documented window of up to four hours, which argues for doing this a day before any public announcement.

The list does not mention one item that deserves its own attention: confirming that traffic measurement is actually firing on the new pages. On content hosted by HubSpot, tracking is automatic, but in a hybrid scenario validation remains manual.

What goes wrong when migrating an educational institution's site?

The problems repeat in a handful of patterns, and almost none are technical. They are a badly inventoried scope, an ignored recruitment calendar and a forgotten URL. Recognizing them early changes the schedule and the budget, because they all appear after signing and before go-live, when fixing costs more.

1. Counting pages from the menu. The menu shows 60 pages, the sitemap shows 400. The difference is a discontinued program, a landing page from an old admissions cycle and content someone published and never linked again. All of them have an indexed URL, and some still get traffic.
2. Ignoring gated content until the end. The student portal and applicant portal fall outside the official service, and the decision about them affects enrollment. It has to be made during the assessment, with the academic team in the room.
3. Migrating in the middle of the recruitment cycle. Switching platforms with applications open adds risk to revenue. The good window is between cycles, and it is short.
4. Leaving the content freeze implicit. Someone has to formally tell the editorial team when production stops. Without that agreement, the new site is born outdated.
5. Forgetting the addresses that live outside the site. A QR code on printed material, a link in a paid ad, a URL in a published PDF notice. None appears in the sitemap, and all break if the URL changes without a redirect.
6. Treating the migration as a technology project. It decides information architecture, content priority and the conversion path, which puts it in marketing strategy territory and not only in infrastructure.

It is worth placing the migration inside the full account setup roadmap, because it rarely happens in isolation from the other implementation fronts.

What usually stalls the schedule in practice is always the same: the inventory takes longer than the execution.

Frequently asked questions about migrating WordPress to HubSpot

So when does migrating to HubSpot pay off?

When the operational and personalization gain outweighs the cost of resolving, one by one, the systems the official service does not cover. That calculation cannot be made with a generic estimate: it depends on how many pages the site has, how much content sits behind a login and how regular the current URL structure is.

On the fear of losing traffic, the answer is reassuring and demanding at the same time. Reassuring because the loss has a known cause, which is a URL changing without the correct redirect. Demanding because avoiding it is not a setting, it is a complete inventory bulk-uploaded before switching DNS and monitored afterwards.

Three numbers decide the shape of the project before any proposal: how many indexed URLs the site has today, how many of those received organic traffic in the last twelve months, and which features depend on login, on a database or on a multi-step form.

Those numbers are in no article, including this one, because they belong to your site. They determine whether the official service is enough, whether the route is hybrid or whether the migration has to be sliced.

The mkt4edu team works with site migration and HubSpot implementation in student recruitment operations, and you can talk to us to build that inventory before committing a timeline and a budget.