Migrate from Regal.io to Salesforce Sales Cloud

Regal Contacts with no Opportunity association and no sales-qualified event history map to Salesforce Lead. Contacts with an active Campaign membership, sales event history, or a mapped Opportunity in Regal's data export map to Salesforce Contact attached to an Account. We compute the split using Regal's contact_status, campaign_membership, and last_event_type properties during the transform phase. The original Regal contact ID is preserved in regalid__c on both Lead and Contact for cross-system audit.

Regal's custom contact profile fields (tenant-specific attributes beyond phone, email, and name) map to Salesforce standard fields if the field names align (Title, Department, Address) and to custom fields (AttributeName__c) for tenant-specific schema. We extract the full Regal attribute schema via the API before migration and pre-create the corresponding Salesforce custom fields in a Sandbox validation before production import.

Regal Events (behavioral records with type, timestamp, and properties) have no direct Salesforce equivalent. We map each Event type to a Salesforce custom field on Contact (event_type__c, event_timestamp__c, event_properties__c as JSON) or to a Task record with TaskSubtype set to LoggedEvent and the WhoId pointing to the Contact. The mapping choice is made per event type during scoping: high-cardinality event types (opens, page views) become custom fields; meaningful interaction events (calls, meetings, stage changes) become Task records with subject and description preserved.

Regal Campaigns define outbound programs with list selection, cadence, and goal metrics. We map Campaign records to Salesforce Campaign, preserving campaign name, goal metrics, and list size. Campaign membership (which Contacts were in which Campaign) migrates as Salesforce CampaignMember records linked to the Campaign and the Contact. Cadence and list-refresh logic is platform-specific and documented for manual rebuild in Salesforce Campaigns or Sales Engagement.

Regal Journeys are event-triggered workflows with conditional branching across voice, SMS, and email steps. We do not migrate Journeys as automation code. Instead, we produce a step-by-step conditional rule document for each active Journey: trigger event, step sequence, condition branches, and action types. This document is handed to the customer's admin or a Salesforce partner to rebuild in Flow or Salesforce Sales Engagement. The Journey handoff document is scoped separately and delivered before production cutover.

Regal AI Agent configurations (voice scripts, decision trees, persona settings, handoff logic) are tied to Regal's proprietary agent runtime and cannot be downloaded via API or UI. We explicitly exclude Agent logic from migration scope. We do migrate the Agent outcome data (conversation disposition, transfer reason, containment flag) as custom fields on Contact or Task so that the business context survives even if the agent logic must be rebuilt from scratch at the destination.

Call recordings in Regal's media storage are exported as audio files. We import them into Salesforce as ContentVersion records and link them to the Contact via ContentDocumentLink. File availability depends on Regal's retention settings at the time of export; we verify recording access during discovery and flag any gaps in the migration scope letter. Salesforce storage limits (5 GB per user on Professional) apply and are accounted for during capacity planning.

Call transcripts migrate as Salesforce Task records with TaskSubtype = Call, the original transcript body stored in a custom Long Text Area field (call_transcript__c), and call disposition stored in a custom picklist (call_disposition__c). Activity timeline ordering is preserved by setting ActivityDate to the original Regal event timestamp.

SMS conversational history is extracted from Regal as thread-level data (direction, timestamp, message body). We migrate each SMS as a Task record with TaskSubtype = SMS, Subject = 'SMS: [Contact Name]', and the message body stored in a custom Long Text Area field (sms_body__c). Thread continuity in Salesforce is preserved by setting the RelatedToId (WhatId) to the Contact and ordering by ActivityDate.

Email threads associated with Regal Contacts migrate to Salesforce EmailMessage records (the message content) linked to a Task record (the activity timeline entry). The WhoId on Task points to the migrated Lead or Contact; message direction (sent/received), timestamp, and subject line are preserved. Email attachments migrate as ContentDocument records linked to the EmailMessage.

Regal Custom Objects (Growth and Enterprise tiers) store complex customer data outside the standard Contact attribute schema. We map each Regal Custom Object to a Salesforce custom object of the same API name (with __c suffix). Lookup relationships from Custom Objects to Contact are preserved as External ID fields in Salesforce. We pre-create the destination schema in a Sandbox before production migration, including all custom fields, picklist values, and validation rules.

Regal's branded caller ID (CNAM) configuration is tied to carrier registration and domain ownership records at Regal's telephony provider. We export the CNAM registration details, carrier agreements, and campaign-level caller ID assignments as a documented handoff for re-registration at the customer's new telephony provider. Salesforce does not natively manage CNAM; this is a telephony setup task outside Salesforce's CRM scope.

Regal's live integrations with Segment, HubSpot, Braze, Iterable, and other platforms define which contacts are synced and how. We document every active Regal integration endpoint, sync direction, and field mapping as part of the migration scope letter. Post-migration, the customer re-establishes integrations pointing to Salesforce instead of Regal. We provide the integration configuration checklist but do not rebuild the integrations themselves.

Regal's Salesforce sync creates Opportunities that reference Salesforce Opportunity IDs. If the migration source Regal instance had a bidirectional Salesforce sync active, those Opportunities may already exist in the destination Salesforce org. We deduplicate by Salesforce Opportunity ID where present, and import any Regal-originated Opportunity data that has no matching Salesforce record as a new Opportunity with the regal_opportunity_id__c external ID field for reconciliation.