CRM migration

Migrate from Bright to Twenty CRM

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

Bright logo

Bright

Source

Twenty CRM

Destination

Twenty CRM logo

Compatibility

100%

14 of 14

objects map 1:1 between Bright and Twenty CRM.

Complexity

BStandard

Timeline

48–72 hours of clock time

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Bright stores standard CRM objects — people, companies, deals, tasks, and notes — with custom fields and relationship associations. The platform uses a relational model where each record can link to related entities. Twenty CRM ships with standard objects (People, Companies, Opportunities, Tasks, Notes) and supports unlimited custom objects and custom fields on every tier. We map Bright's data model directly to Twenty's objects: people become People records with companyId pointing to their parent Company; deals become Opportunities with a stage pick-list and a linked companyId; tasks and notes migrate as their Twenty equivalents with original timestamps and owners preserved. The migration does not move automations. Bright workflows — whether triggered by field changes, date conditions, or form submissions — have no equivalent in Twenty's workflow engine. We export Bright workflow definitions as a rebuild reference for Twenty's workflow builder. Integrations and third-party connections must be re-established in Twenty separately. We access Bright through API where available, falling back to CSV export for custom-field-heavy records. Twenty's import API handles up to 200 calls per minute on the Organization tier, making bulk record loading viable for mid-size datasets. We sequence the migration so Companies land first (the 'one' side of relationships), then People (with companyId links resolved), then Opportunities (with companyId and personId links), then custom objects. This ordering satisfies Twenty's foreign-key requirements and prevents orphaned records. A scoped read-only connection to Bright keeps your team operational throughout cutover, with a delta-pickup window capturing any records modified during the switchover.

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

Bright logo

Bright

What's pushing teams away

  • Reporting flexibility is limited compared to enterprise payroll systems — customers needing custom analytics often bridge to external BI tools.
  • Document storage and viewer functionality lacks the polish of dedicated document management platforms, an annoyance for HR-heavy users.
  • UK-only focus means companies expanding internationally have to migrate to multi-country payroll providers like Deel, Remote, or ADP iHCM.
  • Bureau pricing scales aggressively (e.g., £329 for 10 employers, £549 for 25 employers per tax year), pushing larger payroll bureaus toward subscription-based alternatives.
  • Cloud transition is still in progress — historically a desktop-installed Windows product, customers wanting fully cloud-native payroll without local install evaluate alternatives during the transition window.

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

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

Bright

People

maps to

Twenty CRM

People

1:1
Fully supported

Bright's person records (contacts, leads, partners) map directly to Twenty CRM's People object. Every field on the Bright record — name, email, phone, job title — transfers to the equivalent Twenty People field. The companyId link to the parent Company resolves after the Companies migration batch completes, so People are imported in step two of the sequence.

Bright

Company

maps to

Twenty CRM

Company

1:1
Fully supported

Bright companies map to Twenty CRM's Companies object. Company name, domain/website, industry, employee count, and annual revenue transfer as standard fields. Industry pick-list values require value-by-value mapping against Twenty's allowed values. Parent-company hierarchies in Bright map to Twenty's parentId field on the Company record — the parent must land in Twenty first, which our migration sequence ensures.

Bright

Deal

maps to

Twenty CRM

Opportunity

1:1
Fully supported

Bright deals become Twenty CRM Opportunities. The deal name maps to Opportunity.name, amount maps to amount, close date maps to closedAt, and stage maps to the stage pick-list. The stage pick-list in Twenty must be pre-populated with Bright's stage names before the migration runs — we deliver the required stage values as part of the schema setup plan before data lands.

Bright

Task

maps to

Twenty CRM

Task

1:1
Fully supported

Bright tasks migrate as Twenty CRM Tasks. Each task links to its parent record (Person, Company, or Opportunity) via the relationId field. The task body, due date, assignee (matched by email to Twenty users), and completion status all transfer. Completed tasks from Bright retain their completedAt timestamp as a custom field since Twenty's built-in status does not preserve the exact completion datetime.

Bright

Note

maps to

Twenty CRM

Note

1:1
Fully supported

Bright notes migrate to Twenty CRM's Notes object. Note title, body text, and rich-text content transfer directly. Notes in Twenty can be attached to Person, Company, or Opportunity records — we map the Bright note's parent record reference to the correct relationId and objectName in Twenty during the import.

Bright

Activity (Call)

maps to

Twenty CRM

Task

1:1
Fully supported

Bright call activity logs — recorded calls with subject, duration, outcome, and notes — migrate as Twenty CRM Tasks with type set to 'Call'. The call outcome maps to a custom pick-list field on the Twenty Task since Twenty's standard task model does not include an outcome field. Owner and timestamp are preserved from the Bright activity record.

Bright

Activity (Meeting)

maps to

Twenty CRM

Event

1:1
Fully supported

Bright meeting records — title, description, start time, end time, and attendees — map to Twenty CRM Events. The Event links to its parent Person or Opportunity via relationId. Meeting notes from Bright transfer as the Event description field. We preserve original start and end timestamps since these drive calendar views in Twenty.

Bright

Activity (Email)

maps to

Twenty CRM

Task

1:1
Fully supported

Bright email activity logs — subject, body, timestamp, direction (sent/received), and recipient — migrate as Twenty CRM Tasks with type set to 'Email'. The email body and subject transfer to the task body and title fields. We create a custom 'EmailDirection' pick-list on the Twenty Task to preserve whether the email was sent from or received into Bright.

Bright

Custom Object

maps to

Twenty CRM

Custom Object

1:1
Fully supported

Bright custom objects map 1:1 to Twenty CRM custom objects. If Bright has a custom object named 'Project' or 'Subscription', we create the equivalent custom object in Twenty with matching field types before the migration. Custom object relationships in Bright that use N:N associations require a junction object in Twenty — we identify these during the planning phase and include them in the schema setup plan.

Bright

Custom Field

maps to

Twenty CRM

Custom Field

1:1
Fully supported

Every Bright custom field — whether on People, Companies, Deals, or custom objects — creates a corresponding custom field in Twenty CRM. Field type mapping is type-aware: Bright text fields become Twenty TEXT fields, pick-lists map to Twenty SELECT fields with the same options, date fields map to Twenty DATE fields, and number fields map to NUMBER. We do not charge extra for custom field creation since Twenty includes unlimited custom fields on all tiers.

Bright

Owner / User

maps to

Twenty CRM

Workspace Member

1:1
Fully supported

Bright owner assignments on records map to Twenty CRM Workspace Members. We match Bright owner email addresses to Twenty user accounts by email. Any Bright owners who do not have a corresponding Twenty user are flagged before migration — the team either creates the Twenty user first or assigns those records to a fallback owner. No record lands in Twenty without a resolved owner.

Bright

Attachment / File

maps to

Twenty CRM

Not migratable via CSV

1:1
Fully supported

Bright file attachments on any record type do not transfer via Twenty's CSV import tool. Files must be exported from Bright separately (via API or manual download), then uploaded to Twenty via the API or manually. After upload, each file must be re-linked to its parent record. This step is scoped separately from the core data migration because it involves file handling outside the structured data pipeline.

Bright

Workflow / Automation

maps to

Twenty CRM

Workflow

1:1
Fully supported

Bright workflows — automations triggered by field changes, date conditions, form submissions, or API events — have no equivalent in Twenty CRM's workflow engine. We export Bright workflow definitions as a structured reference document (JSON or markdown) so your team can rebuild them in Twenty's workflow builder. The reference document maps each Bright trigger to Twenty's trigger types and each Bright action to the corresponding Twenty action.

Bright

Integration / Connection

maps to

Twenty CRM

Integration

1:1
Fully supported

Bright integrations with third-party tools — email providers, calendar systems, telephony platforms, or data enrichment services — do not transfer. Each connection must be re-established in Twenty CRM using Twenty's API, webhooks, or available integrations. We document every active Bright integration during the audit phase so your team has a complete rebuild checklist before go-live.

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.

Bright logo

Bright gotchas

Medium

CIS deduction rates are employee-specific and must transfer as discrete fields

High

No bulk document export API forces manual file downloads

Low

Leave entitlement balances require separate export alongside the request history

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

  • Twenty's import order constraint can orphan records if companies are not migrated first

    Twenty CRM's documentation explicitly requires that Companies be imported before People, and People before Opportunities — because the 'one' side of every relationship must exist before the 'many' side can reference it via foreign key. If you migrate Bright People before Companies, the companyId field on every Person record resolves to null in Twenty, producing a workspace full of contacts with no associated company. FlitStack AI sequences the migration: Companies first, then People with resolved companyId links, then Opportunities with both companyId and personId links. We surface the required import order in the pre-migration schema plan and validate that the sequence was followed before declaring the migration complete.

  • Twenty's CSV import caps exports at 20,000 records per file — larger datasets require batching

    Twenty CRM's built-in CSV export tool limits output to 20,000 records per file. For Bright workspaces with more than 20,000 total records — or more than 20,000 people alone — you cannot retrieve all records in a single CSV export. FlitStack AI handles this by either using Bright's API directly for large exports (bypassing the CSV limit entirely) or by splitting the export into multiple batches per object, maintaining the correct import sequence across batches. We identify the batch split points during the planning phase so the migration plan accounts for multiple import passes rather than one monolithic load.

  • File attachments do not migrate through Twenty's CSV import — they must be re-uploaded

    Twenty CRM's CSV import tool handles structured CRM records only — it does not transfer file attachments. Any files attached to Bright records (documents, images, or other attachments) are excluded from the CSV export and must be handled as a separate step. FlitStack AI exports attachments from Bright via API, re-uploads them to Twenty via the API or manually, and re-links each file to its parent record (Person, Company, or Opportunity). This step requires your team to verify the links in Twenty's UI after the core data migration lands. We scope this separately from the record migration because it involves binary file handling outside the structured data pipeline.

  • Workflows and automations must be rebuilt — they do not transfer between platforms

    Bright workflows — automations triggered by field changes, date conditions, form submissions, or record creation events — are platform-specific and do not transfer to Twenty CRM's workflow engine. The logic that triggers a Bright automation has no direct equivalent in Twenty's workflow builder, which uses its own trigger-action model. We export Bright workflow definitions as a structured reference document so your team can map each Bright trigger and action to Twenty's workflow triggers (record creation, record update, date-based) and actions (create record, send email, update field). This reference document is included in the migration package at no additional charge. The actual rebuilding work in Twenty's workflow builder is a manual step your team performs post-migration.

  • Owner assignment by email match can leave records unowned if Twenty users are not set up first

    FlitStack AI resolves Bright owner IDs by matching them against Twenty Workspace Members using email addresses. Any Bright owner whose email does not correspond to an invited Twenty user is flagged before migration. If your Bright workspace has owners who are not yet invited to Twenty, their records will be assigned to a fallback owner (or flagged for manual review) unless your team creates the Twenty user first. We deliver a pre-migration checklist that lists every unique Bright owner email, shows whether each has a corresponding Twenty account, and specifies which records will need a fallback assignment if the Twenty account is not created before the migration runs.

Migration approach

Six steps for a successful Bright to Twenty CRM data migration

  1. Audit Bright data and map the schema

    FlitStack AI inventories every Bright object, counts records by type, and documents all custom fields with their data types and usage frequency. We identify which Bright objects have relationships to other objects (People linked to Companies, Deals linked to both) and document the relationship cardinality. We also export Bright workflow definitions as a rebuild reference and list every active integration. This audit produces the schema setup plan that tells your team which Twenty custom fields, custom objects, and stage values to create before data arrives. We deliver this plan within the first week of engagement.

  2. Set up Twenty CRM workspace schema

    Your team (or our team) creates the Twenty CRM custom fields, custom objects, and opportunity stage values identified in the audit. Because Twenty includes unlimited custom fields on all tiers, there is no tier-gate preventing us from creating every field Bright uses. We provide a field-creation checklist with exact names, types, and pick-list values so the workspace is ready before we begin validation. Owner email matching against Twenty Workspace Members also happens here — we provide the list of required Twenty users so your team can invite them before migration.

  3. Resolve owners and validate record counts

    We match Bright owner IDs to Twenty Workspace Members by email. Unmatched owners are flagged and assigned to a fallback owner, or held for your team to create the corresponding Twenty account. We validate total record counts in Bright per object to confirm the migration scope and identify any objects approaching Twenty's 20,000-record CSV export limit, which triggers API-based export routing instead of CSV. This step runs concurrently with schema setup and produces a final migration scope document.

  4. Run a sample migration with field-level diff

    A representative slice — typically 100 to 500 records spanning People, Companies, Deals, Tasks, and Notes — migrates first. We generate a field-level diff comparing source Bright values to destination Twenty values so you can verify that pick-list mappings, date formats, owner assignments, and relationship links (companyId on People, personId on Opportunities) resolved correctly. You review the diff and approve before the full migration commits. Any incorrect mappings are corrected in the migration plan before the next step.

  5. Run full migration with delta pickup

    The full migration executes using the approved mapping plan, with Companies imported first, then People, then Opportunities, then custom objects. We use Twenty's API for datasets exceeding 20,000 records or for imports requiring precise relationship ordering. A delta-pickup window — typically 24 to 48 hours after the main import completes — captures any records modified in Bright during the cutover. FlitStack AI uses scoped read access on Bright throughout, meaning your team continues working in Bright uninterrupted. One-click rollback is available if post-migration reconciliation reveals data quality issues.

Platform deep dives

Context on both ends of the pair

Bright logo

Bright

Source

Strengths

  • Integrated RTI payroll submissions for UK construction companies under the CIS scheme
  • Clock-in and timesheet tracking with leave management in a single platform
  • CIS verification and deduction calculation built directly into the payroll workflow
  • Support team rated highly in G2 reviews for setup and query resolution

Weaknesses

  • Document storage interface lacks the polish of dedicated document management tools
  • Reporting flexibility is limited compared to standalone payroll systems
  • Pricing and tier structure is not publicly documented in a standard pricing page
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 Bright 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

    Bright: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

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

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

Can't find your answer?

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

Book a free 30 minute consultation

Most Bright-to-Twenty migrations complete within 2–4 weeks end-to-end for under 25,000 total records, including planning, schema setup, sample migration, and delta pickup. The planning and schema setup phase typically runs 5–10 business days. The longest single step is validating pick-list value mappings and ensuring the correct import sequence (Companies before People before Opportunities) is respected. Datasets over 25,000 records, or Bright workspaces with heavy custom object usage, extend the timeline to 6–10 weeks.

Adjacent paths

Related migrations to explore

Ready when you are

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