CRM migration

Migrate from SalesCaptain to Twenty CRM

Field-level mapping, validation, and rollback between SalesCaptain and Twenty CRM. We move data and schema; workflows are rebuilt natively in Twenty CRM.

SalesCaptain logo

SalesCaptain

Source

Twenty CRM

Destination

Twenty CRM logo

Compatibility

80%

8 of 10

objects map 1:1 between SalesCaptain and Twenty CRM.

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from SalesCaptain to Twenty CRM is a migration from a narrow commercial SMB platform to an open-source CRM that ships free and self-hosted. SalesCaptain uses a flat data model with Leads, Companies, Conversations, and Custom Fields; Twenty uses a People-Companies-Opportunities-Activities schema with a /metadata API for custom objects. We map SalesCaptain's conversation threads to Twenty Activity records, preserve custom field schemas as Twenty custom fields, and resolve owner assignment by matching SalesCaptain users to Twenty workspace members by email. SalesCaptain does not expose a bulk export API or workflow definitions via API, so we poll endpoints in controlled batches and deliver a written Workflow Inventory for the customer's admin to rebuild in Twenty's settings. The AGPL-3.0 license on Twenty has no licensing cost implication for self-hosting but requires a legal review if the customer's own software product touches Twenty's codebase.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

SalesCaptain logo

SalesCaptain

What's pushing teams away

  • Steep learning curve when configuring workflows and reporting sends teams looking for simpler alternatives.
  • Customer support response times vary significantly by time of day, frustrating users with urgent issues.
  • Interface complexity causes confusion among non-technical team members, slowing adoption.
  • Limited advanced automation and customization compared to enterprise CRM platforms.
  • Setup and training requirements longer than expected for small teams expecting quick wins.

Choosing

Twenty CRM logo

Twenty CRM

What's pulling them in

  • Top open-source CRM on GitHub with 40.6K stars, giving teams full source code access and infrastructure ownership without per-feature licensing surprises.
  • Free self-hosting under AGPL-3.0 means unlimited users and custom objects for the cost of cloud infrastructure alone, typically $20–100/month.
  • Pricing page explicitly mocks competitors for charging add-on fees for API access, webhooks, and workflows — transparency that resonates with RevOps teams burned by Salesforce.
  • Unlimited custom objects and fields with no price impact, letting teams shape the data model to their business rather than forcing business into rigid schemas.
  • Modern TypeScript/React/PostgreSQL stack means developer-led teams can extend, self-host, or integrate without fighting legacy architecture.

Object mapping

How SalesCaptain objects map to Twenty CRM

Each row shows how a SalesCaptain object lands in Twenty CRM, including any object-level transformations, lookup resolution, or schema-design dependencies.

Typical mapping — final map is confirmed during the sample migration step.

SalesCaptain

Contact

maps to

Twenty CRM

Person

1:1
Fully supported

SalesCaptain Contact records map directly to Twenty Person objects. The primary email, phone, name, and address fields map 1:1. We preserve the SalesCaptain contact's original created date and last_modified timestamp on the Twenty record for audit. Any SalesCaptain custom properties on a Contact map to Twenty custom fields on Person, which we pre-create via the /metadata API before migration begins.

SalesCaptain

Company

maps to

Twenty CRM

Company

1:1
Fully supported

SalesCaptain Company records map 1:1 to Twenty Company objects. Domain name, address, industry, and employee count migrate directly. Company is imported before Person so that the Company-Person relationship is satisfied at Person insert time. We use the SalesCaptain company domain as the dedupe key if duplicate companies exist in the source.

SalesCaptain

Lead

maps to

Twenty CRM

Lead

1:1
Fully supported

SalesCaptain Lead records map to Twenty Lead objects. Lead status, source, and score properties from SalesCaptain migrate as custom fields on the Twenty Lead since Twenty's native Lead model includes standard status and source fields. If the customer has qualified Leads in SalesCaptain that should become People-Company relationships in Twenty, we flag this during scoping and offer a Lead-to-Person convert step post-migration.

SalesCaptain

Deal

maps to

Twenty CRM

Opportunity

1:1
Fully supported

SalesCaptain Deal records map to Twenty Opportunity objects. Deal name, amount, stage, expected close date, and owner migrate directly. The SalesCaptain deal pipeline maps to a Twenty pipeline that we configure before migration. Closed-won and closed-lost reasons from SalesCaptain custom properties become Twenty custom fields for loss and win analysis.

SalesCaptain

Conversation

maps to

Twenty CRM

Activity

1:1
Fully supported

SalesCaptain conversation threads export as activity records with timestamps, participants (contacts or leads), direction (inbound or outbound), and message content. We map these to Twenty Activity records (calls, emails, tasks) with the body preserved as the activity note. Participant resolution uses email matching against the migrated Person and Lead records. This is the highest-risk mapping because SalesCaptain conversation threading does not map to a standard Twenty object type without enrichment.

SalesCaptain

Custom Field

maps to

Twenty CRM

Custom Field (Person, Company, Opportunity, Lead)

lossy
Fully supported

SalesCaptain custom field definitions export as JSON schemas alongside standard field values. We rehydrate custom fields in Twenty by calling the /metadata API to pre-create each field with the correct type (text, number, date, picklist, multi-select). Date-only fields from SalesCaptain that may import as datetime receive explicit type coercion during the transform phase. Multi-select picklist values are delimiter-normalized to match Twenty's format before insert.

SalesCaptain

Communication Channel Profile

maps to

Twenty CRM

Custom Field (Person)

1:1
Fully supported

SalesCaptain channel profile data (phone numbers used for calling, messaging account identifiers) exports as metadata on the Contact. We map these to custom fields on the Twenty Person record (e.g., sms_phone__c, calling_number__c) rather than a native channel object since Twenty does not have a separate Communication Channel Profile concept. Channel-specific routing rules are flagged as configuration items for the customer's admin to review post-migration.

SalesCaptain

User/Team Member

maps to

Twenty CRM

WorkspaceMember

1:1
Fully supported

SalesCaptain user records export with name, email, role, and assignment data. We match SalesCaptain users to Twenty WorkspaceMember records by email address. Any SalesCaptain user without a matching Twenty workspace member goes to a reconciliation queue for the customer's admin to provision before record import resumes. Owner assignment on migrated Deals and Leads is resolved at migration time using the User mapping.

SalesCaptain

Workflow/Automation Rule

maps to

Twenty CRM

None

1:1
Fully supported

SalesCaptain workflow automation rules are not exposed via API and do not migrate. We deliver a Workflow Inventory worksheet during scoping that documents every active rule's trigger conditions, filter logic, and actions so the customer's admin can recreate them in Twenty's settings-based automation. This inventory is a required deliverable before cutover because losing automation rules without a documented replacement causes immediate process disruption.

SalesCaptain

Pipeline

maps to

Twenty CRM

Pipeline

lossy
Fully supported

SalesCaptain deal pipelines map to Twenty Pipeline configurations. Each SalesCaptain pipeline becomes a Twenty Pipeline with stage values migrated as stage entries. Stage probability percentages migrate from SalesCaptain to Twenty stage probability fields, rounded to the nearest integer. We configure the pipeline in Twenty's settings before Deal migration begins.

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

SalesCaptain logo

SalesCaptain gotchas

High

No public bulk export API for high-volume migrations

High

Workflow automation rules do not export via API

Medium

Bearer token rotation requires re-authentication during migration

Medium

Limited custom field type support on import

Low

No public API rate limit documentation

Twenty CRM logo

Twenty CRM gotchas

High

Import order is enforced and critical

High

Export limited to 20,000 records and visible columns only

Medium

Soft-deleted records count toward uniqueness and trigger restores

Medium

API rate limits cap at 200 req/min on Organization tier

Low

No native email sequences — follow-up cadences require external tools

Pair-specific challenges

  • No bulk export API forces batch polling for large record sets

    SalesCaptain's API is oriented toward real-time integrations, not batch data extraction. There is no documented bulk export endpoint or pagination strategy for large record sets. We work around this by polling standard endpoints in controlled batches with retry logic. For migrations exceeding 10,000 records, we flag the timeline impact upfront and discuss whether a partial export of core records is preferable to a slow full extraction. This constraint extends the migration timeline by 30-50 percent compared to platforms with documented bulk export APIs.

  • Picklist and required-field differences between platforms

    SalesCaptain and Twenty CRM use different default picklist values for status and stage fields. A migration without explicit mapping results in import failures or silent data loss when Twenty's validation rejects unrecognized picklist values. We explicitly map each SalesCaptain picklist value to a Twenty picklist value or assign a default during scoping. We also identify required fields in Twenty that are optional in SalesCaptain (such as certain stage or source fields) and assign defaults or request data cleanup before migration begins.

  • Activity and conversation history lacks native equivalent in Twenty

    SalesCaptain stores conversation threads as a first-class object with participant linking and message threading. Twenty does not have a native Conversation object; it uses Activity records for calls, emails, meetings, and tasks. We map SalesCaptain conversation threads to Twenty Activity records, but the threading structure (parent message, reply chain) does not carry over without additional enrichment. Teams that rely on conversation threading for customer context should expect a flattened activity timeline in Twenty.

  • AGPL-3.0 license requires legal review for commercial software integrations

    Twenty CRM uses the AGPL-3.0 license, which requires that any modifications distributed to third parties must also be released under AGPL. For teams using Twenty as an internal CRM with no external distribution, this is not a concern. However, if the customer's own software product integrates with or extends Twenty's codebase, the legal team should review the AGPL implications before committing to the platform. This is not a migration blocker but a legal pre-flight item for software companies.

Migration approach

Six steps for a successful SalesCaptain to Twenty CRM data migration

  1. Discovery and data audit

    We audit the source SalesCaptain account across objects in use (Contacts, Companies, Leads, Deals, Conversations, Custom Fields), team member count, active workflow rules, and engagement volume. We extract a representative data sample to validate field-level types and identify picklist value sets that require explicit mapping. The discovery output is a written migration scope with object counts, a picklist mapping table, and the Workflow Inventory worksheet for the customer to complete before schema design begins.

  2. Twenty schema design and custom field provisioning

    We design the destination schema in Twenty. This includes configuring Pipelines and Stages, pre-creating custom fields via the /metadata API for every SalesCaptain custom property, and mapping SalesCaptain picklist values to Twenty picklist values explicitly. If the customer is self-hosting Twenty, we validate the deployment environment (Node.js version, database connectivity, environment variables including IS_SIGN_UP_DISABLED) before proceeding. Schema is validated in a staging environment before production migration begins.

  3. Owner and user reconciliation

    We extract every distinct SalesCaptain user referenced on Contact, Company, Deal, and Activity records and match by email against the Twenty workspace member list. Any SalesCaptain user without a matching Twenty workspace member is placed in a reconciliation queue. The customer's admin provisions the missing workspace members before record migration resumes. Owner assignment on migrated Deals and Leads cannot proceed until this step is complete because Twenty requires a valid workspace member reference.

  4. Sandbox migration and validation

    We run a full migration into a Twenty staging or sandbox environment using production-like data volume. The customer's team lead spot-checks 25-50 records against the SalesCaptain source, validates the picklist mapping results, confirms the activity timeline is legible, and signs off on the schema and field mapping before production migration begins. Any mapping corrections happen at this stage, not in production.

  5. Production migration in dependency order

    We run production migration in record-dependency order: Companies (foundation object), Persons (with Company relationship resolved), Leads (with workspace member resolved), Opportunities (with Company, workspace member, and Pipeline resolved), Activity records (via batch polling with retry logic, participant resolved by email match), Custom Fields (via /metadata pre-creation then data backfill). Each phase emits a row-count reconciliation report before the next phase begins. Workflow rules are documented separately and not migrated as code.

  6. Cutover, validation, and workflow rebuild handoff

    We freeze SalesCaptain writes during cutover, run a final delta migration of any records modified during the migration window, then enable Twenty as the system of record. We validate record counts across all object types and spot-check a second sample against the source. We deliver the Workflow Inventory document to the customer's admin team with recommendations for recreating each rule in Twenty's settings. We support a five-day hypercare window where we resolve any reconciliation issues. We do not rebuild SalesCaptain workflows in Twenty's settings; that work is scoped separately or handled by the customer's admin.

Platform deep dives

Context on both ends of the pair

SalesCaptain logo

SalesCaptain

Source

Strengths

  • AI voice agents handle routine inbound calls and routing without manual intervention.
  • Shared inbox consolidates SMS, calls, and messages into a single threaded view.
  • Designed for SMB service businesses rather than enterprise, reducing feature bloat.
  • Phone and CRM in one platform eliminates the need for separate telephony tools.
  • Real-time call logging and activity tracking keep reps accountable.

Weaknesses

  • Narrow third-party integration ecosystem compared to HubSpot or Salesforce.
  • Limited API documentation and fewer developer resources available.
  • Smaller vendor with less than 50 employees raises long-term viability questions.
  • No documented bulk export or enterprise-grade API rate limit specifications.
  • Custom object support is minimal; teams with complex data models outgrow it quickly.
Twenty CRM logo

Twenty CRM

Destination

Strengths

  • AGPL-3.0 open-source license with full source code on GitHub — no vendor lock-in, no sunset risk.
  • Unlimited users and unlimited custom objects on self-hosted, with no feature gating based on headcount.
  • REST and GraphQL APIs available on all paid tiers, not locked behind an enterprise add-on fee.
  • MCP server and webhooks shipped as standard features, not premium upgrades.
  • Modern PostgreSQL-backed data model that developer teams can query, extend, and self-host.

Weaknesses

  • Recent v1.0 release means limited production hardening compared to CRMs with multi-year operational track records.
  • No native email sequencing or sales engagement tools — follow-up cadences require a separate platform.
  • No native two-way email sync or inbox integration, requiring third-party connectors for full activity logging.
  • Self-hosting 'free' pricing hides real infrastructure and DevOps costs that stack up over time.
  • Workflow automation is functional but lacks the complexity needed for sophisticated multi-step sales motions.

Complexity grading

How hard is this migration?

Standard CRM migration. 3 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across SalesCaptain and Twenty CRM.

  • Object compatibility

    B

    3 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    SalesCaptain: Not publicly documented.

  • Data volume sensitivity

    B

    SalesCaptain doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your SalesCaptain to Twenty CRM migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about SalesCaptain to Twenty CRM data migrations

Answers to the questions buyers ask most during SalesCaptain to Twenty CRM migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your SalesCaptain to Twenty CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most migrations land between three and five weeks for accounts under 15,000 Contacts, 3,000 Companies, and no custom objects with extensive conversation histories. Migrations with custom objects, large activity records (over 200,000 conversation threads), multiple workspace member provisioning cycles, or self-hosted Twenty deployments requiring server configuration extend to eight to twelve weeks because of batch polling overhead and extended validation cycles. SalesCaptain's lack of a bulk export API adds 30-50 percent to the extraction timeline compared to platforms with documented bulk endpoints.

Adjacent paths

Related migrations to explore

Ready when you are

Move from SalesCaptain.
Land in Twenty CRM, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day