What No Migration Tool Moves Into HubSpot

Most migration planning starts from the wrong question. "What does this tool move?" produces a different answer for every source platform and sends you comparing feature matrices.

The more useful question is the one with a single answer: what does nothing move, whatever you are leaving?

Five things. They are the same five whether the client is coming off Salesforce, Marketo, Pipedrive, Klaviyo or a WordPress install, because they are constraints of the destination rather than gaps in any particular product. In our experience they also account for the majority of the hours, which is why quoting from the record count understates almost every migration.

1. Reports and dashboards

HubSpot publishes no public endpoint that creates a report or a dashboard. There is a reporting API for reading analytics data, and a beta flow that lets a public app receive shared reports, but nothing that builds a report inside a portal programmatically.

Every migration product is built on that same public API, so every one of them stops in the same place. When a marketplace listing implies report support, it is describing something narrower.

The consequences are worth naming to a client early:

• Reporting is manual rebuild work, always, on every project.
• A standard reporting pack cannot be templated across client portals. An agency selling productised reporting builds it by hand every time.
• Report logic cannot be audited programmatically. Records, properties and workflows can be enumerated over the API and checked. Reports have to be opened and read by a person, which is why reporting is the least-audited layer in nearly every portal we inherit.

The saving grace is that most of the inventory does not need rebuilding. Portals accumulate reports the way they accumulate everything else: on one audit we found 1,306 reports, most of them stale; on another, 222 of 282 were owned by three former agencies' email addresses. Agreeing the surviving list is the first deliverable and usually shrinks the project more than any technical decision.

2. Web analytics history

This one is absolute and worth saying out loud before the client discovers it.

HubSpot's page view and visitor data is generated by its own tracking code. A contact's browsing history in HubSpot begins the day that code goes live on the site. There is no import, no backfill and no vendor who can supply one.

It does not matter how much the previous platform recorded. Ten years of visitor history stays where it was generated, and the client's HubSpot analytics start from zero.

Two practical consequences. First, install the tracking code as early in the project as the client will allow, because every week it is live before cutover is a week of history they will have rather than not have. Second, if year-on-year web reporting matters to them, plan to keep read access to the old system for a period rather than promising continuity that cannot exist.

3. Automation logic

Workflows do not move. They are rebuilt.

This is less a limitation than a category error: triggers, branch conditions and actions are expressed in terms specific to the platform that ran them. A Marketo program and a HubSpot workflow are not two encodings of one thing.

So the work is translation, and translation is where the scope decision lives. The number that matters is not how many automations exist, it is how many are still doing something. Every portal carries automations that were switched on for a campaign that ended years ago and never switched off.

Rebuild the ones in use. Document the ones you are not rebuilding, and get that list agreed in writing before anything runs, because "where did our workflow go" is a conversation that goes much better with a signed inventory in it.

4. Templates and design assets

Email templates, landing page templates, modules and the design system around them are rebuilt in HubSpot's own structures. Nothing carries across from another platform's template language.

The trap here is that this work is invisible in a data-shaped quote. A migration priced per record has no line for the fourteen email templates the client considers essential, and those templates are a real design and build project with its own review cycle and its own approvals.

Count them during scoping, look at them, and quote them. Then apply the same reduction as everywhere else: the client almost certainly needs a fraction of what exists.

5. Permissions, teams and ownership structure

Users, teams, permission sets and record ownership rules are reconfigured by hand. The structure that grew inside the old platform over several years is rebuilt in an afternoon of decisions, and the decisions are the hard part.

This is the item most often discovered on the day of go-live, because it is nobody's obvious responsibility. The data team assumes it is an admin task, the admin assumes it came across with the data, and the sales manager finds out when their team cannot see their own pipeline.

Put it in the plan as a named workstream with an owner, however small it looks.

The sixth one, which nobody puts on a checklist

Sending reputation does not migrate either, and it is the item most likely to be discovered by the client rather than by you.

Reputation is built by the sending domain and the sending infrastructure, and engagement such as opens, clicks and spam complaints is what feeds it. None of that history follows a list into a new platform. The contacts arrive; the credibility does not.

Two things follow, and both need to be in the plan rather than discovered in week one.

Authentication has to exist before anything sends. You cannot send with the client's domain in the From address until that domain is connected to HubSpot through DKIM. This is an IT task on the client's side, it sits outside your control, and it is a standard cause of a launch date slipping by a week.

Volume has to be rebuilt gradually. HubSpot's guidance is to move volume across slowly, start with the most engaged contacts, and increase over the following 30 to 60 days. On a dedicated IP the add-on runs an automated 40 day warm-up.

The practical consequence is a scheduling one: the client cannot migrate on a Friday and send the quarterly newsletter to the full database on Monday. If a campaign date is already in their calendar, that date is a project constraint, and it needs to be surfaced during scoping rather than four days before the send.

What does vary by platform

Everything else is genuinely platform-specific, and this is where the detail matters:

• How much activity history the native connector brings, and whether it backfills at all. The Salesforce integration, for example, syncs activities forward and does not backfill history retroactively.
• Whether attachments and files are covered, which they frequently are not.
• How the source models things HubSpot models differently, which is where Marketo and Pardot projects consume their hours, and where the ecommerce and lifecycle concepts in Klaviyo need explicit mapping rather than a field match.
• What the source simply does not have, which is the shape of a Mailchimp or Pipedrive project: less to move, more to design.

We keep the field-by-field version of each of these on the individual migration pages, because the answers really are different per platform. The five above are the ones that are not.

What this does to a quote

Three habits, and they apply to every project in this category.

Split the quote at the boundary. Data migration, schema, lists and content in one section, priced as automated work. Reports, automations, templates and permissions in another, priced as manual build hours against an agreed inventory. One combined number invites the client to assume the whole thing scales with record count, and half of it does not scale that way at all.

Inventory before you price the rebuild. Count what exists, then agree what survives. This is the single largest lever available on a migration budget, and it is a conversation rather than a technical exercise.

Say the constraint in week one. "Reports cannot be moved by any tool, so we will rebuild the ones you still use, and here is what that costs" is an easy sentence early and an unconvincing one in week six.

The bottom line

Reports and dashboards, web analytics history, automation logic, templates, and permission structure do not migrate from any platform, because the limits are in the destination rather than in the tool. That set is usually the majority of the work.

Install the tracking code early, inventory the reports and automations before pricing them, quote the rebuild separately from the data, and name the constraint in the first conversation rather than the sixth week.

If your agency is quoting a client off any platform and wants the rebuild scoped honestly before the number goes out, our white-label HubSpot migration team scopes and delivers these under partner brands.