CRM migration

Migrate from Results to Twenty CRM

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

Results logo

Results

Source

Twenty CRM

Destination

Twenty CRM logo

Compatibility

91%

10 of 11

objects map 1:1 between Results and Twenty CRM.

Complexity

BStandard

Timeline

2-4 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from Results to Twenty CRM is a migration with limited documentation on the source side and a well-documented open-source destination. Results does not publish a public API schema or confirmed field inventory, so our first step is always a scoped extraction feasibility call to determine what can be exported, in what format, and whether any custom objects or calculated fields exist. Twenty uses a clean entity model: People (for contacts), Company (for organizations), Opportunity (for deals), Task and Note (for activities), and supports custom objects via the /metadata API. We pre-provision Twenty Users before importing any records that carry an Owner reference, and we pre-create all custom fields in Settings before running the first import batch. Workflows, automations, and sequence logic do not migrate; we deliver a written inventory of every automation requiring rebuild so your admin can reconstruct them in Twenty's workflow builder post-migration.

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

Results logo

Results

What's pushing teams away

  • Architecture limits — the platform is positioned for SMBs and not designed to scale beyond ~15 users or 15,000 contacts, prompting growing teams to migrate to enterprise platforms.
  • No public REST API documentation or developer portal — custom integrations beyond the published connectors depend on vendor engagement or Zapier middleware.
  • QuickBooks-centric integration story leaves teams running NetSuite, Xero, or Sage looking elsewhere for native bidirectional accounting sync.
  • Heavy reliance on Windows and Office desktop environments may not fit fully browser-native or macOS/Linux remote workforces.
  • Limited public review volume on G2 and a small community footprint make benchmarking and peer-comparison harder than for category leaders.

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 Results objects map to Twenty CRM

Each row shows how a Results 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.

Results

Contact

maps to

Twenty CRM

People

1:1
Fully supported

Results Contact records map to Twenty People. The primary email address on the Contact becomes the People email field and serves as the dedupe key during import. Any first name, last name, phone, job title, or address fields map to their Twenty equivalents. We confirm the exact field inventory on the Results side during the scoping call because no public API schema is documented.

Results

Company

maps to

Twenty CRM

Company

1:1
Fully supported

Results Company records map to Twenty Company. The domain or website on the Company becomes the Company domain field and is used for cross-referencing People records by domain. Company is created before any People import so that the relationship lookup is satisfied at the moment of People insert.

Results

Deal

maps to

Twenty CRM

Opportunity

1:1
Fully supported

Results Deal records map to Twenty Opportunity. The deal stage maps to Twenty stage, and the pipeline assignment maps to a Twenty Record Type with a corresponding Sales Process configured before migration. Deal amount, close date, and probability migrate to their Twenty equivalents.

Results

Pipeline

maps to

Twenty CRM

Record Type + Sales Process

lossy
Fully supported

Each Results deal pipeline becomes a Twenty Record Type on Opportunity with its own Sales Process that defines the valid stage values and probabilities. Stage names and ordering are preserved from Results, with the customer choosing whether to include or exclude closed-lost or stale stages from the target configuration.

Results

Owner

maps to

Twenty CRM

Workspace Member (User)

1:1
Fully supported

Results Owner references on Contact, Company, Deal, and Activity records map to Twenty Workspace Members resolved by email match. We require the customer to invite and confirm all Users in Twenty before record migration begins, per Twenty's documentation requirement that users must exist before Owner lookups can resolve. Owners without a matching Twenty User go to a reconciliation queue.

Results

Custom Object

maps to

Twenty CRM

Custom Object

1:1
Fully supported

Results custom objects migrate to Twenty custom objects of matching name. We create the destination schema in Twenty via Settings → Data Model and the /metadata API before any custom object data is imported. All custom fields, field types, picklist values, and lookup relationships are pre-configured. Any lookup fields referencing standard objects (People, Company, Opportunity) are validated against the existing import of those objects.

Results

Activity: Call

maps to

Twenty CRM

Task (TaskSubtype = Call)

1:1
Fully supported

Results call activities map to Twenty Task records with the call subtype flagged. Call duration, disposition, and any recording URL stored in Results migrate to custom Task fields in Twenty. The activity timestamp preserves the original Results timestamp for timeline ordering.

Results

Activity: Email

maps to

Twenty CRM

Task

1:1
Fully supported

Results email activities map to Twenty Task records. The email subject and body migrate to the Task body, linked to the related People or Company record. If Results stores email as a separate activity object, we map it to Task with the email body preserved in the body field and the timestamp used for timeline ordering.

Results

Activity: Meeting

maps to

Twenty CRM

Task

1:1
Fully supported

Results meeting activities map to Twenty Task records. Meeting title, attendees, start time, and location migrate to the corresponding Task fields. The task is linked to the relevant People, Company, or Opportunity record via the Twenty relationship model.

Results

Activity: Note

maps to

Twenty CRM

Note

1:1
Fully supported

Results notes (standalone note records or note-type activities) map to Twenty Note records linked via ContentDocumentLink to the parent People, Company, or Opportunity record. Rich text formatting is preserved where the Results export format supports it.

Results

Attachment

maps to

Twenty CRM

Attachment

1:1
Fully supported

Attachments associated with Contact, Company, or Deal records in Results migrate as Twenty Attachments linked to the corresponding People, Company, or Opportunity record. File names and original upload timestamps are preserved. Attachments exceeding 25 MB are flagged for manual handling or alternative delivery.

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.

Results logo

Results gotchas

High

QuickBooks-linked records have dual sources of truth

Medium

Suite is not architected to scale beyond ~15 users / 15K contacts

Medium

No documented public REST API

Medium

Field Service photos and signatures require separate binary extraction

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

  • Results has no publicly documented export API

    Results does not publish a public REST API schema or confirmed CSV export format, which means the extraction method must be verified during the scoping call. Depending on the Results instance configuration, export may require a direct database connection, a vendor-assisted export, or a supported data extraction method. We identify the viable extraction path before committing to a migration plan and flag any custom calculated fields or restricted records that may not export cleanly. This step adds one to two weeks to discovery compared to platforms with documented APIs.

  • Twenty requires Users to exist before Owner lookups resolve

    Twenty's documentation explicitly requires that users be invited and active in the workspace before Owner references on Contact, Company, Deal, or Activity records can resolve during import. We require the customer to provision all Workspace Members in Twenty before the production migration begins. If a Results Owner has no corresponding Twenty User, that Owner goes to a reconciliation queue and records referencing that Owner are held until the customer provisions the missing User or remaps the Owner to an existing Twenty User.

  • Custom fields must be created in Twenty before CSV import

    Twenty's CSV import creates records but does not create fields. Any custom fields present in Results that have no equivalent in Twenty's standard schema must be pre-created in Settings → Data Model before the migration run. We handle this as a pre-migration configuration step, but any field type mismatch (for example, a Results multi-select field that must become a Twenty picklist) requires a transformation rule documented in the field mapping sheet. Fields created after migration begins require a re-run of the affected import batch.

  • Workflows and automations do not migrate as code

    Results workflows, automation rules, and sequence logic are not migrated to Twenty because they are not code-compatible with Twenty's automation model. We deliver a written inventory of every active automation in Results, including its trigger, conditions, actions, and recommended Twenty equivalent. The customer's admin rebuilds these in Twenty's workflow builder post-migration. Sequence or cadence logic (if present in Results) is documented separately as a process note for the customer to evaluate against Twenty's roadmap for sequencing or to select a specialized sales engagement tool.

  • Legacy data quality issues multiply during migration

    Results instances that have been in use for multiple years typically contain duplicate Contacts, outdated Company records, Deals in stale pipeline stages, and test data from initial setup. Twenty's clean import model surfaces these issues rather than hiding them. We work with the customer's team during scoping to define archival criteria (for example, Contacts with no activity in 24+ months, Deals in Closed-Lost for 12+ months) so that only active, valuable data migrates. Migrating clutter inflates record counts, pollutes analytics, and adds cost without delivering business value.

Migration approach

Six steps for a successful Results to Twenty CRM data migration

  1. Extraction feasibility and data audit

    We schedule a scoped extraction call to identify the viable export path from the Results instance. We audit all object types present (Contacts, Companies, Deals, Activities, Custom Objects), estimate record counts per object, and identify any custom fields, calculated fields, or restricted data. We document the Results field inventory and confirm with the customer which records meet the archival criteria for migration versus exclusion. The output is a written extraction plan and a preliminary object mapping sheet.

  2. Twenty workspace provisioning

    Before any data is imported, we provision the Twenty workspace with the required configuration. This includes inviting and confirming all Workspace Members who are referenced as Owners in the Results data, creating all custom objects in Settings → Data Model, and creating all custom fields on standard and custom objects with correct field types. We configure Record Types and Sales Processes corresponding to each Results pipeline and stage set. This step is a prerequisite; Twenty will not resolve Owner lookups on import if the User records do not exist.

  3. Sandbox migration and reconciliation

    We run a full migration into a Twenty Sandbox or a parallel workspace using production-like data volume. The customer's RevOps lead reviews record counts, spot-checks 25-50 records for field accuracy and relationship integrity, and verifies that People records are correctly linked to Companies and Opportunities are correctly linked to People and Companies. Any field mapping corrections, transformation rule adjustments, or schema modifications are made in this phase before production migration begins.

  4. Owner reconciliation and User provisioning validation

    We extract every distinct Owner referenced on Contact, Company, Deal, and Activity records from Results and match by email against the Twenty workspace's User table. Owners without a matching Twenty User are placed in a reconciliation queue. The customer's admin resolves the queue by either provisioning the missing Twenty User or remapping the Owner to an existing User. Migration does not proceed past this step because OwnerId references are required on most standard object imports.

  5. Production migration in dependency order

    We run production migration in record-dependency order: Workspace Members (validated), Companies (from Results Organizations), People (with CompanyId resolved from the Company import), Opportunities (with CompanyId and OwnerId resolved), Activity history (Tasks and Notes linked to People, Companies, and Opportunities), Custom Objects (last, with lookups to standard objects already resolved), and Attachments (linked to the parent record). Each phase emits a row-count reconciliation report before the next phase begins. We use batch processing with retry logic for any failed records.

  6. Cutover, validation, and automation rebuild handoff

    We coordinate a cutover window during off-peak hours, run a final delta migration of any records created or modified during the migration window, and switch the system of record to Twenty. We deliver the automation inventory document to the customer's admin team. We support a one-week hypercare window to resolve any reconciliation issues raised by the team during initial use. Workflows, sequences, and automations are not rebuilt inside the migration scope; that work is a separate engagement or an internal admin task.

Platform deep dives

Context on both ends of the pair

Results logo

Results

Source

Strengths

  • Tight QuickBooks Desktop and Online integration eliminates double-entry between CRM and accounting.
  • Bundled CRM, Sales, Business, and Field Service modules in one suite reduce tool sprawl for service SMBs.
  • Field Service module at $10/user/month adds mobile photo/signature capture and on-site checklists at low marginal cost.
  • Choice of one-time perpetual license or month-to-month rent-to-own subscription accommodates SMB cash flow constraints.
  • Pre-built integrations with AvaTax, Zapier, Outlook, Gmail, SMS, WhatsApp, and Calendly cover common SMB stack needs.

Weaknesses

  • Not architected to scale beyond ~15 users or 15,000 contacts.
  • No documented public REST API; custom integrations require Zapier or vendor engagement.
  • QuickBooks-centric story leaves NetSuite/Xero/Sage customers without native integration.
  • Windows/Office desktop dependencies limit fit for fully browser-native or macOS/Linux teams.
  • Limited public review volume on G2 and small community footprint complicate vendor comparison.
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 Results 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

    Results: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

Estimate your Results 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 Results to Twenty CRM data migrations

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

Can't find your answer?

Walk through your Results 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 two and four weeks for accounts under 15,000 Contacts, 3,000 Deals, and no custom objects. Migrations with multiple custom objects, multi-pipeline Deal structures, large activity histories, or partial export scenarios that require vendor coordination for extraction move to six to ten weeks. The extraction feasibility step adds one to two weeks to discovery compared to platforms with documented APIs, because we must confirm the viable export path from Results before mapping can begin.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Results.
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