Migrate from Contact Beacon to Salesforce Sales Cloud

Beacon Contacts map directly to Salesforce Contacts. Standard fields (Name, Email, Phone, Address) migrate as typed Salesforce fields. Owner assignment maps to Salesforce OwnerId via email-matched User lookup. We flag any contacts with a revoked API key in Beacon as inactive Salesforce Users pending reactivation.

Beacon's flat object model does not separate individuals from organizations. If Beacon Contacts include organization-named records (e.g., Company Contact type), we split these into Salesforce Account records with the individual contact attached as a Contact linked via AccountId. The customer chooses during scoping whether individual-only Beacon databases skip the Account layer.

Beacon Donations map to Salesforce Opportunities with the Donation Amount as Amount, Donation Date as CloseDate, and the campaign tag as CampaignId lookup. Opportunity Name is auto-generated as '{Contact Name} - {Campaign} - {Date}'. We preserve the Gift Aid boolean as a custom Opportunity field Gift_Aid_Declared__c (checkbox) or map to the Tax Exempt field if the destination org has configured it. Donation status (pending, completed, refunded) maps to Opportunity StageName values configured during schema design.

Beacon Campaigns map to Salesforce Campaign with Campaign Name, Status (Planned, Active, Completed, Archived), StartDate, and EndDate. We resolve campaign-to-contact membership through CampaignMember records inserted after both Contact and Campaign are in Salesforce. Fundraising appeal type (individual giving, event, grant) maps to Campaign Type picklist.

Beacon donor journey pipeline stages migrate to Salesforce Sales Processes as Stage entries with associated probability values. Any conditional stage-routing rules (e.g., automatic escalation based on donation amount thresholds) must be manually reconfigured in Salesforce Flow after migration. We document every stage name and sequence during scoping.

Beacon per-organization custom fields on Contacts are discovered during scoping, typed (text, number, date, checkbox, picklist), and created in Salesforce before Contact import. Multi-select picklist fields from Beacon migrate to Salesforce multi-select picklists. Any unsupported field types (e.g., complex JSON blobs stored in text fields) are flagged and stored as Long Text Area fields for manual review.

Beacon custom fields on Donations (e.g., donation sub-type, pledge installment number, gift designation) map to custom Opportunity fields. We pre-create these in Salesforce during the schema design phase. Gift Aid declaration date migrates to Gift_Aid_Date__c if the Gift Aid flag is stored as a custom checkbox.

Beacon tags on Contacts and Donations migrate as flat label arrays. We map them to Salesforce Topics with TopicAssignment records for broad tagging, or to a custom multi-select picklist field on Contact if the customer prefers a structured taxonomy. Tags that correspond to inactive Beacon workflows are flagged with a note in the migration inventory.

File attachments on Beacon Contact records are downloaded via individual API requests, chunked to stay within Beacon's rate limits, and re-uploaded to Salesforce as ContentVersion records linked via ContentDocumentLink to the parent Contact. Large batches (>500 files) are split into phases to avoid timeout. We store the original filename and mime type in the ContentVersion Description field for audit.

Beacon User accounts are mapped to Salesforce Users by email match. Inactive Beacon users import as inactive Salesforce Users (or archived depending on destination org settings). Owner assignments on Contact, Donation, and Campaign records resolve to the matched User ID. Users without a Salesforce match enter a reconciliation queue for admin provisioning before record import continues.

Beacon automated workflows (Gift Aid submission triggers, thank-you email sequences, donor follow-up timers) have no UI or API export path. We run a workflow audit during scoping, documenting every automation's trigger, conditions, actions, and delay logic. The customer receives a written Flow design guide with recommended Salesforce Flow equivalents. Rebuild is outside migration scope.

Beacon reports and dashboards do not export as reusable definitions. We document every active report name, filters, and metrics during scoping and deliver a written inventory for the customer to rebuild in Salesforce Reports & Dashboards or Analytics Cloud. Historical data is available in Salesforce post-migration for building new reports.