Salesforce to Twenty CRM Migration

Teams choose Twenty to own their CRM and their data: its core is open source, it can be self-hosted, and every custom object gets its own API. Read why companies are leaving Salesforce for open-source CRM, our Twenty CRM review, the Twenty CRM vs Salesforce comparison and whether Twenty is right for your business.

The checklist, field map and timeline below cover the move itself. After the migration, our Twenty CRM implementation team can run and extend it, including self-hosting on AWS.

The reasons teams give most often:

• More platform than the team can run. Flow, Process Builder, Apex and Lightning components need specialists; the complexity grows with every year of customization.
• Per-user cost. Seats and editions priced for features the team does not use, plus admin and consultant fees.
• Simpler workflows. A CRM the team can change itself, without a developer for every new field.
• Integrations built on open APIs. Twenty gives every object REST and GraphQL endpoints.
• Owning the data and the code. Twenty’s core is open source and can run on your own servers.

List prices per user per month from each vendor’s pricing page, in USD, checked October 2026:

Every Twenty plan has unlimited custom objects and fields. Licenses are only part of the bill: the migration, rebuilt automations and training come on top, and so does running the servers if you self-host. Check both pricing pages in your own currency before you budget.

Field mapping matches each Salesforce field to a Twenty field. Most fields move one to one; the rest change on the way:

Twenty’s import rules shape the map:

• Fields come first. An import creates records, not fields, and it does not add select options. Every custom field and option is set up in Settings, Data Model, before the data is loaded.
• Picklists become select fields. Values go in by their API name (HIGH_PRIORITY, not “High Priority”). A multi-select picklist moves to a multi-select field as a list such as ["VALUE1","VALUE2"], and an import replaces a record’s selections rather than adding to them.
• Currency is two columns, the amount and the currency code, and both must be filled.
• Dates load cleanly as YYYY-MM-DD.
• Records match on a unique field: the record ID, a person’s email or a company’s domain. Keeping each Salesforce ID means a re-run updates records instead of duplicating them, and relations can be linked by ID.

The map also settles what Salesforce allowed and your Twenty set-up does not: a field that was optional but is now required gets a default or is filled before the import, and text that should be a number or a date is converted, or the row is rejected. Picklist values that differ get a written translation, decided once. For example, for a lead status:

Twenty allows unlimited custom fields, so the limit is upkeep, not the platform: recreate the fields your workflows, reports and compliance use, and retire the rest.

Before the move

1. Audit the org. Objects, record counts, which fields are filled and used, and every custom object with what depends on it.
2. List the automation. Each flow, workflow rule, Process Builder process and Apex trigger, and who relies on it.
3. Map the integrations. Every system that reads or writes Salesforce, and how it will reach Twenty: a native connector, a tool such as Zapier or n8n, or the API.
4. Agree the scope with the people who use the data. Which objects move, how much history (activities, opportunity stage history, the audit trail), and what is archived instead.
5. Set success criteria in numbers. Error rate on migrated records, record counts per object, key reports matching Salesforce, integrations running, and how many users work in Twenty by day 30.
6. Clean before you move. Remove duplicates, standardize formats and retire fields nobody uses. A full Salesforce data export first gives you a backup.

Moving the data

7. Load in dependency order. Invite users, then load companies, people, opportunities, custom objects with relations, and last the notes, tasks and files that attach to them. A record loaded before its parent becomes an orphan.
8. Keep the dates. Created and modified dates come across with each record, so history keeps its timeline.
9. Test in rounds. A sample from every object (mapping and formats), then a larger subset (relations, automations, who can see what), then a full dry run (speed, search, reports). Each failure and its fix is written down before the next round.
10. Choose the cutover. A hard cutover is one switch with no fallback; parallel running is safer but means entering data twice; a phased move goes team by team and takes longer overall.
11. On the day: a final backup, Salesforce set to read-only, the records created since the last load moved, and counts compared before anyone works in Twenty.
12. Keep data safe in transit. Encrypted files, access only for the people doing the move, a log of every export and load, and your GDPR or CCPA duties carried over.

After the move

13. Validate in layers, against the targets set in step 5:

14. Rebuild and test integrations and automations, then let each team test its own daily work in Twenty.
15. Train by role and update your documentation. Keep Salesforce read-only for 30 to 60 days as a fallback, and review the criteria at 30, 60 and 90 days.

Data volume, customization, integrations and the time your team can give to checks set the length, so dates come after the assessment, not from a rule of thumb:

• Small org: standard objects, little customization, clean data and few integrations. The shortest path, but it still needs a map, a test load and checks.
• Mid-sized org: some custom objects, integrations to reconnect, several teams to train. Mapping needs transformations, and Salesforce orgs that have run for years often show customization nobody listed at the start.
• Highly customized org: many custom objects, complex automation, compliance sign-off. Custom objects may need redesign, automations are recreated and tested, and the move is often phased.

Preparation decides the speed more than anything else: a problem found in the audit costs less to fix than one found after cutover.

• Moving everything. Unused legacy data adds load time and clutter. Decide the scope in the audit.
• Skipping deduplication. Duplicates in Salesforce become duplicates in Twenty, now with relations attached.
• Underestimating custom objects. One central custom object can need a redesign; find it in the audit, not mid-migration.
• Losing history. Activity that is not mapped, or dates reset to the migration day, strips records of their context.
• Loading out of order. Children loaded before parents end up linked to nothing.
• Skipping test loads, or having no rollback plan. The first full load should never be the production one.
• Forgetting integrations. Email, calendar, billing and support tools stop syncing unless each is rebuilt and tested.
• Expecting Salesforce inside Twenty. Twenty works differently; decide which behaviors matter and which can change. Our Twenty CRM review covers where it is still thin.
• Rushing cutover. Once people create records in Twenty, going back is hard. Set the cutover criteria first.
• Leaving users out. Data can be perfect and the move still fail if people go back to spreadsheets: user adoption needs early news, role-based training and someone to ask.

Twenty is younger than Salesforce. Stay, or plan carefully, if:

• You depend on AppExchange products such as CPQ, field service or industry clouds.
• Your process lives in Apex, and redesigning it costs more than the licenses you would save.
• Nobody can own the CRM technically. Self-hosting means someone runs updates and backups; Twenty’s hosted service is the alternative.

Not sure which applies to you? Our Twenty CRM consulting team reviews your Salesforce setup before you decide.

Moving to monday.com instead, or from another tool? Our data migration service covers every move we run.