Migrate from Salesforce to Twenty

Migrating from Salesforce to Twenty for a sales team that uses accounts, contacts and opportunities

A sales-focused move from Salesforce to Twenty is realistic when the team mainly works with accounts, contacts, opportunities and tasks, and the work is moderate rather than large. The usual trigger is a renewal, a per-seat cost that has grown with headcount, or a requirement to keep customer data on infrastructure the company controls. In most cases an internal Salesforce administrator leads the project with an implementation partner handling the data model, the import scripts and the cutover. The data itself is rarely the hard part. The main risk is reporting and automation depth: confirm early which Salesforce reports, dashboards, flows and scheduled jobs your managers depend on, and whether Twenty's workflows, views and API cover them without custom development.

Start by listing the objects in use and mapping each one. Standard Account, Contact, Opportunity and Task records map to Twenty's companies, people, opportunities and tasks, and custom objects can be defined as code in Twenty's data model, so each custom field needs an explicit target before any data moves. Export with the Data Export Service for a full snapshot and use Data Loader for repeatable extracts. Then import the CSV files in dependency order: companies first, then people linked to companies, then opportunities. Keep the Salesforce IDs in a custom field so relationships can be checked and re-run. Record the number of rows per object at export and at import, and sample deals against the source before sign-off.

Rebuild pipelines and views before users see the system, because sales managers will judge the migration by their board, their filters and their forecast view. Recreate each stage and probability, then check the permissions model: Twenty's role-based permissions cover the basic access rules, but confirm with the vendor which features your edition provides, such as row-level permissions, SSO and audit logs, since the pricing page places some of these in paid plans. Run a parallel period in which the team enters activity in one system and reconciles weekly. Before cutover, ask the implementation partner for a written list of reports, automations and integrations that are rebuilt, changed or dropped.

What maps cleanly from Salesforce Sales Cloud to Twenty, and what needs rework

This table compares the main Salesforce Sales Cloud features with their closest Twenty equivalents and marks each as clean, needs rework or gap. Use it to scope a pilot: clean rows can usually move with data import alone, rework rows need design time, and gap rows need a decision before cutover. Confirm every gap and paid-plan dependency against your own org and a Twenty trial.

Feature area	Salesforce Sales Cloud	Twenty	Status
Standard objects (accounts, contacts, opportunities, tasks)	Account, Contact, Opportunity and Task objects with standard relationships	Companies, People, Opportunities and Tasks objects with relations between records	Clean
Custom objects and fields	Custom objects and fields created in Setup, with validation rules and record types	Custom objects and fields defined as code, with unlimited counts on all plans	Needs rework
Pipelines and stages	Opportunity stages and sales processes per record type	Opportunity stage field and views grouped by stage; confirm how your forecast categories map	Needs rework
Views and list filters	List views and filters saved per user or shared	Saved views with filters and sorts; rebuild shared views for each team	Needs rework
Email and calendar sync	Einstein Activity Capture and Gmail or Outlook connectors	Email and calendar sync is supported; confirm mailbox coverage and sync scope in a pilot	Needs rework
Workflow automation	Flow, Process Builder retirement path, Apex triggers and approvals	Workflow automation builder; complex Apex and multi-step approvals need redesign	Gap
Reports and dashboards	Standard and custom report types with dashboards and forecasting	No direct one-to-one equivalent; confirm reporting depth and export needs in a pilot	Gap
Permissions and SSO	Profiles, permission sets and sharing rules with SSO options	Role-based permissions on all plans; SAML or OIDC SSO, row-level permissions and audit logs require paid plans per Twenty pricing	Needs rework

Which Salesforce data moves, through which export path

Salesforce gives you two documented export routes, and each one covers a different slice of the org. Whichever route you pick, the data still has to be mapped into Twenty's objects and the integrations rebuilt against Twenty's APIs, so the checks below belong in the migration plan from the start.

Data Export Service cadence and format

The Data Export Service produces CSV files in a compressed archive. Salesforce documents a weekly cadence in Enterprise, Performance and Unlimited editions and a 29-day cadence in Professional and Developer editions, so the export you need may not be available on the day you plan the cutover. Confirm your edition and the most recent export date in your own org before scheduling the freeze. Plan for a fresh export close to cutover, since data changed after the last archive will be missing.

Files and attachments coverage

Confirm with your Salesforce administrator whether the export includes files and attachments, since the scope depends on the export options chosen in the org. Records such as accounts, contacts, opportunities and tasks are usually the core of a sales migration, but notes, files and email content may sit outside the standard archive. Ask for a list of what each export contains and where any excluded attachments will be stored during the migration.

Data Loader for repeatable extracts

Data Loader is a separately installed client that runs through a graphical interface or from the command line, which makes it suitable for scripted, repeatable extracts. Teams often use it for trial loads and delta runs before cutover, so each run produces the same field set. Your team or your implementation partner needs a installed copy, a user with API access and a documented run schedule. Keep the configuration files under version control so each trial can be compared.

Field mapping into Twenty objects

Salesforce CSVs use Salesforce object and field API names, which rarely match Twenty's data model one to one. Build a mapping table that links each Salesforce standard object, custom object and picklist value to a Twenty object, field or option, and decide how lookups such as account to contact will be preserved. Twenty supports custom objects and fields defined as code, so custom Salesforce fields can often be recreated directly. Test the mapping on a sample extract before loading the full dataset.

Integration rebuild on Twenty's APIs

Salesforce integrations are not exported with the data, so every connected system must be inventoried and rebuilt. Twenty exposes GraphQL and REST APIs and webhooks, and the connection logic for each external system has to be written or reconfigured against them. Confirm in each Salesforce org which connected apps, outbound messages, scheduled jobs and middleware calls exist, because teams often find integrations that nobody currently documents.

The migration sequence from inventory to decommission

This sequence moves Salesforce accounts, contacts, opportunities and tasks into a self-hosted Twenty workspace in stages, with a reconciliation check at each gate. Each stage ends with a written artifact, so cutover and decommissioning rest on evidence rather than memory.

Inventory objects, fields, users and integrations
The sales operations lead or Salesforce admin lists every standard and custom object in use, each field with its type and whether reports depend on it, active users with their roles and sharing rules, and every integration, flow and Apex trigger that reads or writes CRM data. Anything that cannot be mapped is flagged here as a decision for the business owner. The output is a signed field mapping sheet that shows each Salesforce field, its Twenty object and field, the transformation needed, and the owner who approved it. Work is done when no field remains unassigned and every integration has a keep, rebuild or retire decision.
Run a pilot import into a non-production workspace
Deploy Twenty with its Docker Compose self-hosting setup on a non-production host, which runs a server, a worker, PostgreSQL and Redis and needs at least 2 GB of RAM. Confirm that memory headroom is sufficient before importing, since the documentation notes that insufficient memory can crash processes. Export a representative sample from Salesforce using the Data Export Service or Data Loader, load it through Twenty's import path, and check that relationships such as account to contact and contact to opportunity resolve correctly. The output is a pilot defect log listing every field that truncated, failed a type check or lost a link, along with the mapping changes made to fix each one.
Rebuild pipelines, views and permissions
Recreate the sales pipeline stages, opportunity views, dashboards and role-based permissions in the pilot workspace, and confirm that each sales role sees only the records its Salesforce profile allowed. Rebuild workflow automations that replace Salesforce flows, such as task creation on stage change, and test each one against sample records. Ask a sales manager to walk through their weekly pipeline review in the new workspace. The output is a signed-off pipeline rebuild document with screenshots of each view, a permission matrix checked against the Salesforce sharing model, and a list of any automation that was not rebuilt and why.
Run a parallel period with reconciled counts
Load a full extract into the production Twenty workspace while Salesforce remains the system of record, and let a small pilot group work in both systems. On a fixed schedule, compare record counts per object, totals for open opportunity amounts, and a sample of records field by field. Investigate every difference until its cause is known, whether it is a mapping error, a duplicate or a record edited only in one system. The output is a reconciliation report per object showing source count, target count, the differences and their resolution, reviewed and accepted by the business owner before cutover is scheduled.
Cut over with a final delta export
Freeze edits in Salesforce for a short, announced window, take a final delta export of records created or changed since the last full load, and import it into Twenty. Repeat the reconciliation for the delta and confirm that integrations pointing at Twenty's GraphQL and REST APIs and webhooks are active and tested. Switch sales users to Twenty and keep Salesforce in read-only mode. The output is a cutover record showing the export timestamps, delta counts, reconciliation results, the integration test log and the go-live approval from the business owner.
Retain Salesforce data and decommission
Keep a full archive of the final Salesforce export in encrypted storage that the organization controls, and set the retention period with legal and compliance owners before anything is deleted. Confirm that Salesforce licenses are no longer assigned and that scheduled exports and integrations have been disabled. Verify that the Twenty backup and restore process covers PostgreSQL data and attachments, and test a restore before relying on it. The output is a decommission checklist signed by the business and security owners, a documented retention schedule for the archive, and a record of the license removal date.

How Salesforce objects and custom fields become Twenty objects

Start by mapping every Salesforce object to a Twenty object before you import anything. Standard objects such as Account, Contact, Opportunity and Task usually land on Twenty's default objects for companies, people, opportunities and activities, so the main work is deciding where each field goes. Custom objects and custom fields are different: Twenty supports custom objects and fields defined as code, which means the structure is set in the codebase rather than only through a click-through admin screen. Check the Twenty repository for how custom objects and fields are defined in the version you deploy, and confirm the current data model on a staging instance before you write any mapping file. Record the Salesforce API name, field type and any required flag for each field in a spreadsheet, since that becomes your import contract.

Relationships and picklists need explicit decisions. Salesforce lookups and master-detail relationships must be rebuilt as relations between Twenty objects, and the import order matters: companies and people should exist before opportunities that reference them, so you can resolve IDs from your export. Salesforce picklist values should be copied exactly, including inactive values that still appear on historical records, because an unmapped value will fail or silently change reporting. For record ownership, build a table that maps each Salesforce user ID to a Twenty workspace member, and decide who owns records whose original owner has left the company. Role-based permissions in Twenty should be designed after this mapping, not before, so access follows the real owner.

Stage history and activity timelines usually cannot be imported with the same fidelity as current records, so decide early what is imported and what is archived. Opportunity stage history in Salesforce is a separate history object, and Twenty's timeline will not reproduce it automatically unless you load it as records or notes. A common pattern is to import current stage, amount and close date as live fields, then keep the full history, closed activities and attachments in a read-only archive that your team can search. Confirm with your compliance owner how long historical activity must remain accessible, and test the archive lookup with a sample account before cutover.

What drives the cost and duration of the move

This table lists the factors that most change the effort of a Salesforce to Twenty move, why each one adds work, and how to keep it manageable. Use it to scope a fixed-price quote, separating one-time project work from recurring hosting and support.

Driver	Why it changes effort	How to keep it down
Custom objects and fields	Each custom object needs a Twenty equivalent defined as code, and each field needs a mapping, type check and migration rule. Lookup and master-detail relationships take the most mapping time.	Audit the org's schema before scoping. Retire unused fields, consolidate near-duplicates and map only the objects sales actually uses.
Record and attachment volume	Large account, contact and opportunity counts lengthen import runs and validation. Attachments add storage, transfer time and a separate reconciliation step.	Migrate active records and recent history, archive the rest as read-only exports, and confirm which attachments must move into Twenty.
Active integrations	Each connected tool (marketing, support, ERP, data warehouse) needs its sync rebuilt against Twenty's GraphQL or REST APIs and retested end to end.	List every integration with its owner and data flow. Decide which ones are retired, which are rebuilt and which are replaced by Twenty's native email and calendar sync.
Apex and Flow automation	Triggers, Flows and approval processes have no direct copy in Twenty. Each one must be rewritten as a Twenty workflow or custom code, then tested against edge cases.	Inventory automations by business outcome. Remove dead logic first, then rebuild the remaining rules as Twenty workflows where the built-in automation covers them.
Reporting dependencies	Dashboards, scheduled reports and forecast views that finance or leadership rely on must be rebuilt and reconciled against Salesforce figures before cutover.	Rank reports by who uses them. Rebuild the few that drive decisions, and agree with stakeholders which legacy reports can be dropped.
SSO and permission design	Profiles, permission sets, sharing rules and role hierarchies must map to Twenty's role-based permissions. SAML or OIDC SSO and row-level permissions sit on paid Twenty plans, so the plan choice affects scope.	Document current access rules before migration. Confirm with Twenty's pricing page which plan provides SSO, row-level permissions and audit logs for your team.
Internal admin availability	A named admin must validate mappings, approve test data, sign off UAT and own the cutover. Delays in that availability extend the project more than technical work does.	Name the admin and a business approver at kickoff. Book review windows in the project plan so testing does not wait on ad hoc requests.
One-time project costs	Scoping, mapping, migration test runs, cutover, user testing and training are paid once. Each is priced from the written scope, not from the number of users alone.	Ask for each phase as a separate line with deliverables and acceptance criteria. Fixed scope makes changes visible.
Recurring costs	Hosting of the server, worker, PostgreSQL and Redis (Twenty's Docker Compose guide asks for at least 2 GB of RAM), backups, upgrades and any retainer support continue after go-live.	Ask for the hosting footprint, backup schedule, restore test frequency and upgrade approach. Compare these against the current Salesforce subscription and add-on costs.

What usually goes wrong and how to prevent it

Most failed Salesforce exits to Twenty do not fail on the data itself. They fail on reporting that was left until the end, automation that was assumed to be simple, and an undersized host or permission model that was fixed after users were already working in the system. Each card below names one risk and a check to run before cutover.

Reporting rebuilt too late

Sales leaders usually judge a migration by their forecast and pipeline dashboards, so these are the first things they will ask for. Teams that leave dashboards until after data import often find that the views they rely on were built from Salesforce report types that do not map one to one. Before import, list every report and dashboard in use, record the filters and groupings, and rebuild the top five or so as Twenty views with the same definitions. Get sign-off on the numbers from a finance or sales operations owner while Salesforce is still live, so both systems can be compared side by side.

Automation depth underestimated

Salesforce flows, approval steps and assignment rules often grew over years, and many users do not know they exist until a lead stops routing. Twenty supports workflow automation, but a workflow that replicates a complex Salesforce flow may need several smaller steps and custom logic. Inventory every active automation, mark which ones run on record creation, stage changes or time triggers, and decide for each whether it is rebuilt, simplified or retired. Test the rebuilt workflows with real sample records before any users depend on them.

Duplicate contacts and accounts after import

A CSV export from Salesforce rarely matches the way records are grouped in Twenty, and running the import twice or merging exports from several sources creates duplicate people and companies. Duplicates then split activity history and distort pipeline totals. Decide on one matching key before import, such as email address for people and domain for companies, and clean the export for trailing spaces and inconsistent names. Import a small batch first, count the records in both systems, and resolve duplicates before loading the full dataset.

Activity history left behind

Opportunities and accounts move across, but the calls, meetings, tasks and emails attached to them are often exported separately or not at all. Sales reps then open a deal in Twenty and see no history, which weakens trust in the new system quickly. Confirm which activity types your team uses and export them with their parent record identifiers. Check whether Twenty's email and calendar sync will backfill older messages for your mailboxes, and document what has to be archived in Salesforce instead.

Permissions set too loosely or too late

Teams often import everything into a shared workspace and plan to add access rules later, which leaves sensitive pipeline and contact data visible to people who should not see it. Twenty's role-based permissions are part of the core, but row-level permissions, SAML or OIDC SSO and audit logs are listed on paid plans, so confirm which of these your organization needs before choosing a plan. Define roles from your Salesforce profiles and sharing rules first, then test them with a non-admin account before go-live.

Host undersized for memory

Twenty's Docker Compose guide runs a server, a worker, PostgreSQL and Redis, and it asks for at least 2 GB of RAM because insufficient memory can crash processes. A host sized for a pilot can fail under a full import, a busy worker queue or a large batch of workflow runs, and the failures may look like random errors. Size the host for the import peak as well as steady use, watch memory during the test load, and keep backups of the PostgreSQL database before each large import.

How the migration changes by team size and starting point

A small team that uses Salesforce mainly for accounts, contacts, opportunities and tasks usually has the lightest migration. The work is mostly a data move and a rebuild of a few pipeline views, with little code to port. Scope is set by record volume, user count and how many pipeline stages you run, not by the platform.

Data mapping: Map Account, Contact, Opportunity and Task to Twenty's people, companies, opportunities and activities, and confirm which standard fields you actually populate.
Export path: Use the Data Export Service for a full set of CSV files, or Data Loader for repeatable pulls if you need a re-run before cutover.
Pipeline rebuild: Recreate stages and saved views by hand, which is quick when the stage list is short.
Users and access: Confirm how many people need access and whether row-level permissions matter, since those sit in paid Twenty plans.
Reporting: Test your standard reports before you commit, because reporting depth is a common gap for small teams that rely on dashboards.

Confirm first whether your sales managers depend on forecast reports and dashboards. If they do, compare the reporting depth of SuiteCRM and EspoCRM against Twenty before you commit.

The features to check before you commit to Twenty

Before you commit, test the features your sales managers rely on most in Salesforce. Twenty covers the core pipeline model well: custom objects and fields, views, workflow automation, email and calendar sync, and role-based permissions. Reporting depth, forecasting and mobile use are the areas to verify in a working copy with your own data. Build the three reports your managers actually open each week, including any that group opportunities by stage, owner and close quarter, and confirm whether Twenty produces them without a custom query. Ask the same question about forecast roll-ups and quota views, which many sales teams treat as non-negotiable. For mobile, install the app on the devices your field reps use and check whether logging calls, updating deal stages and attaching files work the way your team expects.

Workflow automation needs the same scrutiny. List every Salesforce flow, approval and validation rule your team depends on, then check each one against Twenty's workflow builder in a test workspace. Simple triggers such as assigning a record on creation or notifying an owner are usually straightforward to rebuild. Multi-step approvals, cross-object updates and rules that depend on Apex logic are where gaps appear, and those may need the API or custom work. Record which plan includes each feature, because the pricing page separates Pro, Organization and Enterprise tiers, and some controls such as row-level permissions and SSO sit in the higher tiers. Ask legal counsel to review the licensing before rollout. Twenty is mostly AGPL-3.0 with an additional application exception, files with an Enterprise license header are under a commercial license, and the SDK and UI packages are MIT. Those terms affect how you may modify and distribute the code, so counsel should read the LICENSE file in the repository against your planned use.

Plan for frequent change as well. Twenty ships often: v2.48.0 was released on October 16, 2026, one day after v2.47.0, according to the GitHub releases page. Pin the exact version in your Docker Compose deployment, read the release notes for each update, and run upgrades first in a staging environment that mirrors your production data. Keep a tested rollback path covering PostgreSQL and Redis, and schedule upgrades outside quarter-end so a regression does not disrupt forecasting. Confirm with your implementation partner who owns this testing cycle and how it is recorded.

Questions buyers ask before moving from Salesforce to Twenty

How long does a Salesforce to Twenty move take?

The duration depends on scope, not on a fixed figure. The main drivers are the number of objects and custom fields in use, how much history must move, how many pipelines and views need rebuilding, and how many integrations or automations must be replaced. A team moving accounts, contacts, opportunities and tasks with a few pipelines will have a very different timeline from one with heavy custom objects and external integrations. Ask for a timeline that is tied to a written list of objects, fields, reports and integrations, and confirm how many parallel test cycles the plan includes before cutover.

Can our own team migrate from Salesforce to Twenty without outside help?

A capable admin can often import CSV extracts and rebuild basic pipelines and views, provided someone owns the data model and the cutover plan. Teams usually need more help when they must map custom Salesforce objects, reconcile duplicate records, rebuild automation, or stand up Twenty's PostgreSQL, Redis and worker stack securely. The Docker Compose self-hosting guide asks for at least 2 GB of RAM, and insufficient memory can crash processes, so the hosting side needs an owner from day one. Be honest about internal capacity during the sales cycle, because cutover tends to collide with quarter-end.

What does the migration need from Salesforce admins and sales leads?

Admins need to produce a clean data extract, document every custom field and its purpose, and confirm which records and history are still in use. Sales leads need to define the pipeline stages, required fields, ownership rules and the reports their forecasts depend on, and they must test those views with real deals before go-live. Plan time for both groups to review sample records in Twenty, because mismatched stage names or lost ownership fields are the most common reasons users reject a new system.

Can Twenty replace the automation we run in Salesforce?

Twenty supports workflow automation, email and calendar sync, webhooks and REST and GraphQL APIs, so many simple automations can be rebuilt directly. Complex Salesforce automation built on Apex, Flow or managed AppExchange packages will not map one to one, and each one needs a documented equivalent or a custom replacement. Inventory every active automation, classify it as simple, complex or no longer needed, and check reporting depth against your forecast and dashboard requirements before committing, since reporting is an area where teams often need to verify fit.

What do the Data Export Service and Data Loader leave out?

The Data Export Service produces a set of CSV files in a compressed archive, on a weekly cadence in Enterprise, Performance and Unlimited editions and every 29 days in Professional and Developer editions. Data Loader is a separately installed client that runs through a graphical interface or command line and suits scripted, repeatable exports. Neither path gives you a finished migration: relationships between objects must be rebuilt through IDs, attachments and file content need separate handling, and custom metadata such as page layouts, validation rules and automation logic is not carried into Twenty. Confirm which files and attachments your edition exports before the first extract.

What does licensing and self-hosting cost include for Twenty?

The open source core is free to self-host, and Twenty's pricing page says all plans include unlimited custom objects, fields, views and records plus REST and GraphQL APIs and webhooks. Paid tiers add cost per user: Pro is listed at 9 US dollars per user per month, Organization at 19 dollars with row-level permissions, SAML or OIDC SSO and audit logs, and Enterprise from 50,000 dollars a year with single-tenant isolation, SCIM and an SLA. Your real cost also includes cloud or server hosting, backups, upgrades, monitoring, and staff time. Check the license file, since most of the codebase is AGPL-3.0 with an additional application exception and some files carry an Enterprise commercial license.

How does DeployOpen scope a Salesforce to Twenty migration?

DeployOpen scopes the work in writing before it starts. The scope covers the objects and fields to migrate, the pipelines, views and reports to rebuild, the automations to replace, the hosting and backup design in your own cloud account or data center, the cutover plan and the testing and handover deliverables. Most engagements are fixed-scope, and ongoing support or upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for a list of assumptions and exclusions, including which integrations and reports are out of scope.

How DeployOpen scopes, runs and supports a Twenty migration

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so a move from Salesforce to Twenty is agreed in writing before any data is touched. The work covers the Twenty deployment, the object mapping, the data import, the rebuilt pipelines and the handover to your admins.

How we scope

We confirm which Salesforce objects, custom fields, reports and integrations are in use before agreeing a scope.
The written scope lists target Twenty objects, import files, pipeline and view rebuilds, and the features to be checked.
We agree in writing whether Salesforce automation, Apex or AppExchange dependencies are out of scope or require custom work.

How we build

We deploy Twenty in your cloud account or data center with PostgreSQL, Redis, a server and a worker, as the project's Docker Compose guide describes.
We map accounts, contacts, opportunities and tasks to Twenty objects, then test imports from CSV extracts on a non-production copy.
We rebuild pipelines, views, permissions and workflow automation, and check each rebuilt item against the written scope.

How we hand over

We deliver documentation covering the deployment, field mapping, import runbooks, user roles and backup procedures.
We walk your administrators through the Twenty settings they will maintain, including custom objects and fields defined as code.
We agree a cutover plan with your sales operations team, including how Salesforce data remains available during parallel running.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover applying new Twenty releases, reviewing configuration changes and rechecking integrations after each upgrade.
Ask for the support hours, response expectations and upgrade process in writing before you sign, since these depend on your scope.