Migrate from Rezora to Twenty CRM

Rezora contacts migrate directly to Twenty People records. Each Rezora contact maps to one People record; the original Rezora contact ID is stored as Source_System_ID__c for traceability and delta-run de-duplication. Emails, phone numbers, job titles, and addresses transfer as standard People fields.

Rezora custom properties on contacts (e.g., lead_source, license_number, preferred_contact_method) create Twenty custom fields on the People object via Twenty's Metadata API before the migration run. Field type is preserved: text properties become text fields, pick-lists become select fields, date properties become date fields.

Rezora companies (brokerages, teams, or office entities) map directly to Twenty Companies records. Company name, domain/website, industry, number of employees, and annual revenue transfer to matching Twenty fields. Multi-office brokerages with parent-branch hierarchies require decisions about whether to create separate Company records per office or consolidate under one primary brokerage record.

Rezora company-level custom fields (e.g., mls_id, brokerage_license, market_region) migrate as Twenty Company custom fields. The Metadata API creates each field first, then field values load during the Company import phase. Original create dates are preserved as custom datetime fields since Twenty's CreatedAt is set at migration time.

Rezora campaigns have no direct equivalent in Twenty's standard schema. FlitStack exports campaign names, types, statuses, and member counts as a CSV reference file. Teams rebuild campaigns as custom objects in Twenty (Organization plan) or document them in a Campaign Notes record linked to relevant People records. Campaign membership (which contacts received which campaigns) is preserved as a custom field on People.

Rezora drip campaigns and email sequences are marketing automation constructs with step timing, condition branches, and enrollment rules. Twenty's workflow builder handles task automation but does not natively replicate drip campaign logic. FlitStack exports drip campaign definitions as JSON and CSV reference files so your Twenty admin can rebuild them as workflows. The exported file includes step order, wait durations, and enrollment criteria.

Rezora email templates (HTML content used in drip campaigns) have no storage location in Twenty's standard schema. FlitStack exports template HTML as files. Teams can store template body as a long-text custom field on a Campaign reference record, or re-create templates in an external email tool (e.g., Mailchimp, SendGrid) and integrate via Twenty's webhooks.

Rezora tracks email engagement metrics (opens, clicks, template views) per contact. Twenty does not store engagement metrics as activity records — it tracks only calls, meetings, and notes. Engagement history cannot migrate to Twenty and is exported as a reference CSV for compliance or reporting purposes outside the CRM.

Rezora's social media scheduling and posting features have no direct equivalent in Twenty. Social post records can be exported as a CSV with post text, platform, and date. Teams rebuild posting workflows in dedicated social media tools (e.g., Buffer, Hootsuite) and link those tools to Twenty via webhook or Zapier integration post-migration.

Rezora agents are contacts with an agent-specific role. In Twenty, the contact data migrates to a People record. If the agent also needs to log into Twenty as a user, their email address is used to create a WorkspaceMember invitation — but agents who are only managed contacts (not users) land only as People records. FlitStack flags contacts that have matching email invitations in Twenty before assigning WorkspaceMember roles.

Rezora file attachments on contacts or templates are not included in CSV exports. FlitStack exports a manifest of attachment URLs and file names. Teams re-upload files to Twenty manually, or FlitStack's API team handles re-upload to Twenty's file storage. This step is scoped separately from the record migration because file transfer requires destination storage credentials.