HubSpot to Twenty CRM migration
Twenty is the open-source CRM you can self-host and own outright. That is the appeal, and it is real. This is the practitioner guide to actually moving: how HubSpot objects map, what self-hosting commits you to, what does not transfer, and the cases where Twenty is the wrong call today. Twenty is younger than HubSpot, and we will say so wherever it matters.
Migrate to Twenty if you want a CRM you control end to end: open-source code, self-hostable, no per-seat tax that scales against you, and a clean REST and GraphQL API to build on. It fits teams that are technical enough to own infrastructure (or pay someone to), run a sales-led or relationship-driven motion, and are tired of paying HubSpot for hubs nobody opens.
Stay on HubSpot if your revenue runs through Marketing Hub (nurture, landing pages, forms, attribution), Service Hub tickets, native dashboards finance trusts, or the app marketplace. Twenty does not replace any of those today, and it is a younger product: its self-hosted single-tenant build was only marked production-ready in 2026. Pretending otherwise is how migrations fail.
Either way, the CSV export is the easy hour. Choosing self-host versus cloud, redesigning the data model, rebuilding workflows, and deciding what history you can actually carry is the work that decides whether the move pays off.
Why migrate from HubSpot to Twenty?
Teams move to Twenty for three reasons: ownership (open-source code you can self-host, no vendor lock-in), cost (no per-seat pricing that punishes growth, or 9 to 19 USD per user on cloud), and a clean REST and GraphQL API to build on. It suits technical, sales-led teams paying HubSpot for hubs they never open.
The honest version is narrower than the marketing version. Twenty is a strong fit when three things are true at once. You run a sales-led or relationship-driven motion where the CRM is a contact and deal database, not a marketing engine. You have the technical capacity to own infrastructure, or the budget to have someone own it for you. And HubSpot's bill has drifted past the value you actually use, usually because seats multiplied or you are paying for Marketing and Service hubs that two people touch.
Where Twenty genuinely wins: you stop renting your CRM. The code is open-source, so you can self-host it on your own infrastructure and your data never leaves your perimeter. Pricing does not scale punitively against headcount the way per-seat enterprise CRMs do. And the API surface is clean and modern (REST and GraphQL with metadata endpoints), which makes Twenty pleasant to build on rather than something you fight.
Where the marketing oversells: Twenty is a younger product than HubSpot or Salesforce. Its self-hosted single-tenant deployment was only marked production-ready in 2026. It has no marketing automation, no native quoting, no service desk, and a thinner reporting layer. None of that is a dealbreaker for the right team. All of it is a dealbreaker for the wrong one. The rest of this page helps you tell which you are.
If you are weighing Twenty against staying put, our migrations practice covers the Attio route too, which suits teams that want managed cloud rather than self-host.
How HubSpot objects map to Twenty
Twenty's standard objects are People, Companies, Opportunities, Notes and Tasks. Most of the mapping is clean because both systems think in contacts, companies and deals. The traps are in lifecycle stages, calculated properties and activity history, where Twenty is deliberately leaner. Here is the table we work from.
| HubSpot | Twenty | Migration notes |
|---|---|---|
| Contacts | People | Standard object. Map core fields directly; custom contact properties become custom fields you create first. Define identity-based dedup rules (name plus company plus domain, not just email) before import, not after. |
| Companies | Companies | Near 1:1. Twenty links People to Companies as a relation. Decide upfront how you resolve duplicate companies, because a bulk import will happily create three records for one account. |
| Deals | Opportunities | Twenty's deal object is Opportunities, with a stage field and a relation to the company and contacts. Each HubSpot pipeline becomes a stage set on Opportunities; multi-pipeline portals map to a pipeline or stage field you design. |
| Deal pipelines and stages | Stage field and views | No multi-pipeline construct out of the box the way HubSpot ships it. Model pipelines as a select field plus saved views, or as separate stage configurations. Map every stage on paper first. |
| Lifecycle stages | Select field on People or Companies | No native lifecycle concept. Rebuild it as a select field with explicit transition rules. This is the moment to fix lifecycle logic instead of importing its debt. |
| Custom properties | Custom fields | Create the custom fields in Twenty before import. Typed mapping: enumeration to select, multi-checkbox to multi-select, plus number, date, text and boolean. Calculated and score properties do not transfer; they get rebuilt. |
| Notes | Notes | Importable via CSV or API. Original timestamps and author survive only if you map them explicitly and the same users exist in Twenty; otherwise notes land under the importing user with the original author named in the body. |
| Tasks | Tasks | Open tasks transfer as Tasks with due dates and assignees. Map assignees to existing Twenty members or they default to the importer. |
| Calls, meetings (engagements) | Notes or custom object | No first-class call or meeting engagement object. Import the ones that still carry decision weight as timestamped Notes; archive the rest outside Twenty. |
| Logged emails | Not migrated as history | Twenty has no BCC email-logging archive to inherit. Historical logged-email bodies stay in your HubSpot export. Plan email going forward through Twenty's integrations, not by backfilling years of threads. |
| Active and static lists | Saved views | Static lists become a select or tag field plus a filtered view. Active (dynamic) lists become saved views with filters; enrollment-style behavior needs a small workflow to replicate. |
| Workflows | Twenty Workflows and n8n | Nothing migrates automatically. Twenty has native Workflows (record, schedule, manual and webhook triggers, with branching). Each HubSpot workflow is classified rebuild, replace or retire. Most portals retire more than they rebuild. |
| Marketing emails, forms, landing pages | Not migrated | Twenty is not a marketing automation platform. Pair it with a dedicated outbound tool such as Lemlist, or a marketing tool like Mautic or Listmonk for nurture. Budget for this before you decide, not after. |
| Tickets (Service Hub) | Custom object or your support tool | No service desk. Keep tickets in Zendesk or Intercom and sync the relationship, or model a lightweight ticket object as a custom object if volume is small. |
| Quotes, products, line items | Custom objects or external | No native quoting. Model line items as custom objects, or keep quoting in a dedicated tool and reference it. If quotes are load-bearing in your sales flow, price this in. |
Two structural points are worth internalizing before you map a single field. First, Twenty ships a small, clean set of standard objects and expects you to extend it with custom objects and fields rather than inherit a sprawling default schema. That is a feature: you build only what your motion needs. It also means the migration is not a transposition. The portals that get the most out of the move redesign the model on their real motion, then map the old data into it, not the other way around.
Second, Twenty is API-first by design. The REST and GraphQL APIs, with metadata endpoints that expose your custom object schema, are how serious imports of more than a few thousand records happen, and how anything reading from or writing into HubSpot today (billing, enrichment, forms) gets repointed. CSV import handles the first load and related-record links; the API handles volume, idempotency and the integrations around the CRM.
Should you self-host Twenty or use the managed cloud?
Self-host if data residency, full control or avoiding per-seat cost are the point of moving, and you can run infrastructure. Use Twenty's managed cloud (9 to 19 USD per user per month) if you want the open-source data model without operating servers. Most teams that come to us for ownership end up self-hosting; the rest are better on cloud than they expect. This is the choice that makes a Twenty migration different from any other CRM move, so decide it before anything else.
Full control of the stack
The full stack runs on your infrastructure: the Twenty server, a background worker, PostgreSQL and Redis. Your data never leaves your perimeter, there is no per-seat license, and you can fork or extend the code. This is the reason most teams choose Twenty.
You own the operations
You own uptime, backups, upgrades and security patching. Budget a VPS with at least 4 GB of RAM, Docker and Docker Compose, and someone who owns the deployment. Twenty's self-hosted single-tenant build reached production-ready status in 2026; treat anything older as a pilot, not production.
The model without the servers
Twenty's managed cloud gives you the same open-source data model and API without running servers. Pricing is roughly 9 USD per user per month, or 19 USD with SSO and row-level permissions. If "ownership" for you means escaping HubSpot's bill and data model rather than literally hosting it, cloud is the honest answer.
A CRM is not a static site
Self-hosting a CRM is a stateful, business-critical system with a database that holds your revenue history. If nobody on the team wants to own Postgres backups and upgrade windows, choose cloud, or have us run the deployment for you. A self-hosted CRM with no operator is a future outage.
We are comfortable on either side. We will tell you in the diagnostic which one fits, and we say "cloud" more often than people expect, because the goal is a CRM your team trusts, not a server you babysit.
What breaks in a HubSpot to Twenty migration
Every migration tool tells you what transfers. Here is what does not, and what we do about each item. Knowing this before cutover is the difference between a controlled move and an unpleasant quarter.
Deal stage history
HubSpot stores property history: every stage change on every deal, with timestamps. Twenty does not inherit that as history. Export it before you lose portal access, then backfill the dates that matter (entered SQL, entered negotiation, closed) as plain date fields on each Opportunity. Those timestamps are where the truth hides; lose the export and metrics like average days-in-stage become unknowable.
Activity logs
Years of logged calls, meeting outcomes and task history have no one-click import path, and Twenty has no first-class engagement object for them. Archive the full engagement export somewhere queryable, then selectively import the activities that still carry decision weight (last meeting notes on open deals, current-quarter call summaries) as timestamped Notes. Importing everything buries the signal.
Logged emails
HubSpot's BCC-logged email archive does not move. Twenty does not rebuild it. Historical email lives in your HubSpot export; plan email going forward through Twenty's integrations rather than trying to backfill years of threads. Inventory what email history you actually need before committing to a cutover date.
Workflows and sequences
Zero automatic migration. Twenty has native Workflows (record, schedule, manual and webhook triggers, with branching), so much of the logic can be rebuilt, but every HubSpot workflow gets classified: rebuild in Twenty, replace with n8n or Make, or retire. The retire pile is usually the biggest. Sales sequences move to a dedicated tool like Lemlist.
Lead scoring
HubSpot score properties recalculate inside HubSpot, so the values you export are frozen snapshots, not living scores. Scoring gets rebuilt in Twenty from fields plus workflow logic. Treat the rebuild as a chance to audit whether the old score ever predicted anything.
Dashboards and reporting
Dashboards do not move, and Twenty's native reporting is leaner than HubSpot's. For structured reporting you build views, or push data out via the API to a BI layer. If leadership expects HubSpot's drag-and-drop report builder on day one, calibrate now or keep a BI tool in the loop.
The 10-point pre-migration checklist
Run this before the first record moves. Every item exists because skipping it cost someone a week.
- Decide self-host or cloud firstThis choice frames everything else: where the data lands, who operates it, how the API endpoints are configured. Do not start mapping fields until it is settled.
- Export everything, including property historyFull export of contacts, companies, deals and engagements, plus deal-stage and lifecycle-stage property history. Once the portal closes, the timestamps are gone.
- Design the Twenty data model on paperStandard objects plus the custom objects and fields your motion needs. Twenty starts lean by design; create the schema before you import, not during.
- Audit field usage in HubSpotList every property with fill rate and last-written date. Dead schema does not get migrated. Most portals carry dozens of fields nobody has touched in years.
- Clean lifecycle states before the moveMigrate truth, not debt: the contacts marked customer who never bought, the deals marked won that were not, the leads who unsubscribed years ago.
- Set identity rules for deduplicationDecide what makes two records the same: name plus company plus domain or LinkedIn, not just email. Bulk imports create duplicates fast.
- Map every pipeline and stage on paperHubSpot pipeline and stage on the left, Twenty stage configuration on the right, signed off by whoever owns the pipeline.
- Inventory every workflow, then kill the zombiesClassify each automation rebuild, replace or retire, with an owner per decision. Expect retire to win.
- Inventory integrations and API consumersBilling, support, enrichment, forms, Zapier or n8n: anything reading from or writing into HubSpot needs a new target in Twenty and a switch date.
- Write the verification plan before the dry runRecord counts per object, owner coverage, spot checks on a random sample, and a named person who signs off the cutover. If you cannot define "verified", you are not ready to move.
Phases and a realistic timeline
Three to five weeks for most sales-led teams, plus infrastructure setup if you self-host. The data transfer is days; the model redesign, the rebuild and (for self-host) standing up production-grade infrastructure are what take time.
Audit, scope and the host decision · 2 to 4 days
Field-usage audit, workflow inventory, integration map, and the self-host-versus-cloud call. This is exactly what our free diagnostic covers, so you can get it without committing.
Infrastructure, self-host only · 1 to 3 days
Stand up Twenty on your infrastructure: server, worker, PostgreSQL, Redis, backups, upgrade plan. Skip this entirely on managed cloud. We can run it or hand you a documented deployment.
Model design in Twenty · 3 to 5 days
Standard objects, custom objects and fields, stage configurations and views designed on your real motion, not transposed from HubSpot's defaults. This is where the migration earns its keep.
Dry run on a copy · about 1 week
Full import (CSV for the first load, API for volume and related records) into a staging instance. Run the verification plan, fix the mapping, run it again until counts match and spot checks pass.
Cutover · 1 to 2 days
Freeze HubSpot writes, final delta import, integrations repointed to Twenty, dedup pass, sign-off against the verification plan. The team starts Monday in the new system.
Rebuild workflows and reporting · 1 to 2 weeks, overlapping
HubSpot workflows rebuilt as Twenty Workflows or in n8n, scoring re-implemented, reporting views built. Sequenced by revenue impact: the automation that books meetings comes back first.
Hypercare and handover · 1 week
The team works, we watch. Edge cases fixed the day they appear, documentation finished against reality, and you get the keys: model, workflows, runbook, and (if self-hosted) the deployment. Zero lock-in, which on open-source Twenty is literal.
How we run a Twenty migration
We are a small, senior studio. One operator runs your migration end to end, which is why nothing falls between a salesperson and an offshore implementer. On a Twenty move specifically, the work is:
- The host decision, honestly. We tell you whether self-host or managed cloud fits, and we say cloud when it does. If you self-host, we can stand up and operate the deployment (server, worker, Postgres, Redis, backups, upgrades) or hand it to your team documented.
- The data model, designed not transposed. We design Twenty's objects, custom fields and stage configurations on your real motion, then map HubSpot or Salesforce data into it.
- The migration itself, verified. CSV for the first load, the REST and GraphQL APIs for volume, related records and idempotency. Every write counted before and after, because at any real volume a single bad filter rewrites your revenue history.
- The rebuild. Workflows rebuilt as Twenty Workflows or in n8n, scoring re-implemented, reporting views built, integrations repointed.
- The handover. Model, workflows, runbook, and the deployment if self-hosted. On open-source Twenty there is no lock-in by design, and we keep it that way.
We have not published a Twenty case study yet, and we will not invent one. What we can show is how we run migrations and CRM hygiene at real volumes: a HubSpot funnel and lifecycle cleanup on a SaaS scale-up where the entire base was re-tagged and stale deals closed with zero accidental wins, and a PE and M&A fund where we operate 24 production workflows built through the API. The discipline is identical on Twenty; the destination is the part that changes.
Five cases where we would tell you to stay on HubSpot
We are happy to migrate you to Twenty. That only stays credible if we also name the cases where the move is wrong. Here they are.
Your demand gen lives in HubSpot
Nurture sequences, landing pages, forms, attribution: Twenty replaces none of it. You would buy a CRM and re-buy a marketing stack around it (Mautic, Listmonk, a sending tool). If Marketing Hub earns its bill, stay.
Nobody will own the infrastructure
Self-hosting is a stateful, business-critical system. If no one will own Postgres backups and upgrades and you do not want to pay for managed cloud or an operator, Twenty becomes a future outage. Stay until you have the capacity.
Leadership runs on native dashboards
If the team lives in HubSpot's report builder, Twenty's leaner reporting will feel thin on day one. It is buildable through views and a BI layer, but "buildable" is not "in the box".
Tickets or quotes are load-bearing
Twenty has no service desk and no native quoting. If Service Hub tickets run your renewals, or in-CRM quotes and payment links run your sales flow, those are real dependencies to price before you move.
You need a battle-tested platform today
Twenty is younger than HubSpot and Salesforce, with its self-hosted single-tenant build only recently production-ready. If you cannot tolerate a younger product's rough edges and need vendor SLAs and a deep app marketplace now, stay. Revisit Twenty in a year.
HubSpot to Twenty migration FAQ
Is Twenty a good replacement for HubSpot?
Can I migrate HubSpot to Twenty myself with a CSV?
Should I self-host Twenty or use the cloud?
What does not transfer from HubSpot to Twenty?
Is Twenty production-ready and safe to bet a CRM on?
How long does a HubSpot to Twenty migration take?
Not sure Twenty is the right move?
Tell us about your HubSpot and your appetite for self-hosting, in the form, text or a voice memo, whichever is faster. We map where HubSpot hits the ceiling for you, whether Twenty (self-host or cloud) actually pays off in your case, and what it would cost. Free, 30 minutes of our work, an answer within 24h.
Free 30-minute diagnostic