Migrate from Regal.io to Twenty CRM

Regal Contacts map to Twenty People records. The primary identifier is the contact's phone number or email; we use email as the dedupe key where available. Custom attributes on the Regal Contact (tenant-specific profile fields) migrate as Twenty custom fields that we pre-create in Settings > Data Model before import. Any Contact record missing both a phone number and email is flagged as a partial record and held in a reconciliation queue because Twenty People do not require phone numbers but your team may want to review incomplete records before they enter the CRM.

Regal Company records (if present in the source export) map to Twenty Company records with a 1:1 field mapping. The Company domain becomes the Website field and serves as the dedupe key. If the source export contains only Contacts without a standalone Company object, we derive Company records from domain-matching logic on People email addresses, creating or linking to the corresponding Company record during migration.

Regal Campaigns define outbound programs with list selection, cadence, and goal metrics. We map Campaign membership (the list of Contacts targeted) to a set of Opportunity records linked to the target People, with Campaign name and goal metrics stored in custom Opportunity fields. If the customer has a pipeline concept, each Campaign becomes a distinct Opportunity stage group rather than a flat list, preserving the program-level view.

Behavioral Events are the core of Regal's data model. Each Event has a type, timestamp, properties, and an associated Contact. We export the full event history and transform each Event into a Twenty Task (for call, email, and meeting outcomes) or a Note (for custom event types and Journey trigger records). The original Event type is preserved in a custom field event_type__c so that the behavioral timeline is queryable in Twenty. Event timestamps map to the Task ActivityDate to maintain chronological ordering in the activity feed.

Regal's Contact Attributes are tenant-specific custom profile fields stored on Contacts. We extract the full attribute schema from Regal's API before migration, identify the field types (text, number, date, boolean, select), and pre-create matching custom fields in Twenty's Settings > Data Model under the People or Company object as appropriate. Select and multi-select attributes map to Twenty's select and multi-select field types with the same option values preserved.

Regal Custom Objects are defined by Custom Event schemas with a traits/properties split (traits update Contact; properties update the Object instance) and a unique identifier property. We extract all Custom Object instances, resolve the linking Contact reference, and create matching Custom Objects in Twenty with the same field names and types. The unique identifier property from Regal becomes a custom ID field in Twenty. Multiple Regal events can update a single Object instance, and we consolidate those updates into the latest state of the custom Object record.

Regal Journeys are conditional, event-triggered sequences of voice, SMS, and email steps defined in the no-code Journey builder. We do not migrate Journeys as executable logic because Regal's Journey runtime is not exportable. Instead, we document every active Journey as a step-by-step conditional rule inventory: trigger event, condition branches, action steps, and goal metrics. This document serves as the blueprint for rebuilding equivalent logic in Twenty's workflow system post-migration.

Call transcripts from Regal are exported as structured text and attached to the corresponding People record in Twenty as a Note with a custom transcript__c field. The Note title carries the call timestamp and duration. If the customer requires audio file preservation, we note that audio availability depends on Regal's retention settings at the time of export; audio files themselves are not directly importable into Twenty without a custom storage integration.

SMS and email conversational history associated with Contacts is extracted as thread-level data and reattached to the corresponding People record in Twenty as a Note. Thread continuity in the destination system cannot be guaranteed because Twenty's activity model is task-based rather than thread-native; we preserve the message content and timestamp but note that the conversation UI will differ from Regal's thread view.

Regal AI Agent configurations — voice scripts, decision trees, persona settings — are tied to Regal's proprietary agent runtime and are not exportable via API or UI. We explicitly exclude Agent logic from the migration scope and flag it for manual rebuild. We do migrate the conversation outcome data and Journey trigger conditions so that business context is preserved. The written Journey inventory (see above) serves as the functional spec for recreating equivalent logic in Twenty's workflow system.