Migrate from Pipedrive to Twenty

How to migrate from Pipedrive to Twenty without losing pipeline history

A sales operations lead usually starts this move because of a renewal, a per-seat cost that keeps climbing, or a data residency requirement that the hosted Pipedrive account cannot meet. The migration is a data and workflow project: deals, people, organizations and activities move into self-hosted Twenty, and Pipedrive stages are rebuilt as Kanban views rather than copied as settings. Sales operations owns the field mapping and the sign-off on pipeline reports, an internal platform team provisions the servers and databases, and an implementation partner, if one is used, typically covers the import scripts, hardening and cutover support. Twenty's self-hosted core runs on PostgreSQL and Redis alongside its server and worker, so the platform team needs to be comfortable operating those two services, backing them up and patching them on a schedule.

Effort and risk depend mostly on data volume, the number of custom Pipedrive fields and how many integrations write into the pipeline. The one-time work is export, mapping, test imports in a staging workspace and user training. The recurring work is hosting, backups, upgrades and support, which the team should price against the infrastructure it already runs. Twenty ships frequent releases, so confirm the upgrade procedure and the version you will pin before you commit to a cutover date. Ask the vendor or your partner to confirm the minimum memory for the Docker Compose setup in the self-hosting guide, since insufficient memory can crash the processes.

Before cutover, run at least two full test imports and compare deal counts, stage totals, owner assignments and open activities against Pipedrive. Confirm that email and calendar sync connects the right mailboxes for each rep, because sync misconfigurations are easy to miss until reps start losing messages. Plan a read-only Pipedrive window so that reps and reporting can check history after the switch, and agree in writing who signs off that the pipeline reconciles. Notes are exported separately from the main records, so give them their own mapping and check line by line on a sample of high-value deals.

Which Pipedrive capabilities map cleanly to Twenty and which need rework

This table compares the main Pipedrive capabilities that a sales team relies on with their closest equivalents in self-hosted Twenty. Each row is labeled clean, needs rework or gap, so you can see where data moves directly and where stages, notes, add-ons or integrations need a deliberate rebuild. Confirm email sync coverage and any Pipedrive add-on behavior in your own environment before you set a cutover date.

Pipedrive capability	Twenty equivalent	Status and what to confirm
Deals and pipeline stages	Custom objects and Kanban views grouped by a stage field	Needs rework: rebuild each pipeline stage as a select field value and recreate the board view
People and organizations	People and companies objects with relations to opportunities	Clean: map fields and relations during import, then check duplicate handling
Activities	Tasks and calendar events linked to records	Needs rework: confirm how activity types, due dates and completion status are imported
Notes and files	Notes and attachments on records	Needs rework: Pipedrive exports notes and files separately, so plan a second import pass
Email and calendar sync	Built-in email and calendar sync per connected account	Confirm: check sync coverage for your mail provider and any Pipedrive mailbox add-on behavior
Workflow automation	Workflow automation with triggers and actions	Needs rework: rebuild each Pipedrive automation as a Twenty workflow and test it
Permissions and visibility	Role-based permissions per object and field	Needs rework: map Pipedrive visibility groups to Twenty roles and confirm row-level scope on your plan
API and integrations	REST and GraphQL APIs with webhooks	Gap for some apps: confirm each third-party Pipedrive integration has a Twenty connector or custom build

What data moves out of Pipedrive and what integrations to rebuild

Pipedrive's admin Export data tab covers the core record types, but linked items, notes, files and connected apps each need their own handling. Inventory every source before cutover, because anything not on an export or in a rebuild list will not reach Twenty.

Core records in the Export data tab

The Export data tab lets global admins and permitted users export leads, deals, organizations, people, products, activities, projects, notes and files as XLSX or CSV. Confirm which of these your account actually uses, and map each to a Twenty object before you export. Deals, people and organizations usually become the first imports, while leads and products may need a decision on whether they belong in Twenty at all. Exported files remain downloadable for 28 days, so schedule the export and store the files in a controlled location.

Linked items need separate exports

A deal export does not carry every relationship. Activities, notes, files and products attached to deals are not automatically rebuilt as links when you import a single object type. Plan a relationship map before the import: which deal IDs own which activities, and which person and organization records each deal references. Run a small test import with a few deals, open the linked people and activities in Twenty, and confirm the associations match Pipedrive before importing the full set.

Notes and files need their own path

Notes and files are exported as separate items, so they cannot be assumed to travel with the deal records. Decide whether historical notes go into Twenty as timeline notes, into an archive folder, or stay in a read-only export for reference. Attachments are the higher risk, since file references can break when the source account closes. Confirm with the account owner which attachments must be preserved and where they will be stored in your own infrastructure.

Inventory Pipedrive-connected apps

Before cutover, list every app, Marketplace add-on, email integration and custom script that reads or writes Pipedrive data. Record the trigger, the data direction, the owner and the credential it uses. Campaigns, calendar tools, lead forms and reporting dashboards are common examples. Each one needs a replacement, a retirement decision or a documented manual process, because Pipedrive connections stop working once the account is retired.

Rebuild webhooks and API calls for Twenty

Scripts that depend on Pipedrive's API must be rewritten against Twenty's REST and GraphQL APIs. Twenty also supports webhooks, so event-driven flows can be re-created there. Map each Pipedrive event to a Twenty trigger, then test authentication, pagination and rate handling in a staging workspace. Keep Pipedrive API tokens active until every flow is verified, and document the new API keys and their owners in your secrets manager.

Rebuild automations as workflows

Stage-change automations, reminders, assignment rules and approval steps in Pipedrive need equivalents in Twenty's workflow automation. Document each rule with its trigger, condition and action, then rebuild it and test it with sample records. Automations that send email or update other systems deserve extra scrutiny, because a mistake there reaches customers. Confirm which automations your team truly relies on, since rebuilding unused rules adds effort with no benefit.

The five-phase sequence from inventory to decommission

The sequence moves Pipedrive data into a self-hosted Twenty workspace in controlled stages, so each phase ends with a documented result that the next phase depends on. Sales reps keep working throughout, and Pipedrive is only switched off once the data and the archive are confirmed.

Inventory pipelines, fields, users and integrations
The sales operations lead, with a Pipedrive admin, lists every pipeline and stage, every custom field on deals, people and organizations, each active user and the role they hold, and every connected integration, including email sync, Campaigns and any Zapier or webhook flows. The output is a field mapping sheet that pairs each Pipedrive object and field with a Twenty object, field or view, and flags anything with no equivalent. The step is done when the sales lead signs off the sheet and each open question has a named owner.
Export source data and confirm completeness
An admin runs the Pipedrive export for leads, deals, organizations, people, activities and notes, following the export guidance for the 28-day file window, and stores the files in a restricted location on your own infrastructure. Notes and files linked to records are exported separately, so the team checks each file against record counts in Pipedrive. The output is an export log with file names, row counts and the date each export was taken.
Run a pilot import into a non-production workspace
The platform team deploys Twenty with the Docker Compose self-hosting guide on a staging host, with the server, worker, PostgreSQL and Redis running and enough memory for the documented minimum. The team imports a sample of deals, people and organizations, then checks how relations, duplicates, stage values and date formats came through. The output is a pilot defect list that records each problem, its cause and the fix applied to the mapping sheet. The step closes when a second pilot import runs without new defects.
Rebuild stages as views and configure access
Sales operations recreates each Pipedrive pipeline as a Kanban view in Twenty, using the stage order from the inventory, and sets up the custom objects and fields defined in the mapping sheet. Role-based permissions are assigned to match the Pipedrive roles, and workflow automations are rebuilt only where the team still needs them. The output is a configuration record listing each view, field, role and workflow, which a sales lead reviews with two or three reps before the parallel run starts.
Run a parallel period with a reconciliation report
Reps work in both systems for a window agreed in advance, and every new deal, contact and activity is entered in Pipedrive while the team checks that it reaches Twenty through the import or sync method chosen. Email and calendar sync are tested with real mailboxes before cutover. At the end of the window, the team compares record counts, stage totals and open activities between the two systems. The output is a reconciliation report that lists every gap and its resolution.
Cut over with a final delta export
The team freezes new entries in Pipedrive, takes a final delta export of changes since the last import, and loads it into Twenty using the same mapping sheet. Reps then work only in Twenty, and the admin confirms that users can log in with the permissions they expect. The output is a signed cutover checklist covering the delta import, the reconciliation sign-off, user access tests and the named person who approves the switch.
Archive Pipedrive data and decommission
Before the Pipedrive subscription is closed, the team stores a complete archive of exports, notes, files and the reconciliation report in a location the compliance owner controls, and checks that the archive can be opened. Retention rules for the archive are confirmed with the compliance owner, since the Pipedrive export files themselves are only available for a limited window. The output is an archive index and a decommission record showing when access was removed and who approved it.

How the data flows during a parallel run

The parallel run works as a one-way pipeline until cutover: Pipedrive remains the system of record, and each export moves into a staging Twenty instance before anything reaches production. Start with the Pipedrive Export data tab, which provides leads, deals, organizations, people, activities and notes as XLSX or CSV, and keep the files for the 28-day window Pipedrive documents, since they expire. Load them into staging in dependency order: organizations first, then people linked to organizations, then deals linked to both, then activities and notes. Each load should be repeatable, so a failed import can be rerun from the same files without creating duplicates. Confirm that the Twenty server, worker, PostgreSQL and Redis containers described in the Twenty self-hosting guide are healthy before each load, because the worker processes the background jobs that imports depend on.

Reconciliation happens after each load and again before cutover. Compare record counts per object type between Pipedrive and staging, and compare the number of deals in each pipeline stage against the stage Kanban view in Twenty. Sample a fixed set of high-value deals and check owner, value, currency, close date and linked contacts by hand. Keep the reconciliation as a dated document with the export file names, so that auditors and sales leadership can see how each count was checked. Plan for mismatches caused by archived records, duplicate people and deals without an organization, and decide in advance which side wins for each case.

Reps keep selling in Pipedrive during the run, so email and calendar sync need a separate test. Connect a pilot group of mailboxes to staging Twenty, send and receive test messages, and confirm that threads attach to the correct person and deal records and that calendar events appear on the right activities. Run the same test with every mailbox type the team uses, and check how shared inboxes and external addresses are matched. Record the results against a checklist and sign off before production users are connected. Changes made in Pipedrive after the last export must be captured in a final delta export at cutover, and the production import should be repeated from that delta with the reconciliation rerun before reps switch over.

How the migration changes by team size and starting point

A small team with one sales pipeline, a handful of users and few integrations has the shortest migration. The inventory is mostly deals, people, organizations, activities and notes, and the export can usually be checked by hand against a sample of records. One Kanban view in Twenty can usually reproduce the stage order, so the rebuild is a short configuration task rather than a design exercise. Parallel running can be brief because there is little to reconcile.

Inventory: list the fields your reps actually use, then drop unused custom fields before import.
Kanban views: rebuild the single pipeline as one board, with stages mapped in the same order.
Notes and activities: export them separately and attach them to the matching records after the main import.
Email sync: test one rep's mailbox end to end before enabling it for everyone.
Parallel run: keep Pipedrive read-only for a short window so late activity can be copied across.

Before cutover, confirm with your implementation partner or from Twenty's documentation how email and calendar sync handle existing threads, and confirm the record counts match between the two systems.

What drives migration cost and duration

This table lists the main drivers of migration cost and effort, why each one moves the total, and how to keep it under control. Read it before requesting a quote, because the same migration can cost very different amounts depending on how much pipeline history, email and custom work is in scope.

Driver	Why it moves cost or effort	How to keep it down
Pipelines and stages	Each Pipedrive pipeline must be rebuilt as a Kanban view in Twenty, and stage names, order and probability logic need manual mapping. More pipelines mean more design and testing.	Consolidate unused pipelines before export, and agree the stage map in writing before build starts.
Volume of deals, people and organizations	Record counts drive import runtime, deduplication work and the number of validation checks. Duplicate people and organizations across records add cleanup time.	Archive closed deals older than the reporting window, and run a deduplication pass in Pipedrive before exporting.
Activities and notes	Pipedrive exports handle activities and notes as separate files, so they must be linked back to deals, people and organizations. This is usually the most manual step.	Limit the import to open deals and the last agreed period, and confirm with stakeholders which notes must be kept.
Attachments and files	Files do not travel in the standard CSV or XLSX exports, so each attachment needs its own retrieval and re-linking. Storage on your own servers also grows with volume.	Inventory attachments first, keep only the files tied to live deals, and confirm the storage capacity you will need.
Custom fields and custom objects	Each Pipedrive custom field must map to a Twenty field type, and any custom objects must be modeled as code. Field mismatches are a common source of rework.	Map fields in a single spreadsheet, retire unused fields, and test the mapping on a sample export.
Email and calendar sync	Twenty's email and calendar sync needs mailbox connections, permissions and testing for each user. Synced history may not match what sales reps expect from Pipedrive.	Pilot with a small group of reps, and document which mailboxes and history windows are in scope.
Workflow automation and integrations	Pipedrive automations, webhooks and connected tools must be rebuilt or replaced in Twenty's workflow and API model. Each integration adds design, build and test effort.	Inventory every integration, rank them by business use, and rebuild only the ones that the sales process depends on.
Hosting and staffing	Self-hosting means PostgreSQL, Redis, the server and the worker run in your environment, so the team or partner must own patching, backups and monitoring. Staffing is the largest recurring component.	Decide early who runs the stack after cutover, and ask the partner to document operations and handover.
Parallel run length	Running Pipedrive and Twenty side by side keeps two sets of data current and doubles some admin work. The longer the overlap, the higher the cost of keeping both in sync.	Set a fixed cutover date, freeze data entry for a short window, and agree exit criteria before the parallel run starts.
Managed Twenty plans, if chosen	Twenty's pricing page lists per-user Pro and Organization plans, which recur monthly and grow with seats. Enterprise pricing is annual and quoted from scope.	Compare seat counts against your self-hosted hosting and staffing costs, and ask for the plan terms in writing.

What usually goes wrong in a Pipedrive to Twenty move

Most failed CRM moves are not caused by the target software. They come from stages that do not map cleanly, history that stays behind in the export, and infrastructure that was sized for a demo rather than a live sales team. Each card below names one risk, why it matters for this migration, and the check that prevents it before cutover.

Stage mismatch in the pipeline

Pipedrive stages are per pipeline, and each one carries a probability and an order that reps rely on for forecasting. In Twenty, stages become options on a select field that you show as Kanban columns, so a stage name that exists in two pipelines can collapse into one column. Export every pipeline with its stage list, write a one-to-one mapping table, and confirm with a sales lead that no open deal lands in a column that means something different.

Lost deal history

A deal export gives you the current state of each record, not the stage-change timeline that Pipedrive keeps in its activity and change log. Teams that expect old win and loss dates, or time-in-stage reports, to survive the move are often disappointed. Decide which historical fields you must keep as plain values on the deal, such as close date and won or lost reason, and tell reporting owners what will no longer be available.

Notes imported as plain text

Notes in Pipedrive are attached to a deal, person or organization, and they carry an author and a timestamp. A flat text import loses those links unless the import file keeps the record identifier and the creation date in separate columns. Test a sample of ten deals with long notes, and confirm that each note appears on the correct record with its original date before you trust the full run.

Email sync gaps found after cutover

Email and calendar sync depends on each user connecting their own mailbox, and history before the connection date is generally not backfilled. Shared inboxes, aliases and mail sent from mobile apps can also fall outside the sync scope. Before cutover, have a pilot group connect accounts, send and receive test messages, and check which threads appear on the right person. Document the gaps so reps know which conversations to file manually.

Export file expiry

Pipedrive makes exported files available for 28 days, so an export that was scheduled early and not downloaded in time must be run again. Attachments and linked files also need their own export path. Put the export on a dated checklist, download each file into your own storage the same day, and record the file names and row counts so you can compare them with the imported data later.

Undersized memory on the host

Twenty's Docker Compose guide runs a server, a worker, PostgreSQL and Redis on one host, and it asks for at least 2 GB of RAM because insufficient memory can crash processes. A host that meets the minimum on paper can still fail during a bulk import when the worker queues fill up. Size the host above the minimum for the import window, watch memory during a trial import, and keep a plan to resize before the real run.

No tested PostgreSQL backup

Twenty stores CRM records in PostgreSQL, and Redis holds queue data and cache. A backup job that runs but has never been restored gives no protection. Before the import, take a full PostgreSQL dump, restore it to a separate host, and confirm that record counts match. Schedule backups after go-live as well, and include the file storage used for attachments in the same restore test.

Questions teams ask before moving from Pipedrive to Twenty

How long does a move from Pipedrive to Twenty take?

The duration depends on how much history you carry over, how clean your Pipedrive data is and how many people must sign off on the new pipeline. No supplied source gives a standard timeline, so treat any number as something to confirm in a written scope. The main drivers are the number of deals, people and organizations to map, how many custom fields you rebuild as Twenty objects and fields, whether notes are imported as a separate step, and how long your email and calendar sync test takes. A small team with a short pipeline history can cut over quickly, while a team with years of activities, custom fields and several pipelines needs more mapping and testing. Ask any implementation partner for a timeline tied to these drivers.

Can our sales team migrate from Pipedrive to Twenty without outside help?

Yes, a capable internal team can run the move, provided someone owns the data mapping, the Docker Compose deployment and the cutover checks. The work includes exporting deals, people, organizations and activities from Pipedrive, rebuilding stages as Kanban views in Twenty, importing records, and testing email and calendar sync with real mailboxes. Teams without a PostgreSQL, Redis and container operations background often bring in outside help for hosting, backups and upgrades. DeployOpen plans, implements, integrates, backs up and documents self-hosted platforms in your own infrastructure under a fixed-scope written agreement, so the choice is between staffing this internally and scoping it externally.

What does the migration need from sales ops and IT?

Sales operations owns the business model: which pipelines, stages, required fields and reports must survive the move, and who signs off on each Kanban view. IT owns the environment: the server or cloud account, the PostgreSQL and Redis services, TLS, identity, backups and access to the mail and calendar providers used for sync. Both teams should agree on a cutover date, a freeze period for new deals in Pipedrive, and a rollback plan. Ask for the list of data owners, the change window and the permissions each person needs in Pipedrive and in the new environment before work starts.

Do notes and files transfer from Pipedrive to Twenty?

Plan on importing notes and files as a separate step rather than assuming they arrive with deals. Pipedrive's Export data tab covers leads, deals, organizations, people, products, activities, projects, notes and files as XLSX or CSV, and exported files remain available for 28 days, so schedule and verify the export before that window matters. Notes and files linked to records need their own mapping to Twenty records, and attachments may require a separate transfer method. Test a sample of records with notes and attachments in a staging workspace before the full import, and confirm with the vendor and your own tests which item types map cleanly.

How do we check email and calendar sync before cutover?

Test email and calendar sync with a defined set of real users and mailboxes in a staging workspace before any production switch. Twenty supports email and calendar sync, but you should confirm for your mail provider how it authenticates, which folders and calendars are included, how far back history loads and how duplicates are handled. Check that messages and events attach to the correct people, organizations and deals, that sync continues after a token refresh and that users can send from Twenty. Document each test case and the expected result, then repeat the tests after the final import so that cutover does not depend on a single check.

What does self-hosting Twenty cost in infrastructure?

The core software is free to self-host, according to Twenty's pricing page, so your ongoing cost is the infrastructure and the people who run it. The Docker Compose guide runs a server, a worker, PostgreSQL and Redis, and asks for at least 2 GB of RAM because insufficient memory can crash processes, so start from that minimum and size for your user count and storage. Recurring costs include compute, storage, backups, monitoring, TLS, and staff time for upgrades. One-time costs include the migration, mapping and testing. Ask any quote to itemize hosting, setup, migration, backup and upgrade support separately so you can compare against your current Pipedrive plan and add-on spend.

How do the AGPL-3.0 license and Enterprise header affect our use of Twenty?

Twenty's core is mostly licensed under AGPL-3.0 with an additional application exception, and its SDK and UI packages are MIT, according to the LICENSE file in the repository. Files marked with an Enterprise license header fall under a commercial license, so do not assume every file in the repository is open source. If you modify the code and offer it to users over a network, AGPL-3.0 obligations may apply, so have counsel review your intended use. Confirm the license headers in the exact release you deploy and keep a record of any custom code, since that affects how you maintain and share changes.

What happens to our Pipedrive data after cutover?

Keep Pipedrive in read-only mode for a defined retention period after cutover, and keep a verified export archive that your organization controls. Confirm with Pipedrive what happens to your account when you cancel, since exported files are only available for 28 days, so store the export files on your own storage before that window closes. Decide who approves deletion, record where each archive is kept, and set an end date for access. Check that your retention obligations for personal data in the old system are met in the new one, and that deletion requests are handled in both places.

When a team should cut over and when to wait

Cut over only when the Twenty workspace matches Pipedrive on the things reps and managers will check first. Record counts must reconcile for deals, people, organizations and activities, with each total compared between the Pipedrive export and the Twenty import, and every open deal sitting in the stage it belongs to. Reps should have worked through the Kanban views on a copy of their own pipeline and confirmed that they can move a deal, log an activity and find a contact without help. Email and calendar sync must be verified for each user individually, not assumed from one admin test account, because connection status is per mailbox. Integrations that write to or read from Pipedrive, such as forms, Zapier-style automations or reporting, need a tested replacement or a written decision to drop them.

Delay the cutover if the stage mapping is still disputed, because a deal moved into the wrong stage will distort forecasts from the first day. Also delay if you cannot show a current backup of the Pipedrive data and a restorable copy of the Twenty database, since the Docker Compose deployment depends on PostgreSQL and Redis and an untested restore is not a rollback path. Confirm the server meets the memory guidance in Twenty's self-hosting documentation (at least 2 GB of RAM) under real load before users depend on it. Plan a rollback path in writing: who can reopen Pipedrive, which period of new entries would need re-keying, and who decides.

Archive Pipedrive exports before the window closes. Pipedrive keeps exported files for 28 days, so the export date becomes a deadline in the project plan rather than a detail. Save the XLSX or CSV files for every object type, plus notes and files exported separately, to storage your organization controls, and record which export matches which cutover checkpoint. Keep the Pipedrive subscription active until the reconciliation and rollback sign-off are complete, and confirm with Pipedrive what happens to account data at cancellation, since that date may not match your project timeline.

How DeployOpen scopes and runs a Pipedrive to Twenty migration

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, including Twenty. For a Pipedrive to Twenty move, we start from a written scope that covers which Pipedrive records move, how stages become Kanban views, and how email sync is verified before cutover.

How we scope

Inventory which Pipedrive deals, people, organizations, activities and notes must move, using your admin export data.
Agree in writing how each Pipedrive stage maps to a Twenty Kanban view and which fields become custom fields.
Confirm hosting target, PostgreSQL and Redis sizing, and the email and calendar accounts that must sync into Twenty.

How we build

Stand up Twenty with Docker Compose on your infrastructure, running the server, worker, PostgreSQL and Redis components.
Load migrated records in a test workspace, then reconcile counts and relationships between deals, people and organizations.
Configure workflow automation, role-based permissions and email and calendar sync, then test each with pilot sales users.

How we hand over

Document the cutover runbook, rollback steps and the mapping between Pipedrive and Twenty objects.
Provide admin guides for custom objects, views, permissions and the separate notes import, as agreed in the scope.
Walk your sales operations and IT staff through daily administration before the written handover is signed.

How we support

Offer ongoing support, upgrades and backups for your Twenty instance as a retainer after handover.
Plan each upgrade against the release notes and test it in a staging copy before production.
Confirm with us which support hours and response expectations apply, as they are set in the retainer scope.