Migrating a wealth-advisory firm off Redtail to HubSpot

1 This was a platform migration, not a CRM swap

The instinct on a CRM change is to export contacts, import contacts, and treat the rest as configuration. For an advisory firm that framing collapses immediately. The unit of value isn’t the contact — it’s the household, the account, the relationships between people, and the process that moves money under supervision. Migrating the firm meant migrating all four: the data model, the history, the workflows, and the controls.

So the work began as an inventory of the source model, not an export. Every distinct kind of thing — and every process attached to it — was written down and asked one question: what represents this in HubSpot? The answers sorted into three buckets: has a native home, needs modeling, or has no home at all. The third bucket is the engagement.

2 The object-model gap

Redtail, like most vertical CRMs, keeps everyone in a single “contact” table, separated by a type flag: individuals, businesses, trusts, and associations all live together. HubSpot doesn’t work that way — people are Contacts, organizations are Companies, and a trust is neither cleanly. The migration has to shard one table into several objects and keep an Entity-Type property so nothing blurs in the split.

Two source entities have no native HubSpot object, and they are the two that matter most to an advisor: the investment account and the household — the reporting and billing units the firm actually thinks in. You can approximate accounts as deals and households as companies on a lower tier, and it demos fine. It breaks the moment relationships need labels.

3 The association graph is the firm

A firm like this carries a dense web of relationships, and the web is the business: spouse to spouse, parent to child, trustee and beneficiary to a trust, owner and joint owner to an account, head of household to member, attorney and CPA to a client. Dozens of distinct relationship types, many on the same pair of records at once.

HubSpot can represent this — with custom association labels and multiple labeled associations per record pair. Both are Enterprise features. On Professional they import unlabeled, every relationship flattens to a generic link, and the graph that makes the firm legible collapses into noise. It is the most consequential scoping decision on the project, and it is invisible in a demo.

4 A decade of fields, encoded as text

Because the source lacked dedicated fields for many attributes, the firm did what every team does: crammed them into keyword strings and user-defined fields — client tier, do-not-solicit flags, plan types, custodians, prospect stage, all as text. Carrying them verbatim would move the mess across; the value is in parsing them apart into typed properties that workflows and reports can use.

The build defined a couple hundred properties grouped by business process — tax, billing, compliance, retirement plans, communication — so a record stays navigable instead of becoming a wall of fields. Keyword clusters became single- and multi-select properties; fee blobs split into an amount and a date; legacy duplicates were archived, not deleted, so nothing was destroyed on the way in.

5 Compliance is a process you rebuild, not a field

The heaviest part of the platform wasn’t data — it was process. The firm ran 60+ compliance and service workflows that had always lived on the advisors’ shoulders: money movement, account maintenance, document collection, review cadences. Each one was reviewed, rationalized, and rebuilt in HubSpot as a ticket pipeline with stage requirements and conditional routing — and, deliberately, moved off the advisors onto a customer-service team so the people who close business stop doing operational paperwork.

The requirement that shaped the build: work had to be assignable to a team, not a person. A request enters a queue and whoever is available picks it up — no bottleneck on one owner’s inbox, no dropped item when someone is out. Supervisory controls are enforced by the pipeline itself: a money movement above a set threshold to a third party cannot advance until a principal approves it, and the approval is a recorded step, not a remembered one.

6 A migration you can run twice

At this scale the load has to be idempotent — safe to run again without doubling anything — because you will run it again. The mechanism is worth stealing: give every record a unique external-ID property carrying its source identifier, and match on it. A note stamped with its source ID can’t import twice; an activity stamped with its source ID maps to a single task no matter how many times the load runs.

Because the standard export silently dropped columns, extraction was rebuilt against the source API with that ID as the key of record. Every write was logged with counts and a verification step, and a reconciliation pass compared HubSpot against the source field by field — with explicit logic never to recreate a record that already existed. That is how a decade of history — thousands of households and accounts, a six-figure volume of notes, a dense web of labeled relationships — lands once, correctly, and stays that way.

7 What changed

The firm now runs on a platform that matches how it works. Households and accounts are first-class records; a decade of relationships carries its real labels; and the full client history is intact and searchable in one place instead of split across a legacy tool and a stack of spreadsheets. Compliance and service work moved off the advisors into team-assigned pipelines, so the people who advise clients stopped doing operational paperwork and the firm can prove its controls instead of asserting them.

Details are generalized and figures are representative of the engagement; specifics vary by firm.

8 The model, generalized

Strip away the vertical and the exercise is reusable for any platform migration into HubSpot:

• Inventory the source model and its processes first — objects, properties, associations, and the workflows on them — before any export.
• Find what has no native object. That is where custom objects go, and it usually decides the tier.
• Treat labeled relationships as data, not garnish. If association labels matter, that is an Enterprise decision.
• Rebuild process as team-assignable pipelines with approval gates — queues, not single owners.
• Make the load idempotent with external IDs before the first record moves.