CRM migration

Migrate from Zuper to Twenty CRM

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

Zuper logo

Zuper

Source

Twenty CRM

Destination

Twenty CRM logo

Compatibility

100%

11 of 11

objects map 1:1 between Zuper and Twenty CRM.

Complexity

BStandard

Timeline

48–72 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Zuper is a field-service management platform built around Jobs, Customers, Locations, and Teams — its data model reflects an operations-first worldview where records track service visits, work orders, and field-technician assignments. Twenty CRM is a modern open-source CRM built around People, Companies, Opportunities, Notes, and Tasks with a PostgreSQL-backed data model and a custom-field system under Settings → Data Model. The migration requires mapping Zuper's job-ticket paradigm (status, priority, scheduled date, assigned technician) into Twenty's Opportunity records with supplementary custom fields for service-type specifics. We map Zuper Customers to Twenty People (contact-level) and Locations to Twenty Companies (account-level), preserving service addresses as address fields on the company record. Custom fields defined in Zuper get recreated as Twenty custom fields before import. Zuper teams and technicians resolve to Twenty workspace members by email match. Because Zuper has no native opportunity object, the Job-to-Opportunity mapping is a transformed translation — the job's lifecycle stage becomes the opportunity stage, and the assigned technician becomes the opportunity owner. Workflows, job automations, and guided workflows do not migrate and must be rebuilt in Twenty's workflow builder. The migration uses Zuper's REST API for record extraction and Twenty's CSV import with API upsert for large datasets, followed by a 24–48 hour delta pickup window.

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

Zuper logo

Zuper

What's pushing teams away

  • The estimate platform has limited functionality compared to dedicated quoting tools, and customers report it is inferior to most competing products in the FSM space.
  • Zuper is a newer product still in active development — some features customers need are not yet available, causing delays for teams with specific requirements.
  • The mobile app has stability issues including crashes mid-task, disappearing data during input, and excessive clicking to complete simple actions.
  • Leadership commitments have been missed repeatedly according to at least one mid-market reviewer, creating frustration around roadmap reliability.
  • Limited reporting depth makes it hard to extract actionable operational insights without exporting to a third-party BI tool.

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

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

Zuper

Customer

maps to

Twenty CRM

People

1:1
Fully supported

Zuper Customers (individuals requesting service) map directly to Twenty People records. Each customer's name, email, phone, and address fields transfer as standard People fields. The customer's primary location address is preserved as supplementary address data on the related Company record.

Zuper

Location

maps to

Twenty CRM

Company

1:1
Fully supported

Zuper Locations (service addresses linked to customers) map to Twenty Company records. A Zuper customer with multiple locations generates multiple Company records in Twenty — each with its own address, industry classification, and linked People records for on-site contacts at that location.

Zuper

Job

maps to

Twenty CRM

Opportunity

1:1
Fully supported

Zuper Jobs are the primary migrated record. Each Job becomes a Twenty Opportunity linked to the target Company (the service location). Job status (Pending/In Progress/Completed) maps to Opportunity Stage values using a configured value-mapping table. Job scheduled date maps to Opportunity Expected Close Date for work-order tracking.

Zuper

Job Status

maps to

Twenty CRM

Opportunity Stage

1:1
Fully supported

Zuper's four-tier job status (Pending, In Progress, Completed, Cancelled) maps to a simplified Four-Stage sales pipeline in Twenty: Appointment Scheduled → Work In Progress → Closed Won (for Completed) or Closed Lost (for Cancelled). Stage probability is assigned per stage value.

Zuper

Job Priority

maps to

Twenty CRM

Custom field: Job_Priority__c

1:1
Fully supported

Zuper job priority levels (Low, Medium, High, Urgent) have no native equivalent field type in Twenty CRM's standard Opportunity object. We create a custom select field named Job_Priority__c on the Opportunity object under Settings → Data Model to preserve priority ordering and maintain visibility into service-level agreements. Priority values are mapped verbatim from Zuper's pick-list options during the migration.

Zuper

Job Category

maps to

Twenty CRM

Custom field: Service_Type__c

1:1
Fully supported

Zuper job categories (HVAC, Plumbing, Electrical, etc.) from the Job Category Hub have no native CRM equivalent in Twenty. A custom select field on Opportunity captures the service category. Category values are mapped from Zuper's category names to Twenty pick-list options.

Zuper

Team / Technician

maps to

Twenty CRM

WorkspaceMember (Owner)

1:1
Fully supported

Zuper Teams and individual Technicians are resolved by email to Twenty Workspace Members. A Team in Zuper becomes a Group of individual member links in Twenty. Unresolved technicians (no matching email) are flagged and assigned to a fallback workspace member or held for manual assignment.

Zuper

Timesheet / Timelog

maps to

Twenty CRM

Custom object: Timesheet

1:1
Fully supported

Zuper Timesheets and Timelog entries (hours logged per technician per job) are translated into a custom Timesheet object in Twenty linked to the Opportunity (Job) and the WorkspaceMember (Technician). This preserves labor history without forcing it into a standard CRM object.

Zuper

Job Notes

maps to

Twenty CRM

Note

1:1
Fully supported

Zuper job notes and internal comments migrate as Twenty Note records attached to the corresponding Opportunity (Job). Original timestamps and author attribution are preserved. Notes with attachments (photos, signed forms) are flagged for manual re-upload since CSV import does not carry binary file references.

Zuper

Job Attachments / Photos

maps to

Twenty CRM

Manual re-upload required

1:1
Fully supported

Zuper job attachments (before/after photos, signed forms, compliance documents) are not included in standard CSV exports. We export the attachment list and metadata, then re-upload via Twenty's API or manual file attach. This step is documented in the migration checklist and can be parallelized with the data migration.

Zuper

Custom Field (per module)

maps to

Twenty CRM

Custom Field (per object)

1:1
Fully supported

Every Zuper custom field (created per module via Settings → Custom Fields) is audited and recreated in Twenty under Settings → Data Model before the main import. Custom field type mapping: Zuper text → Twenty text, Zuper number → Twenty number, Zuper date → Twenty date, Zuper select → Twenty select.

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.

Zuper logo

Zuper gotchas

High

No bulk API endpoint means large migrations are sequential

Medium

Quote object schema is shallower than Job schema

High

Workflow Builder automations have no export capability

Medium

Multi-custom-field filter on Properties API returns no records when multiple filters applied

Medium

Mobile app instability causes incomplete Job records in production data

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 CSV import skips binary file attachments

    Zuper job attachments (photos, signed forms, compliance documents, before/after images) are stored as binary files linked to job records. Twenty's CSV import function only moves columnar data — it does not import or relink file attachments. We export the attachment metadata list (file name, URL, linked job ID) as a reference CSV. The actual files must be re-uploaded manually to Twenty or migrated via API call after the Opportunity records are in place. This step adds 1–3 hours of manual effort per 100 attachments and should be scheduled after data validation.

  • Zuper's N:1 customer-to-location model requires address expansion

    Zuper allows one Customer record to have multiple Location records, each with a distinct service address. Twenty CRM's Company object has a single address field. When migrating, each Zuper Location generates a separate Company record in Twenty — even if it belongs to the same Customer. The People record (Customer) links to the primary Company; additional Locations become Company records linked by a custom parent-company field or left as separate accounts. This inflates record counts and requires admin review to decide which Location becomes the primary account for CRM reporting purposes.

  • Twenty requires all referenced users to accept invitations before import

    Twenty's import system enforces referential integrity: if your CSV contains a WorkspaceMember email in an assignee field, that user must have an accepted invitation in Twenty before the import runs. Zuper's teams and technicians may include inactive accounts or email addresses that no longer correspond to active users. We audit all technician and team member emails against Twenty's invited user list before migration. Any unresolved owner references are reassigned to a designated fallback workspace member so the import does not fail. This adds a pre-migration invitation step requiring 1–2 business days for team coordination.

  • Zuper Workflow Builder automations cannot migrate to Twenty workflow builder

    Zuper's Workflow Builder uses a node-based automation model that triggers on job lifecycle events (job created, status changed, technician assigned). Twenty's workflow builder handles CRM-level automations (task creation on opportunity stage change, field updates, notification triggers) — it has no equivalent to Zuper's job-scheduling or technician-dispatch logic. Any scheduling rules, conditional routing, or auto-assignment workflows built in Zuper must be rebuilt in Twenty's workflow builder after migration. We export your Zuper workflow definitions as a structured JSON reference document to accelerate the rebuild. Scheduling logic in particular may need a third-party scheduling tool or a custom integration to replicate.

Migration approach

Six steps for a successful Zuper to Twenty CRM data migration

  1. Audit Zuper data and export via REST API

    FlitStack AI connects to your Zuper account via the REST API to enumerate all modules: Jobs, Customers, Locations, Teams, Timesheets, and custom fields. We extract record counts per object, identify custom field definitions, and map the job status pick-list values. The audit report is shared with you before migration begins — it shows the exact record volumes and custom field inventory that will land in Twenty.

  2. Create Twenty schema: custom fields and custom objects

    Before any data lands, FlitStack creates the custom fields and custom objects needed in Twenty. This includes Job_Priority__c (select), Service_Type__c (select), Scheduled_Start__c (datetime), Scheduled_End__c (datetime), and the Timesheet custom object with its relation to Opportunity and WorkspaceMember. We create these under Settings → Data Model using Twenty's field type conventions, then share the completed schema checklist so your admin can verify before import begins.

  3. Invite and resolve all Zuper technicians and team members

    FlitStack extracts all technician and team member email addresses from Zuper's Teams and Jobs API responses. We cross-reference against Twenty's invited user list and flag any email with no matching Twenty account. Your team sends invitations to those users and waits for acceptance. Unresolved owners are assigned to a designated fallback Twenty WorkspaceMember. No Opportunity record lands in Twenty without a valid assignee reference.

  4. Migrate in sequence: Companies → People → Opportunities → Timesheets

    Following Twenty's import order requirements, we load Companies first (Locations from Zuper), then People (Customers), then Opportunities (Jobs linked to Companies). Each import batch is validated before the next begins. Zuper's job status values are translated to Twenty stage values via the configured value map during the Opportunities import. Custom fields on every record are populated from the Zuper custom field values extracted in Step 1. Timesheet records import last, linked to their parent Opportunities by ID.

  5. Run sample migration with field-level diff and delta pickup

    A representative sample (typically 100–500 records) migrates first. We generate a field-level diff between the Zuper source record and the Twenty destination record so you can verify that job status mapping, priority values, assigned technician resolution, and scheduled date fields are all correct. After sample approval, the full migration runs. Zuper remains fully operational during cutover — a 24–48 hour delta pickup window captures any records modified in Zuper after the initial export. Audit log records every operation, and one-click rollback is available if reconciliation identifies issues.

Platform deep dives

Context on both ends of the pair

Zuper logo

Zuper

Source

Strengths

  • Offline-first mobile app allows technicians to work without connectivity and sync when back online.
  • Intelligent dispatching and smart scheduling reduce manual job assignment overhead.
  • Embedded digital payment processing shortens invoice-to-payment cycles.
  • Configurable workflow builder lets admins adapt the platform to trade-specific processes.
  • Custom fields on Customers and Jobs provide trade-specific data capture without developer involvement.

Weaknesses

  • The estimate and quoting module is widely reported as underdeveloped with limited functionality.
  • The mobile app suffers from instability including crashes and data loss during input tasks.
  • Zuper is still actively developing features, which can cause delays for teams needing specific capabilities.
  • API lacks a bulk import endpoint, making large-volume data migrations slower and more rate-limit sensitive.
  • Workflow definitions cannot be exported — every automation must be manually rebuilt at the destination.
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 Zuper 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

    Zuper: Not publicly documented in current developer documentation.

  • Data volume sensitivity

    B

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

Estimator

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

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

Can't find your answer?

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

Book a free 30 minute consultation

Most Zuper-to-Twenty migrations complete in 48–72 hours of clock time for under 50,000 records. The longest planning step is the pre-migration schema setup — creating custom fields and the Timesheet object in Twenty — which takes 1–2 days. Larger setups with 50,000+ records or multiple locations per customer extend the timeline to 5–10 days. Zuper's API export speed and the number of custom fields are the primary timeline variables.

Adjacent paths

Related migrations to explore

Ready when you are

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