HubSpot Migration Services: What Moves, What Is Rebuilt, What Is Abandoned

A business asks three firms to quote a migration from its current CRM to HubSpot and receives numbers that differ by a factor of four. Each firm has scoped honestly against a different assumption about one question: how much of the existing configuration comes across. The cheapest quote assumes records move and the rest is rebuilt from a short conversation. The dearest assumes every report, automation and custom field has an owner who will object to losing it. Neither firm asked the question, because answering it requires a usage audit that nobody has run.

This article sets out what a migration service contains, and how a buyer should scope one before requesting quotes. It begins with the three dispositions every configured object receives, then gives the test that assigns them, which is a data question rather than a matter of opinion. It then works through what reliably moves, what has to be rebuilt and what should be abandoned, before covering cutover sequencing, the reconciliation that proves the migration worked, and how these projects are priced. The antipatterns and the verification checks close the article out.

The Six Workstreams

Six workstreams, and a proposal that names fewer has scoped some of them out, deliberately or otherwise.

Audit. An inventory of what exists in the source system and, separately, of what is still genuinely in use. This workstream determines the size of the other five, and it is the one skipped to produce a cheap quote.

Data model design. The structure of the target, derived from how the business actually sells rather than inherited from the shape of the source system.

Data migration. Records mapped, deduplicated, imported and then reconciled against the source.

Configuration rebuild. Automations, reports and computed fields expressed again in the idiom of the target platform.

Integration rework. Every system connected to the source must connect to the target, and a connector that existed for one may not exist for the other.

Cutover and enablement. The switch itself, the parallel period, and the training that determines whether anybody uses what was built.

The Three Dispositions

Every configured object in the source system receives exactly one of three dispositions, and the middle one carries the project.

The common error in a proposal is offering only the first and the third of them. A migration that treats everything as move-or-abandon either ports an idiom the target does not speak, producing a configuration that works badly and confuses everybody, or discards behaviour somebody still depends on and discovers it at the worst moment.

The actual counts from one engagement, including how many automations survived the usage test, are in the Salesforce to HubSpot migration case study.

The Usage Test

Assigning dispositions is a question of evidence rather than opinion, and that evidence already exists inside the source system.

For automations, the test is execution history over the preceding twelve months. An automation that has not fired in twelve months is not in use, whatever anybody remembers about why it was built. Most source systems expose this, and where they do not, the log can usually be reconstructed from the records it would have touched.

For reports, the test is how many times each has been opened. A report nobody has opened in a year is not a report, it is a saved query. Report libraries accumulate without limit because nothing forces deletion, and the proportion that survives a view test is routinely under a fifth.

For fields, the test is the population rate on records created within the last year. A field populated on two percent of records created in the last year is either abandoned or is capturing an exception that deserves a different treatment.

For everything, there is a defence step: the list of proposed abandonments circulates, and anybody may defend an item by naming a use. Defence by assertion is enough — the point is to catch the quarterly report the audit could not see, not to litigate.

The audit is the cheapest phase and the one that determines the price of the rest. A business that runs it before requesting quotes will receive comparable numbers instead of the spread described in the opening.

The Move Disposition

Records move, along with the fields that carry them. Contacts, companies, deals and their equivalents move through an import or an API load, so the work sits in mapping and deduplication rather than in the transfer itself.

Two qualifications matter. Activity history moves with varying fidelity: emails and calls usually come across, engagement detail frequently does not, and year-on-year comparison restarts at cutover unless that is addressed deliberately. Attachments are the second: they are held outside the CRM's own storage in many systems, so they migrate as a separate exercise carrying its own volume problem.

Field mapping is where the work nobody quoted for actually sits. A source field is either mapped to an existing target property, mapped to a new one, transformed, or abandoned with a reason. Each decision is individually trivial and there are hundreds of them, so the audit's field inventory becomes the document the whole migration runs on.

The Rebuild Disposition

Anything expressing behaviour rather than simply holding data belongs in this disposition rather than the first.

Automations are rebuilt because platforms differ in what they can express and in what they make easy. A source automation that polls for a condition every night may be a single trigger in the target, and porting it literally produces something that works and nobody can maintain.

Reports are rebuilt because they depend on the target's data model, which is not the same as the source's. A report rebuilt against a better model is frequently simpler than the original; one rebuilt against a model that copied the source's compromises inherits them permanently.

Computed and formula fields are rebuilt because their syntax does not transfer, and this is the category where a straight port is most tempting and least advisable. Each one presents an opportunity to ask whether the calculation it performs is still the correct one.

Permissions and record visibility are rebuilt because the two platforms model access differently, and this is the workstream where a difference in model can mean a rule the target cannot express. Establishing that early matters, because the remedy is a policy change rather than a configuration change.

Cutover

Three sequencing decisions carry most of the risk in this phase.

Parallel or hard cutover. Running both systems briefly is the safer option and costs discipline, because a business with two live CRMs will put data into both unless one of them is made read-only. A hard cutover is cleaner to run and unforgiving of anything the audit happened to miss.

Freeze window. This is the period between the final export and go-live during which the source system must not change. Longer freezes are operationally expensive, and shorter ones require a delta load, which amounts to a second migration in miniature.

Integration switchover is the third, and it has to land with the cutover rather than at any point after it. An integration still writing to the source after go-live produces two divergent systems and a reconciliation nobody budgeted for.

Reconciliation

This is the step that proves the migration worked, and it is routinely reduced to a record count.

A record count is necessary, and it is nowhere near sufficient to establish that the migration succeeded. Reconciliation should establish that totals match by object, that financial aggregates match — open pipeline value, closed-won by period — and that a sample of records is correct field by field, chosen to include the awkward cases rather than the convenient ones.

The sample is where the defects that matter actually surface. A mapping error affecting five percent of records passes a count comfortably and shows up immediately in twenty records read properly. Exporting both sides and comparing is more reliable than reading two interfaces side by side.

Pricing

These projects are priced on the audit's findings, so a quote produced without one is a guess.

The variables that move the number are the count of objects requiring rebuild rather than move, the number of integrations and whether they are bidirectional, the volume and cleanliness of records, and whether permissions can be expressed in the target at all. Two businesses on the same source platform with the same record count differ by several times on those variables.

Time and materials suits this work because the audit changes what is known partway through it. Fixed fee is available where an audit has already been completed and the scope is genuinely settled, which in practice means the audit is a separate, smaller engagement that precedes it. A fixed price quoted before an audit is pricing the provider's risk rather than the work itself.

Antipatterns

Quoting before auditing. This produces the fourfold spread described in the opening, and the cheapest quote wins on a basis nobody can examine.

Move-or-abandon only. This either ports an idiom the target does not speak or discards behaviour somebody still depends on.

Migrating the configuration rather than the requirements. This reproduces decisions nobody would make again, and does it in an unfamiliar system.

Reconciling on counts alone. A mapping error affecting five percent of records passes a count comfortably.

Integrations switched after cutover. This produces two divergent systems and a reconciliation nobody budgeted for.

No defence step. The quarterly report nobody happened to run during the audit window is abandoned, and its absence is discovered at quarter end.

History assumed to move. Engagement detail frequently does not come across, and nobody notices until somebody requests a year-on-year comparison.

Verification Before Signing

1. An audit has been run, covering automation execution history, report view counts and field population rates on recent records.
2. Every source object carries a disposition, with rebuild costed separately from move rather than folded into one number.
3. A defence step exists with a stated deadline, so an abandonment can be challenged by naming a use.
4. The reconciliation plan is field-level rather than count-only, and names the sample it will read.
5. The integrations switch at cutover rather than afterwards, each with a named owner for the switch itself.

A provider able to answer those five has scoped the work, and one who cannot has priced an assumption instead.

Boundaries of This Article

This article describes migration to HubSpot from another CRM. Migrating from spreadsheets is a smaller exercise dominated by data quality rather than configuration, and migrating a CMS is a different discipline.

The object APIs and the data model documentation are the reference for what the target can hold. What it should hold is a design question this article treats in outline only.

The method used here is set out at length in CRM data migration, and sector-specific accounts exist for a law firm and a Zoho migration.

In Summary

Every configured object in the source system gets one of three dispositions: move where the target holds the same thing in the same shape, rebuild where the behaviour is still wanted but not portable, abandon where usage condemns it and nobody defends it. Offering only the first and third is the error that makes migrations either unusable or lossy.

The disposition is assigned by evidence rather than opinion — automation execution history, report view counts, field population on recent records — followed by a defence step that catches what the audit window could not see.

Running the audit before requesting quotes changes what comes back from the providers. It is the cheapest phase and it determines the price of every other one, which is the difference between three comparable proposals and three numbers differing by a factor of four for reasons nobody can explain.