Migrate from Fans-CRM to Salesforce Sales Cloud

Fans-CRM Fan and Subscriber records map to Salesforce Contact with custom fields for engagement_score, subscription_status, lapse_date, and reengagement_campaign_flag. The Fans-CRM fan identifier becomes an external ID field (fans_crm_id__c) for deduplication and future sync. Subscription tier name migrates to a custom picklist field fan_tier__c. The subscriber lifecycle stage from Fans-CRM (active, paused, lapsed, churned) maps to a custom Contact field for retention reporting.

Fans-CRM Subscription Tiers (names, pricing, fan counts per tier) do not map to a standard Salesforce object. We create a fan_tier__c picklist on Contact and a companion fan_tier_price__c number field storing the tier price at the time of migration. Tier change history migrates as a custom object FanTierChange__c with the old tier, new tier, and change date for reporting on tier migration patterns.

Pay-per-view transactions (amount, fan identifier, timestamp, content post reference, PPV type) have no standard Salesforce equivalent and migrate to a PPVTransaction__c custom object. The fan identifier resolves to a Contact lookup at migration time. Content post reference becomes a lookup to FanContent__c (created separately). PPV amount migrates as a currency field; the historical timestamp preserves as ActivityDate for engagement reporting. We chunk PPV imports into Bulk API batches of 10,000 records to respect Salesforce governor limits.

Fans-CRM Content Posts (media references, PPV pricing, post date, content type, visibility setting) migrate to FanContent__c as a custom object. Media URLs or filenames store in a custom field as references rather than binary blob transfer. PPV pricing and content type (photo, video, message, locked post) migrate as custom fields. Performance metadata (views, likes, purchases) becomes a custom numeric field set. FanContent__c is parent to PPVTransaction__c via a lookup relationship we create before PPV import begins.

Fan-level engagement scores, chatter metrics, response rates, and message volume from Fans-CRM migrate as custom numeric fields on the Contact record (engagement_score__c, messages_sent__c, messages_received__c, avg_response_time_hours__c). These values represent a snapshot at migration time and do not carry historical time-series data unless Fans-CRM export includes a metrics history export that we can load into a separate FanEngagementHistory__c custom object.

Fans-CRM agency team members map to Salesforce User records by email match. Role assignments (Admin, Manager, Agent) from Fans-CRM become Salesforce Profiles and Permission Sets that we configure during schema design. We reconcile team members against the destination Salesforce org's active User licenses; any Fans-CRM team member without a Salesforce User goes to a license reconciliation queue for the customer to resolve before record migration proceeds.

Fans-CRM Smart Folder structures and tags do not have a native Salesforce equivalent. We export the underlying tag data and fan-tag associations and reconstruct them in Salesforce using the Topic model. Tags used for fan segmentation become Topic records with TopicAssignment linking fans to segments. Tags used for content organization associate with FanContent__c records. The customer selects the tag strategy during scoping: content-focused tags as Topics, fan-segment tags as a custom multi-select picklist on Contact.

Fans-CRM Chat Assistant, bulk message templates, and automated reply rules are platform-native automation logic tied to the Fans-CRM interface and its OnlyFans session management. These do not transfer to Salesforce because Salesforce uses a different automation model (Flow) and different data structures. We document the template names, trigger conditions, and message content during discovery so the customer's admin can rebuild them as Salesforce Flow Templates or as Salesforce Content records with a manual usage guide.

Fans-CRM bulk message send history and individual chat message threads migrate to Salesforce as Task records (with TaskSubtype = Task for general messaging) and EmailMessage records for threads that include email-type communication. Chat message content migrates as Task Description or as ContentDocumentNote attachments. The fan Contact lookup resolves at migration time using the fans_crm_id__c external ID. We use Bulk API 2.0 for chat history volumes above 100,000 records.

Fans-CRM's creator account data (profile name, bio, social links, earnings summary, payout records) maps to Salesforce Account as a single parent record. This is relevant for agencies managing multiple creator profiles: each Fans-CRM creator account becomes a separate Salesforce Account, and the fans subscribed to that creator become Contacts linked to that Account. Earnings and payout data migrate to custom fields on Account for revenue reporting.

Fans-CRM lapse re-engagement campaigns migrate to Salesforce Campaign with campaign type, target audience size, send date, and response rate preserved. Campaign members link to the corresponding Contact records via the fans_crm_id__c lookup. Campaign member status (Sent, Responded, Converted) maps to Salesforce CampaignMember Status values. Active campaign send logic does not migrate; the campaign record documents the campaign for rebuild in Salesforce Journey Builder or Flow.

Fans-CRM internal notes and fan-level comments migrate to Salesforce Note records linked via ContentDocumentLink to the parent Contact. Note body preserves as rich text. Note timestamps map to Salesforce Note CreatedDate for historical ordering. If Fans-CRM export includes attachment references, we migrate them as ContentDocument records linked to the same parent Contact.

Fans-CRM browser session data (cookies, session tokens, browser fingerprints used for anti-detect browsing) are tied to the Fans-CRM bundled browser environment and do not transfer to Salesforce. This feature is explicitly excluded from migration scope. We confirm during scoping whether the client uses Fans-CRM for data management only or also for active OnlyFans session management. Session-based features must be rebuilt independently in the new CRM environment.