CRM migration

Migrate from Propertybase to Twenty CRM

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

Propertybase logo

Propertybase

Source

Twenty CRM

Destination

Twenty CRM logo

Compatibility

83%

10 of 12

objects map 1:1 between Propertybase and Twenty CRM.

Complexity

BStandard

Timeline

48–72 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Propertybase runs on a Salesforce backend, meaning its CRM data lives in standard Salesforce objects — Contacts, Accounts, Leads, Opportunities — plus Propertybase-specific custom objects for Listings, Offers, and real estate transaction tracking. When you migrate to Twenty CRM, which uses a streamlined People-Companies-Opportunities schema with full custom object support, the core challenge is mapping Propertybase's Salesforce record types and custom real-estate fields into Twenty's field model without losing transactional context. FlitStack AI extracts data via the Salesforce REST API (respecting per-user rate limits and excluding formula/roll-up summary fields that Propertybase exports always drop), then transforms and loads into Twenty using its CSV import or GraphQL API. Standard CRM objects — contacts, companies, deals, activities — migrate with direct or value-mapped field translations. Real estate-specific objects — Listings, Offers/Contracts, custom record types for individual buyers versus company contacts — require custom object creation in Twenty and careful association mapping. We preserve original create dates, owner assignments, and association links throughout. Workflows, validation rules, and report definitions do not migrate and must be rebuilt in Twenty or exported as reference documents for manual recreation.

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

Propertybase logo

Propertybase

What's pushing teams away

  • Customers report recurring billing issues where the company charges unexpectedly, with one reviewer stating the platform 'literally steals money' through billing disputes.
  • The onboarding experience is described as basic and unhelpful — teams report needing to build their own features to make the software usable, suggesting inadequate initial setup support.
  • A steep learning curve makes the platform difficult to adopt — reviews indicate 'you have to learn how to make it do it all' rather than it working out of the box.
  • Alternative platforms like BoomTown (4.7/5) and BoldTrail (4.5/5) score higher on G2, prompting teams to evaluate options with more modern UX and simpler configuration.
  • Enterprise pricing at $89/user/month is cost-prohibitive for larger teams compared to flat-rate alternatives in the real estate CRM market.

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

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

Propertybase

Contact (Individual)

maps to

Twenty CRM

People

1:1
Fully supported

Propertybase Individual Contacts (SystemIsIndividual=TRUE) map directly to Twenty People. The ghost Account record that Salesforce requires for all contacts is discarded — Twenty People records have no mandatory AccountId requirement. Original create dates are preserved as a custom field since Twenty's CreatedAt is set at import time.

Propertybase

Contact (Company)

maps to

Twenty CRM

People + Companies

many:1
Fully supported

Propertybase Company Contacts (SystemIsIndividual=FALSE) split into a Twenty People record (the contact person) and a Twenty Company record (the agency or brokerage they work for). The Person is linked to the Company via the companyId field. This separates the individual from the firm they represent.

Propertybase

Account

maps to

Twenty CRM

Companies

1:1
Fully supported

Propertybase Accounts map directly to Twenty Companies. Company name, domain, industry, employee count, and annual revenue translate field-for-field. Parent-account hierarchies (if used) map to the Twenty Companies' own companyId for self-referential parent linking. Multi-company contact links are preserved as Twenty People-Company associations.

Propertybase

Opportunity (Deal)

maps to

Twenty CRM

Opportunities

1:1
Fully supported

Propertybase deals stored as Salesforce Opportunities migrate to Twenty Opportunities. Deal name, amount, close date, stage, and probability translate with value-mapping on stage names. The Opportunity is linked to the primary Company and the primary associated People record via Twenty's companyId and peopleId fields.

Propertybase

Listing (custom object)

maps to

Twenty CRM

Custom Object: Listing

1:1
Fully supported

Propertybase Listings are a custom Salesforce object tracking property-level data. Since Twenty has no native Listing object, FlitStack creates a Listing custom object in Twenty under Settings → Data Model before import. Property fields (address, price, bedrooms, bathrooms, sqft, listing status) are recreated as Twenty fields of the appropriate type.

Propertybase

Offer / Contract (custom object)

maps to

Twenty CRM

Custom Object: Offer

1:1
Fully supported

Propertybase Offer/Contract records track purchase offers linked to Listings and Contact purchasers. These migrate as a second Twenty custom object (Offer) with lookup relations to the Listing and People custom objects. Offer amount, status, and terms fields map to identically named fields in Twenty. The Offer → Listing link uses Twenty's relation field type pointing to the Listing custom object.

Propertybase

Task / Event (activity)

maps to

Twenty CRM

Tasks

1:1
Fully supported

Propertybase logged calls, emails, and meetings stored as Salesforce Tasks and Events migrate to Twenty Tasks. The Subject field carries the activity type (Call, Email, Meeting), and description fields preserve body text. Original timestamps and assigned owners are carried over. Recurring tasks and calendar Events are simplified to individual Task records in Twenty.

Propertybase

Lead

maps to

Twenty CRM

People

1:many
Fully supported

Propertybase Leads that have not been converted to Contacts are imported as Twenty People records tagged with a Lead_Source__c custom field to preserve origin. If a Lead has a corresponding Account or Opportunity in Propertybase, those relationships are preserved by matching on the source record's ID stored in a Source_System_ID__c field on the Twenty People record.

Propertybase

User (owner)

maps to

Twenty CRM

WorkspaceMember

1:1
Fully supported

Propertybase owner assignments (Salesforce User IDs on Contacts, Accounts, Opportunities) are resolved by email. FlitStack matches the owner email on each Propertybase record to a Twenty workspace Member invited before migration. Unmatched owners are flagged in a pre-migration audit report; your team either invites those users to Twenty first or designates a fallback owner for assignment.

Propertybase

Attachment / File

maps to

Twenty CRM

Note (with file attachment)

1:1
Fully supported

Propertybase file attachments on Listings, Offers, or Contacts are downloaded from Salesforce Files and re-uploaded to Twenty, attached to the corresponding record as a Note with a file link. Salesforce's 25MB per-file limit applies during extraction; files larger than this are flagged for manual handling.

Propertybase

Custom field (listing-specific)

maps to

Twenty CRM

Custom field on Listing object

1:1
Fully supported

Propertybase custom fields added to Listings — such as property type, HOA fees, MLS number, or days-on-market — are created as Twenty fields on the Listing custom object before the data load. Field types are matched (text, number, select, date) based on Propertybase field metadata. Fields marked required in Propertybase are set required in Twenty's Data Model.

Propertybase

Workflow Rules

maps to

Twenty CRM

No equivalent

1:1
Mapping required

Propertybase Workflow Rules govern offer-stage changes, listing-status updates, and contact assignment automation. These are platform-configured Salesforce workflows with no Twenty equivalent. FlitStack exports the workflow definitions as JSON reference documents your team uses to rebuild equivalent automations in Twenty's Settings → Workflows. This is a manual rebuild step — plan 1–3 days of configuration work.

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.

Propertybase logo

Propertybase gotchas

High

Formula and roll-up summary fields excluded from exports

Medium

Ghost company records for Individual Contacts

Medium

Workflow rules do not export — automations must be rebuilt

Medium

Media Loader assets require separate migration path

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

  • Propertybase formula and roll-up summary fields are always excluded from exports

    Salesforce's export mechanism — which Propertybase uses for all its data extraction — permanently excludes formula fields and roll-up summary fields from any data dump, regardless of whether the export is run manually or via API. If your Propertybase reports rely on calculated fields like 'days in stage' or 'lifetime deal value' that are stored as formula fields, those values will not appear in the export and therefore will not reach Twenty. FlitStack flags every formula field found during the pre-migration audit and surfaces them as fields that need manual recalculation or a Twenty field update formula after migration.

  • Listing-to-Offer associations require custom lookup fields created before import

    Twenty's CSV import process requires that all target fields exist before records land — it creates records, not fields. Propertybase stores offer-to-listing links as Salesforce lookup fields on the Offer__c custom object. In Twenty, those links need to be recreated as relation fields on the Offer custom object pointing to the Listing custom object, and both custom objects must exist in Twenty's Data Model before the import sequence begins. If your team skips the pre-creation step, the import will fail on the Offer rows because the relation field won't exist yet. FlitStack includes a schema-preparation step that creates all custom objects and their field types before any data moves.

  • Individual contacts and company contacts require different import paths

    Propertybase uses the SystemIsIndividual flag on Contact records to distinguish individual buyers (no associated company) from company contacts (associated with an agency or brokerage firm). This distinction has no direct equivalent in Twenty's People object — all contacts land as People regardless of whether they represent a firm or an individual. The translation requires FlitStack to split Propertybase Company Contacts into two records: the person (People) and the firm (Companies), then re-link them via companyId. Contacts that have no company association in Propertybase import as standalone People records. This deconstruction step is the most common source of association loss if handled manually.

  • Workflow rules and validation rules do not migrate and have no Twenty equivalent

    Propertybase Workflow Rules and Validation Rules are Salesforce automation constructs — process builders that evaluate criteria and trigger field updates, email alerts, or record locks — that have no structural equivalent in Twenty. Specifically, workflows that auto-advance offer stages when listing status changes or lock a Contact record when certain fields are blank cannot be carried over. Twenty's workflow builder supports basic conditional automation but not the multi-step branching logic that Salesforce Flow handles. Teams migrating from Propertybase should plan 1–3 days for a consultant or admin to rebuild core automations in Twenty. FlitStack exports workflow definitions as JSON reference documents for this rebuild step.

  • Twenty's per-minute API rate limits cap bulk migration throughput

    Twenty's cloud tiers impose API rate limits (100 requests per minute on Pro, 200 on Organization) that constrain how fast FlitStack can push records during the migration window. For migrations with more than 50,000 records, FlitStack switches to batched CSV import via Twenty's native CSV import tool, which is not rate-limited, rather than the GraphQL API. Large listing and offer datasets with complex associations may require a multi-pass import approach — companies and people first, then listings, then offers — to respect the import order documented in Twenty's own migration guide. FlitStack sequences these passes automatically.

Migration approach

Six steps for a successful Propertybase to Twenty CRM data migration

  1. Audit Propertybase data and build the migration mapping document

    FlitStack connects to your Propertybase Salesforce org via the REST API using a dedicated integration user with read-only access. We pull a full export of all objects including custom Listing and Offer fields, map every standard and custom field to its Twenty equivalent, and identify formula fields (which will be excluded per Salesforce's export rules). We also capture owner email addresses for resolution against Twenty workspace Members. The output is a field-level mapping document your team reviews before any data moves.

  2. Create custom objects and fields in Twenty's Data Model

    Before importing any records, FlitStack creates the Listing and Offer custom objects in Twenty under Settings → Data Model, along with all required fields and their types (text, number, select, relation). We also create any custom fields on the standard People and Companies objects (Lead_Source__c, Original_Create_Date__c, Source_System_ID__c) that carry Propertybase metadata across. This step requires a Twenty admin with Data Model write access. We deliver a step-by-step setup checklist based on the mapping document so your team can complete this independently or with our guidance.

  3. Invite users to Twenty and resolve owner assignments

    Twenty requires workspace Members to exist before user references (ownerId, assignee) can map during import. FlitStack generates an owner-resolution report listing every Propertybase owner email and whether it corresponds to an invited Twenty Member. Your team sends invitations to any missing users before the migration run. Owners without a matching Twenty account are assigned to a designated fallback Member — flagged in the report for later reassignment in Twenty after migration.

  4. Run a sample migration with field-level diff

    A representative slice — typically 200–500 records spanning People, Companies, Opportunities, Listings, and Offers — migrates first using the full mapping logic. FlitStack generates a field-level diff comparing source values against destination values for every mapped field, so you can verify stage name mappings, owner resolution, association links, and custom object field population before committing the full dataset. No records are deleted during this phase; the diff is a read-only validation.

  5. Execute full migration with delta-pickup window

    The full migration runs against Twenty using the validated mapping. A delta-pickup window of 24–48 hours following the initial load captures any records created or modified in Propertybase during the cutover period. Every operation is logged in FlitStack's audit log. If reconciliation fails — record counts don't match, associations are broken, or field values fall outside expected ranges — one-click rollback reverts the Twenty org to its pre-migration state so your team can investigate and re-run without data loss.

Platform deep dives

Context on both ends of the pair

Propertybase logo

Propertybase

Source

Strengths

  • Salesforce-backed infrastructure provides enterprise-grade security, scalability, and a familiar interface for teams with Salesforce experience.
  • Comprehensive real estate feature set covering the full sales cycle from lead capture through transaction close without requiring multiple disconnected tools.
  • Native listing management with media handling allows teams to store and display property images, video links, and PDFs within a single system.
  • Per-unit pricing model scales with brokerage size, making entry affordable for small teams before requiring enterprise-level investment.

Weaknesses

  • Recurring billing disputes and perceived billing practices drive negative reviews that signal customer satisfaction risk during and after migration.
  • Basic onboarding experience forces teams to invest significant time configuring the platform before it delivers real value.
  • Formula and roll-up summary fields cannot be exported, requiring migration teams to reconstruct calculated values from underlying source data.
  • Enterprise pricing at $89/user/month makes the platform expensive for large teams compared to flat-rate real estate CRM alternatives.
  • Workflow rules and automation are not data-exportable and must be manually rebuilt on the destination platform, adding migration complexity.
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. 1 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 Propertybase and Twenty CRM.

  • Object compatibility

    B

    1 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

    Propertybase: Salesforce API limits apply — not publicly documented per Propertybase tier.

  • Data volume sensitivity

    A

    Propertybase exposes a bulk API — large-volume migrations stream efficiently.

Estimator

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

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

Can't find your answer?

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

Book a free 30 minute consultation

Most Propertybase-to-Twenty migrations complete in 48–72 hours of clock time for under 25,000 total records including People, Companies, Opportunities, Listings, and Offers. Larger setups with 200,000+ records or multiple custom objects extend to 7–14 days. The longest single step is setting up the Listing and Offer custom objects in Twenty's Data Model before import — plan 1–2 days for schema configuration. Actual data transfer time depends on API rate limits and whether we use Twenty's CSV import (faster for large batches) or GraphQL API.

Adjacent paths

Related migrations to explore

Ready when you are

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