Migrate from Rizer to Twenty CRM

Rizer Contact records map to Twenty People with standard fields (name, email, phone, address) preserved. Referral attribution source and attribution window fields from Rizer migrate as custom fields on People (e.g., referral_source__c, attribution_window_days__c). Rizer's lifecycle_stage property migrates as a custom picklist field if the customer relies on it for segmentation. We inspect raw field values during export because Rizer's Referrizer API does not enforce type constraints on read; date fields stored as strings and multi-select values stored as delimited text are normalized before write.

Rizer Companies map directly to Twenty Companies. The Rizer company association on Contact (the link between a Contact and their employer) resolves to a Twenty Company record before Contact import so that the relationship is satisfied at the moment of People insert. Industry tags and custom company properties become custom fields on the Twenty Company object.

Rizer Deals map to Twenty Opportunities. The Rizer dealstage property maps to a Twenty pipeline stage, which we configure in Settings before migration. Pipeline assignments in Rizer become Twenty Opportunity pipeline names. Closed-Won and Closed-Lost amounts, probability, and expected close date transfer to standard Opportunity fields. Deal custom properties (beyond the standard stage and amount fields) migrate as custom fields on Opportunity.

Rizer Workflows are automated email sequences attached to Contact lifecycle stages with branching logic and delay rules. Twenty does not have a native sequence or workflow automation feature equivalent to Rizer's contact-nurture sequences. We do not migrate Workflows as code. We deliver a written inventory of every active Rizer Workflow documenting its trigger condition (e.g., callback_date reached, lifecycle_stage transitioned), delay rules, email content reference, and tagging actions. The customer's admin rebuilds these in a tool of their choice (Twilio Segment, ConvertKit, ActiveCampaign, or a custom n8n workflow) post-migration.

Rizer tags applied to Contacts are flat string lists. We normalize these to a Twenty custom multi-select picklist field (tags__c) on People during migration. If the customer uses tags for content classification or campaign segmentation, we offer a Topics-based alternative where each Rizer tag becomes a Twenty Topic with TopicAssignment records. The customer selects the tag strategy during scoping.

Rizer Referrizer API custom field descriptors on Contacts migrate to Twenty People custom fields. We inspect raw values during export to infer data type because the Rizer API returns field metadata without enforcing type constraints. Date fields stored as strings, numeric fields stored as text, and delimited multi-select values are all normalized before write. Custom fields must exist in Twenty's Settings → Data Model before import; we create them during the pre-migration data model step.

Referral tracking sources and attribution windows stored on Rizer Contact records migrate as custom fields on Twenty People. The referral_source__c field carries the attribution channel (e.g., creator_mention, affiliate_link, social_post). The attribution_window_days__c field carries the configured conversion window. Attribution history spanning multiple fields becomes a JSON blob in a long-text field or individual fields per the customer's data model preference. Referral click counts and conversion counts migrate as numeric custom fields if present.

Rize Clients (from the separate time-tracking product at rize.io) map to Twenty Companies. This is a separate export scope from Rizer Social because the two products have separate login domains and no unified API. Clients from Rize include the client name and contact details; we treat them as company-level records in Twenty. Projects belonging to a Client link to the Company via a custom lookup field.

Rize Projects belong to Clients and contain Tasks. Twenty does not have a native Project object, so we evaluate one of two approaches during scoping: flatten Projects into Twenty Opportunities with a custom project_name__c field, or create a custom Project object in Twenty's data model. The choice depends on whether the customer wants time-tracking integration post-migration or just needs project context preserved as a label on records.

Rize Tasks nested under Projects do not have a direct Twenty equivalent. Subtasks in Rize are a boolean or count field on a Task, not a separate object. We expand these into discrete Task records in Twenty if the standard Task object is sufficient, or into a custom Task object if the customer needs hierarchical project-task relationships. Rize time-tracking data is scoped separately from the Rizer Social migration because these are separate products.

Rizer user accounts map to Twenty Members. Role assignments (admin, manager, member) in Rizer map to Twenty's role-based access control settings. We resolve by email match. Any Rizer user without a matching Twenty Member invitation is held in a reconciliation queue for the customer's admin to provision before record import resumes. Rizer Social and Rize have separate user management; if both products are in scope, we handle member mapping twice.