I keep seeing the same headline in different costumes. Are admins obsolete? Is AI putting consultants out of work? Is this the end of the CRM career? And I'll be honest- I do this work sitting at a computer, so when someone says "AI is coming for the people who sit at computers," I'm in the blast radius by definition. I'm not going to pretend that didn't make me think.
So I did the thing I'd tell any client to do before a migration: I stopped reacting to the headline and went and looked at the actual data model.
Here's what I found. AI is excellent at the part of a Salesforce-to-HubSpot migration that was never the hard part. And it is structurally, not temporarily, bad at the part that is. If you're a RevOps leader staring down a Salesforce exit, that distinction is the difference between a migration that lands clean and one that quietly amputates the most valuable thing your old org knew.
Let me show you exactly where the line is. I'm going to use Financial Services Cloud, because FSC is where this gets brutal and obvious.
Open HubSpot's native Salesforce import, or hand the job to an LLM with API access, and the demo is genuinely impressive. Salesforce Contact becomes HubSpot Contact. Account becomes Company. Opportunity becomes Deal. Custom fields line up, picklist values translate, the record counts reconcile at the end. You export 40,000 records, you import 40,000 records, the math checks out, everyone goes to lunch.
And for a plain-vanilla Sales Cloud org, that's mostly fine. The tooling has earned its reputation here. This is the deterministic, well-specified, field-level work — and yes, that work is getting automated, and that's okay. I don't bill for that work either.
The trouble is that nobody runs Financial Services Cloud as a plain-vanilla org. The entire reason FSC exists is to model a structure that doesn't fit in flat fields. And a field-level migration — human or machine — moves every record perfectly while silently destroying that structure. Every record arrives intact. The graph connecting them does not.
In FSC, the value isn't in the Contact records. It's in the relationships between them. Three things carry that, and none of them is a field:
1. The Household. A wealth advisor doesn't manage 600 individuals. They manage ~250 households, each containing multiple people. In FSC a household is an Account (with a Household record type), and the people in it are linked through junction records (not through a "company" field on the contact). The household is a first-class entity with its own rollups and its own relationship to the advisor.
2. Account-Contact Relationships (ACRs). This is the part that field mapping cannot see. In standard Salesforce a contact belongs to one account. In FSC, a single person relates to many households and accounts, each relationship carrying a role: Spouse. Trustee. Power of Attorney. Beneficiary. Primary Advisor. Accountant. These roles aren't fields on the contact — they live on the relationship itself, in the junction object. A contact-level importer has no column to put them in, so it doesn't. They evaporate.
3. Reciprocal roles and Relationship Groups. FSC roles are bidirectional and paired. If Person A is the Trustee for Person B, Person B is Trusteed by Person A. The org stores both directions and the membership of each person within the household group. That reciprocity is structural, and a one-directional contact import flattens it.
Now layer on the derived data: household-level rollups like total assets under management, aggregate held-away assets, total revenue per household. In FSC those are live calculations that recompute as accounts move in and out of the household. They are not stored truths. They are functions of the graph.
Here's the teardown, stated plainly. When you run a naive FSC migration:
And here's the part that should genuinely scare a RevOps director: the record count still reconciles. 40,000 in, 40,000 out. Every validation that operates at the row level passes. The data loss is invisible to exactly the checks AI is good at running, because the thing you lost was never in a cell. It was in the wiring between the cells.
Six weeks later an advisor opens a household and can't see who the trustee is. Nobody can explain when it broke, because technically nothing broke. Everything migrated.
This is the work I actually do, and it's the work that doesn't compress into a mapping table:
Decide what a household becomes in HubSpot before moving a single record. HubSpot has no native household object. You have three defensible options — model households as Companies, build a custom Household object (Enterprise), or carry the structure in labeled associations — and each one trades something away. The right answer depends on whether the firm reports at the household level, whether advisors need household rollups in-app, and how the post-migration RevOps workflows are going to query the data. That's a judgment call about the business, made before you touch the API. There is no correct field mapping for a decision you haven't made yet.
Rebuild the ACR roles as labeled associations, not lost metadata. HubSpot supports many-to-many associations between contacts and companies with association labels, and they're bidirectional. That's where Trustee / POA / Spouse / Beneficiary has to land as labeled, reciprocal associations that preserve both the many-to-many cardinality and the role semantics. Building that label taxonomy correctly, and writing the transformation that reads the FSC junction and reconstructs each labeled edge, is the entire job. It is also precisely the step a field-level importer skips.
Reconstruct rollups as live HubSpot logic, not migrated numbers. You don't migrate the AUM total. You rebuild the calculation in HubSpot so it stays true after cutover. Migrating a derived value as a static fact is how you ship a CRM that's confidently wrong.
Reconcile on relationships, not row counts. My post-load validation doesn't ask "did 40,000 contacts arrive." It asks "does every household still have its trustee, and does every multi-household individual still touch all of their households." That's a reconciliation against the graph, and you can only write it if you understood the graph in the first place.
Here's where I landed, and why I'm not changing course.
AI is going to keep eating the deterministic layer of this work, and good. Field mapping, picklist translation, dedup passes, the first draft of a transformation script. Let it. That makes me faster, not obsolete, because the part that compresses was never the part anyone should have been paying a premium for.
What doesn't compress is the layer above the fields: deciding what a household is in the new system, knowing that the trustee relationship is the asset and the contact record is just the container, and being accountable when an advisor's screen has to be right. That's not a mapping problem with an answer waiting to be retrieved. It's a judgment problem under a high cost of error, where the failure mode is invisible to every automated check. AI doesn't do that work badly because it's early. It does it badly because it's a different kind of problem.
The migration tools map fields. I map households. As long as the most valuable thing in a Financial Services Cloud org is the relationship graph and not the cells, and that is never going to stop being true. There's a chair at this computer with my name on it.
I architect Salesforce-to-HubSpot migrations for mid-market firms — extraction, bi-directional sync, and the relationship modeling that field-level tools skip. If you're planning an FSC exit and want it to land without quietly losing the household graph, let's map your current data model together.