You've made the decision. The per-seat math didn't work, or the schema finally stopped bending far enough, or the integrations you needed were locked behind a tier that didn't make sense for where you are. Whatever the reason, the decision is made: you're moving off HubSpot.
The previous article in this series covered headless CRM options in 2026 — the build/buy/self-host tradeoffs, the open-source landscape, the ecosystem risks most comparisons skip. This one starts where that one ends. You've picked a direction. Now comes the actual migration.
One scope note upfront. I'm writing about SMB and mid-market moves — teams in the 10 to 200 seat range, typically leaving HubSpot Professional or Enterprise, with internal engineering that can own the integration work. The patterns below translate cleanly to Pipedrive, Zoho, Freshsales, and similar mid-market SaaS CRMs.
Salesforce migrations are a different problem. Mature SFDC orgs carry customization depth, approval chains, CPQ, partner portals, territory rules, permission models, and reporting semantics that this article only touches in passing. The sampling heuristics here — a week of audit, 300–500 records to expose edge cases — are dangerously optimistic for a serious SFDC decommission. Treat this article as applicable to HubSpot-class systems and translate carefully if your starting point is enterprise SFDC. I'm also not covering cold-start deployments (teams who've never had a CRM).
What Should Have Kept You on HubSpot
Before the practical sections, one honest framing.
HubSpot isn't a bad product. It's a product that has stopped fitting a particular situation. Those are different problems, and conflating them produces a migration that solves the wrong thing.
The cases where staying would have been the right answer: your pipeline is conventional (Contacts, Companies, Deals, Activities is your data model in full), your team size is stable, and your integration needs are covered by HubSpot's marketplace. If that's your situation and the trigger was cost, run the real TCO math including the migration project — most migrations in that profile end up costing more than two to three years of the SaaS subscription, especially if you include the productivity friction that follows a tool change.
The cases where moving is justified: per-seat billing is scaling badly as you add ops and support people who need read access but don't need the full platform, you've hit a schema limit that's forcing you to maintain a parallel database just to hold the data HubSpot can't model, your automation needs have outgrown what Operations Hub can handle without hitting API rate limits, or you have data sovereignty requirements that the vendor can't satisfy.
If none of those apply, the migration will not fix the actual problem, and the problem will follow you to the new system. That's worth being certain about before you start.
The Process You Think You Have
Before the audit, an uncomfortable framing.
Migration planning implicitly assumes the organization has a process that can be ported. Workflows that are documented. Lifecycle stages that mean specific things. Pipeline transitions that follow rules. Custom properties that exist for reasons someone can articulate.
For most SMB organizations, this is not true.
The reality you're likely to find:
- Pipeline stages were created emotionally over three years by whoever asked. Some are duplicates of each other. One was added for a deal that closed in 2023 and never used since.
- Two of your three "official" customer onboarding workflows are actually run in a contractor's Zapier account that nobody has the password to.
- Sales reports come from Excel exports that someone tweaks manually on the way to the executive team. The HubSpot dashboard and the executive deck have never matched.
- "Lifecycle stage" means one thing to marketing, a different thing to sales, and isn't tracked by customer success at all.
- The single person who understands the lead-routing rules is six months from retirement.
None of this is unusual. It's what an SMB CRM looks like after three to five years of normal operation. But it means the migration is not just translating a system; it's translating a system that nobody fully holds in their head, into a system that has to be specified explicitly to be built.
If the audit reveals that the process you're migrating doesn't exist coherently, the migration cannot fix that. It can only force the conversation. Sometimes that's the right outcome — the team has been deferring the conversation for years, and a migration is the forcing function. Sometimes it's the wrong outcome — the team isn't ready to formalize, and the migration produces a new system that documents the same confusion at higher cost.
Notice which one you're in before you commit. It changes the project entirely.
Pre-Migration Sampling: A Week Before You Commit
The most reliable thing you can do before committing engineering resources to a migration is spend one week auditing actual usage. Not what people say they use — what the logs show.
Pull the following data from HubSpot's API or reports:
Login frequency by user. Export the last 30 days of login events and count per seat. In my experience, when I do this audit for teams considering migration, between 30 and 40 percent of active seats log in less than once per week. Some of those are legitimate — a finance person who runs one report monthly — but most are seats that are active on paper and unused in practice. This changes your cost model significantly, and it also changes your training and onboarding estimate for the target system.
Object access by type. Which objects does each team actually use? Sales teams live in Deals and Contacts. CS teams live in Tickets. Marketing lives in Campaigns and Lists. If your migration scope includes all objects but actual usage concentrates in two, you've just identified what to migrate first and what to deprioritize.
Workflow execution rates. Pull workflow activity for the last 60 days and look at which workflows are actually firing. I've found it fairly common that half the workflows in a mature HubSpot instance run fewer than 10 times per month. Some of those are quarterly processes; some are automations nobody turned off when the underlying need changed. Knowing which workflows are operationally critical versus dormant dramatically reduces migration complexity.
Integration write patterns. Which external systems are actually pushing data into HubSpot, and how often? An integration listed in the Connections panel that hasn't made an API call in 90 days is probably not critical path. One that fires every 15 minutes is. Map the dependency correctly before you touch anything.
This week of sampling almost always produces at least one surprise. Sometimes the surprise is that usage is more concentrated than expected — which makes the migration cheaper. Sometimes it reveals a dependency that wasn't visible in the original plan — a nightly sync from a third-party system that writes directly to custom properties, which nobody mentioned because the person who set it up left two years ago.
Don't commit to a migration timeline before you have this data.
The Shape of HubSpot's Data Export
HubSpot provides CSV exports and API access. Both have gaps you need to know about before you design a migration schema.
CSV exports are object-level, not relationship-level. You can export all your Contacts as a CSV, and all your Companies as a separate CSV. But the associations between them — which contacts belong to which companies, which contacts are associated with which deals — don't come cleanly in the CSV exports. You get association counts in some cases, but not the full association graph. For a target schema that needs to reconstruct those relationships, you'll need to pull associations via API, which is slower and requires pagination handling.
Custom property history is not in the standard export. If you care about when a contact moved through lifecycle stages, or who changed a property and when, that history is in HubSpot's timeline but not in the CSV export. It's accessible via the Timeline Events API and the Property History API, but those require explicit extraction. Many migrations deprioritize this data — "we'll backfill it later" — and then never do, because the target system works fine without it for day-to-day operations. That's a reasonable trade-off as long as it's deliberate. If your sales forecasting or reporting depends on historical stage transitions, plan for this extraction upfront.
Activity timeline is the hardest part. Emails sent from HubSpot, calls logged through the CRM, notes, tasks — the full activity feed — is stored in HubSpot in a structure that doesn't have a clean analog in most target systems. The common outcome is that historical activity gets exported to a read-only archive (a spreadsheet, a static view, a frozen snapshot in the new system) rather than being fully migrated as live, queryable records. That's almost always fine operationally: nobody needs to create a new task against a three-year-old email thread. But make the decision explicitly rather than discovering it mid-migration when the data mapping breaks down.
Schema translation is rarely 1:1. HubSpot's data model is opinionated. Companies and Contacts have a many-to-many relationship with specific HubSpot semantics. Deals have pipeline stages that are defined per-pipeline. If your target schema is more normalized or differently opinionated — and it usually is — you'll need explicit mapping logic that handles the edge cases. The edge cases are where the migration breaks. Contacts with no associated company. Deals with custom pipeline stages that don't map to your target stage model. Custom objects from HubSpot Enterprise that have no direct analog in the target. Build the mapping layer first, run it against a sample, and count the exceptions before running it against everything.
The Migration Plan Structure
A practical migration for a team in this size range typically breaks into four phases:
slug="api-integrations"
text="If the integration layer is what's making your HubSpot migration hard — extraction edge cases, cutover sequencing, broken syncs — that's the work I take on."
/>
Phase 1: Schema and data. Design the target schema, build the extraction scripts, validate the mapping on a sample of records (300–500 contacts is usually enough to expose edge cases), and run the full extraction. Target: all contacts, companies, deals, and their associations in the new system, with historical data correctly attached.
Phase 2: Integration cutover. Identify every system that reads from or writes to HubSpot — both via native integrations and via API/Zapier/webhook connections — and migrate those connections to the new system one at a time. The principle here is: never have two CRM systems simultaneously receiving writes from the same source. Split-brain data is much harder to reconcile than a brief blackout window. Maintain a clear cutover registry: which integrations are on the old system, which are on the new, and which are in the middle of being moved.
Phase 3: Email integration cutover. This deserves its own phase because it's the most fragile part. If your team is using HubSpot's email sequences, reply tracking, or inbox sync, those connections touch your mail server or email client directly. You cannot have two systems simultaneously tracking replies to the same thread without collisions. Plan for a hard cutover on email: a specific date when HubSpot's email tracking is disabled and the new system's is active. Communicate this clearly to your team before it happens.
Phase 4: Forms and website. HubSpot's embedded forms use HubSpot's JavaScript SDK. Those break on cutover. Either replace them with the new system's form embeds before going live, or route submissions through your own backend and forward to the new system (which gives you more control and doesn't break the page if the CRM is briefly unavailable). Don't forget about forms embedded in landing pages, blog posts, or third-party tools — they're often invisible until they break.
What Breaks in Week Two
The first week after cutover tends to go reasonably well. People are paying attention, the team knows to report problems, and you're watching the logs carefully.
Week two is where the accumulated debt surfaces.
Email reply tracking. Sales reps will notice this first. Emails they sent before the cutover, when the prospect replies, won't be tracked in the new system — and the old tracking will no longer be active. The reply appears in their inbox but not in the CRM. This is structural, not a bug: the old tracking pixel or BCC address is gone, and messages sent before cutover can't retroactively report to a new system. The only clean answer is to acknowledge the gap explicitly: activity from before [cutover date] lives in the archive, activity from after lives in the new system. Plan this communication in advance.
Notification rules. Every sales rep who had custom notification rules in HubSpot — "notify me when a deal moves to Negotiation," "alert me when a high-value contact revisits the pricing page" — has those rules in their head, not in any migration doc. Some of them will notice immediately when they stop receiving alerts. Some will notice three weeks later when they realize they haven't heard about a renewal. Do an explicit notification audit with each affected person before cutover, not after.
Reporting, and the semantic drift hidden inside it. Executives who are used to seeing a specific HubSpot dashboard — pipeline velocity, conversion rates, activity metrics — will ask for the same view on the new system. The deeper problem isn't just rebuilding the report. It's that the same KPI computed in two CRMs is almost never the same number.
Pipeline velocity in HubSpot uses HubSpot's specific definition of stage transition timestamps. Conversion rate depends on what counts as a "qualified" contact, which is tied to HubSpot's lifecycle stage semantics. Forecast amounts use HubSpot's pipeline-stage probabilities, which are configurable and rarely the same as the target system's defaults. "Active opportunities" depends on what each system considers an open deal.
After cutover, the dashboards will show different numbers than they did the day before — not because the business changed, but because the formulas underneath did. The pipeline appears to have shrunk. The conversion rate moved 4 points. The forecast doesn't tie out to the old one. None of this is a bug in the new system; it's a definitional shift that nobody surfaced explicitly.
This is one of the most corrosive post-migration effects, because it destroys executive trust in the new system fast. The pattern I've seen play out more than once: a board meeting two weeks after cutover, the pipeline view is materially smaller than the last reported number, the CEO asks whether sales fell off a cliff, nobody in the room can fully reconstruct why the definitions changed, and the migration spends the next month being defended instead of completed. Recovering executive trust after this kind of discrepancy is harder than the original migration work.
Build the key reports in the target system, validate the numbers against HubSpot's output before cutover, and document every place the definitions differ — explicitly, in writing, with executive sign-off on the new definitions. The discrepancies you find during that validation are much easier to resolve before you've turned off the source, and the documented version is what defends the new dashboards when the CEO asks why pipeline looks smaller.
Webhooks from third-party systems. Anything that sends HubSpot webhooks — a form tool, a data enrichment service, a marketing automation platform — still has your HubSpot endpoints in its configuration. It will keep sending to those endpoints after cutover, and those calls will start failing silently (HubSpot returns 4xx, the sender logs the error, nobody notices). Build a registry of all outbound webhook destinations before cutover and update them as part of the cutover plan.
Talking to the Sales Team
Migration communication is an engineering task, not a soft skill on the side.
Sales teams are attached to their CRM in a way that most engineering teams underestimate. The CRM is their memory, their pipeline, their daily workflow. A migration in their eyes is not a technical upgrade — it's downtime plus retraining tax, and they're not wrong to see it that way. The new system will be slower for them for weeks or months, because the muscle memory they've built is specific to the old tool.
The deeper layer is political, and it's worth naming.
A CRM is not just a workflow tool. It's a compensation system: deals in the pipeline drive commission forecasts. It's a visibility system: who sees what about which accounts is a sales-org power question. It's an attribution battlefield: marketing-versus-sales credit, territory ownership, opportunity assignment rules. The configuration of the existing CRM encodes years of internal negotiation between sales leadership, RevOps, marketing, and finance about who gets credit for what.
A migration reopens every one of those negotiations. The new schema requires explicit decisions about lifecycle stages, attribution rules, territory boundaries, and visibility — decisions that were settled (often informally) in the old system and that now have to be re-litigated to be configured. If the project is run as a technical exercise without a sales leadership sponsor who can adjudicate these conversations, the migration will surface political disagreements without any mechanism to resolve them. That doesn't kill the technical work, but it produces a system that several stakeholders quietly don't trust, which has the same operational effect as a system that doesn't work.
The things that don't work:
"Temporary friction" is not useful framing. It's true but it doesn't help. It sounds like you're minimizing a real impact. Sales reps know friction when they experience it; calling it temporary doesn't make it smaller.
"We got rid of HubSpot bloat" doesn't land. They didn't experience HubSpot as bloat. They experienced it as a tool that worked. The cost argument is not their argument — it's the business argument. Don't make them defend a cost decision that wasn't theirs.
What does work: acknowledge directly what they're giving up, at least temporarily. The mobile app may be worse. The email integration may not be as polished. The reporting they're used to will need to be rebuilt. Say those things explicitly before cutover, not as disclaimers but as honest accounting. Then commit to a specific timeline for closing each gap.
Three concrete things to do before cutover:
Demo the new system with a real rep's real pipeline. Not a demo account with fake data — their actual pipeline in the new system, migrated ahead of the cutover date. Let them click through their workflow and tell you what's missing. This surfaces gaps you didn't know existed and also builds enough familiarity that the cutover day isn't the first time they've touched the new tool.
Parallel access window. Give the sales team read access to HubSpot for 30 days post-cutover. They won't be creating new records there, but they can look up historical data and the activity timeline without having to ask you to run a query. This reduces the cognitive load of the transition considerably.
Named owner for migration questions. One specific person — engineer or ops lead — is the named contact for migration issues during the transition period. Not a Slack channel, not a Jira board. A person. "Questions about the new CRM go to [name]" is useful. "Raise a ticket in the migration project" during a stressful sales quarter is not.
The Engineering Tax That Starts the Day After
A missing frame in most migration discussions: HubSpot's monthly invoice is replaced by an internal engineering invoice that doesn't show up as a line item but is paid every quarter forever.
The cutover is the end of one project and the start of a different one. On the new system you now own:
- Integration drift. Every external system you connected during migration assumes a stable API on your side. As the target CRM evolves, or as those external systems evolve, the integrations need maintenance — usually small fixes, sometimes a serious rewrite. There is no longer a vendor whose job includes keeping the integration surface stable for you.
- Schema evolution. The custom objects, fields, and workflows that took weight off HubSpot are now your responsibility to extend. Every new sales process, every new compliance requirement, every new product line that needs CRM support produces a small engineering task. HubSpot would have handled most of these via configuration.
- Plugin and dependency lifecycle. If you chose an open-source target, security patches, plugin compatibility, and version upgrades are now on someone's plate. If you chose a managed alternative, this is lighter but still non-zero.
- The bus factor. The engineer who built the migration knows where the rough edges are. When that person leaves, that knowledge leaves with them unless it was documented. Most of it wasn't.
- Support load nobody attributed. Sales asks why a workflow didn't fire. Marketing asks why a field isn't syncing. Finance asks why a deal didn't appear in the export. Each one is small. In aggregate, it's a real percentage of someone's week, indefinitely.
I've seen internal CRM deployments two years after cutover that look almost exactly like the HubSpot instance they replaced — with custom fields proliferating, workflow shortcuts coded in by whichever engineer was free, and business logic accumulating with no owner deciding what belongs and what doesn't. The migration didn't solve the operational problem; it transferred it from a vendor relationship into an internal one, with fewer guardrails.
This is not an argument against migrating. It's an argument against pretending the migration is the cost. The migration is the visible cost. The maintenance tax that starts the day after is the cost that determines whether the move was worth it over a three-year horizon.
If you don't have, or can't justify, a fractional engineering allocation dedicated to CRM ownership going forward, the migration math probably doesn't work — independent of what the spreadsheet showed. A fractional CTO is often the right structure here: someone who owns this kind of architectural decision without being a full-time hire.
The Questions to Answer Before You Pull the Trigger
A sanity check for the week before final commit:
Is the data validation complete? Run the full extraction against a backup, count records by type, spot-check 50 records for accuracy, verify that all associations are present.
Do you have a rollback plan and a rollback window? If something critical breaks in week one, what's the procedure to move back to HubSpot temporarily? HubSpot won't delete your data immediately — but is your subscription still active? Is there a clear decision point at which the rollback window closes?
Have you notified every team that interacts with the CRM? Not just sales — support, marketing, finance, any integration owner. Does each person know the cutover date, what changes for them specifically, and who to contact with problems?
Is the email cutover synchronized with the sales team's calendar? Cutting over email tracking during a high-stakes renewal period or a product launch is unnecessarily painful timing. Match the cutover to a lower-intensity period if you have any choice.
Is the post-migration ownership question answered? Who maintains the CRM in month four, in year two, when the engineer who built it has moved on? If the answer is "we'll figure it out," the migration is starting with a structural debt that compounds quickly.
When to Abort or Postpone
Two signals that the migration should stop or wait:
The first is data quality problems discovered during extraction that are larger than expected. If you pull your contacts and find that 40% have no associated company, that 15% of deals have invalid pipeline stages, or that a significant fraction of your data doesn't match what the new schema expects — that's a sign that the source data needs remediation before migration, not after. Migrating dirty data into a new system doesn't clean it; it buries it. The new system will appear to have problems that are actually artifacts of the source data, and untangling those after the fact is significantly harder than fixing the source data before the move.
The second is organizational instability. A sales leadership change, a new VP who hasn't bought into the tool decision, a major product launch happening in the same quarter — any of these make the migration significantly harder and riskier than it needs to be. A CRM migration requires sustained attention from the people who use it. If their attention is elsewhere during the transition, you'll get degraded adoption and a lot of "the new CRM doesn't work" feedback that's really "the new CRM wasn't set up correctly because nobody had time to care."
Timing matters more than it looks in planning. A migration that's three months later but lands when the organization has bandwidth is usually better than a migration that happens on schedule but gets inadequate attention.
One Last Thing
The migrations that go badly are almost never technical failures in the strict sense. The data gets moved, the integrations get reconnected, the system comes up. What goes wrong is the organizational layer — reporting that wasn't rebuilt before someone needed it, notification rules that weren't audited, a sales rep who found out about the change the morning of the cutover, a webhook that silently started failing three weeks after go-live.
A CRM migration is an integration project, an organizational change project, and a political project. The technical work is the smallest of the three.
The deeper pattern is worth being clear about. SaaS CRMs decay outward — per-seat costs scaling badly, schema rigidity, integration ceilings, vendor decisions you can't influence. Custom and self-hosted CRMs decay inward — accumulating custom fields nobody owns, workflow logic coded in by whoever was free that quarter, undocumented dependencies, and a CRM that two years after cutover looks structurally identical to the system it replaced. Both are forms of the same operational gravity. Neither one is escaped by migrating; the migration just changes which version of it you live with.
And the harder truth: a CRM migration rarely solves a process problem. It exposes one. The migration forces the organization to describe its actual process instead of the process it thought it had — and the gap between the two is where most of the work lives. Done well, this formalizes what the team had been improvising. Done poorly, it ports the improvisation into a more expensive substrate.
Treat the technical layer as the table stakes. The actual project is the organizational one, and that's where the next two years of value or regret comes from.
If the integration layer is what's making the move hard — extraction edge cases, cutover sequencing, broken syncs after the fact — that overlaps with API & integrations work I take on. If you're still on the question of whether to move at all, technical consultation is the more honest starting point. And if you want to see what a full automation pipeline on top of a custom data layer looks like in production, the pikkuna.fi project is the closest real-world example I have.
Top comments (0)